503 Service Unavailable
Opis kroničnog problema s hostingom (crowave.com)
Web stranicu crowave.com hostam nešto više od deset godina kod istog, cjenovno pristupačnog hosting pružatelja, čiji identitet za sada namjerno ne otkrivam. Tijekom tog razdoblja kontinuirano se ponavlja isti obrazac: server povremeno postane nedostupan, a preglednik vraća grešku “503 Service Unavailable” što je HTTP status koji označava da poslužitelj privremeno ne može obraditi zahtjev.
Tehnička podrška pružatelja reagira neujednačeno: nekad isti dan, nekad tek nakon nekoliko dana ili tjedana. Problem se u pravilu otkloni bez detaljnog objašnjenja (vjerojatno restartom relevantne usluge), a sljedeći ispad se može dogoditi već sutradan, za tjedan ili za mjesec dana.
Ova ponavljajuća situacija natjerala me da samostalno sagledam materiju koja bi trebala biti u domeni pružatelja usluge: napredne postavke administratorskog sučelja i PHP-a, izmjene sistemskih konfiguracijskih datoteka unutar web-foldera, te dublje razumijevanje rada WordPress jezgre i međusobne kompatibilnosti dodataka (plugina). To je znanje koje korisnik hostinga u pravilu ne bi trebao morati steći, no kad podrška šuti danima, čekanje prekriženih ruku jednostavno nije održiva opcija.
Opis najnovijeg incidenta
U posljednjih tjedan dana ponovila se posebno indikativna varijanta problema: statična naslovna stranica na root domeni te statične datoteke unutar WordPress instalacije učitavaju se posve normalno, dok sama WordPress instalacija na adresi https://www.crowave.com/blog/ dosljedno vraća grešku 503 Service Unavailable. Ta razlika u ponašanju jasno je upućivala na to da je uzrok izoliran na PHP sloju, a ne na Apache poslužitelju u cjelini.
U pokušaju samostalnog rješavanja, u administratorskom sučelju (“Select PHP Version” / MultiPHP Manager) promijenio sam PHP verziju domene s 8.3 na 8.2 i natrag na 8.3, u nadi da će se time prisilno regenerirati PHP-FPM socket. Problem je ostao identičan, čime je isključena mogućnost da je uzrok jednostavna, površinska konfiguracijska greška.
Tehnička analiza Apache error loga
Uvid u Apache error log otkrio je konkretan, ponavljajući uzrok:
[proxy:error] (111)Connection refused: AH02454: FCGI: attempt to connect to Unix domain socket /opt/alt/php-fpm82/usr/var/sockets/crowave.sock (*:80) failed
[proxy_fcgi:error] [client 195.2.67.184:46220] AH01079: failed to make connection to backend: httpd-UDS
Ovi zapisi pokazuju da je Apache aktivan i da ispravno prosljeđuje zahtjeve prema /blog/ putem FastCGI (FCGI) protokola, no na drugoj strani Unix domain socketa nitko ne “sluša“, odnosno PHP-FPM pool dodijeljen računu “crowave” ili nije pokrenut, ili se srušio. Time se objašnjava i zašto statični sadržaj radi bez problema: Apache ga poslužuje izravno, bez posredovanja PHP-a, dok se svaki zahtjev prema WordPressu (koji zahtijeva izvršavanje PHP koda) završava greškom 503.
Sama pogreška “(111) Connection refused” ima precizno značenje: datoteka socketa postoji na disku, ali nijedan proces je ne “osluškuje” za dolazne konekcije. To je tipičan simptom da je PHP-FPM proces prethodno bio aktivan, a potom pao ili je nasilno prekinut (npr. od strane sustava zbog prekoračenja resursa), pri čemu je datoteka socketa ostala “zaostala” na disku. Za usporedbu, da socket uopće nije bio kreiran, error log bi prijavio grešku “(2) No such file or directory” — bitno drugačiji simptom koji bi upućivao na posve drugačiji uzrok (npr. da PHP-FPM pool za taj račun uopće nije konfiguriran).
U istom error logu zabilježen je i velik broj ModSecurity zapisa (status 403) za pokušaje pristupa putanjama poput /.env, /.env.production i /.git/config. Ti zapisi predstavljaju rutinsko automatizirano skeniranje domene u potrazi za procurjelim konfiguracijskim datotekama i vjerodajnicama, no WAF (Web Application Firewall) sloj te zahtjeve ispravno odbija prije nego što uopće dođu do PHP-a, pa oni nisu uzrok pada servisa, nego odvojena, uobičajena “pozadinska buka” interneta.
Provjera preopterećenja zakupljenih resursa
Prva pretpostavka bila je da sam premašio resurse dodijeljene mom hosting paketu. Grafovi prometa (bandwidth) u administratorskom sučelju, međutim, pokazivali su nizak i naizgled bezopasan promet, tipično do 3 MB, rijetko do 10 MB dnevno, dok su ukupna iskorištenost diskovnog prostora (15%) i mjesečnog prometa (26%) ostajale daleko ispod ugovorenih limita.
Pažljivijim pregledom pojedinačnih dnevnih vrijednosti na tom grafu, međutim, uočio sam znatnu nekonzistentnost: povremeno bi se pojavio dnevni “pik” od 750 ili čak 900 MB, potpuno izvan inače prikazanog obrasca. Ta nesukladnost gdje je svakodnevni promet prikazan kao gotovo zanemariv, uz rijetke, naizgled nasumične ekstremne vrijednosti, bila je prvi signal da widget za bandwidth ne prikazuje stvarno stanje pouzdano, što se kasnijom analizom i potvrdilo.
Detaljna analiza stvarnog prometa (GoAccess)
Kako bih dobio pouzdanu sliku, sirove Apache access logove analizirao sam alatom GoAccess, koji generira statistiku izravno iz zapisa poslužitelja, neovisno o očito nepouzdanom sažetku iz administratorskog sučelja.
Rezultati su bili nedvosmisleni. Stvaran dnevni promet konzistentno iznosi između 1 i 1,3 GB svaki dan, ne povremeno. Ranije prikazivani graf koji je za većinu dana pokazivao do 10 MB taj je promet drastično podcjenjivao, a rijetki “pikovi” od 750–900 MB koje sam ranije uočio zapravo su bili bliži stvarnoj, uobičajenoj vrijednosti, dok su ostali dani bili pogrešno prikazani kao gotovo nula.
Još važnije, analiza HTTP statusnih kodova pokazala je da se greške 503 pojavljuju svakodnevno, u manjoj ili većoj mjeri. Primjerice, prije tri dana je zabilježeno 1.241 grešaka 503, odnosno 8,4% svih zahtjeva tog dana. To ukazuje da PHP-FPM pool nije povremeno, nego kronično na rubu preopterećenja, a ja kao korisnik primjećujem samo najteže epizode, kada ispad traje neprekidno satima.
Najvažniji nalaz odnosi se na sastav prometa: 44 do 55% ukupnog prometa dolazi od automatiziranih crawlera (botova), a ne od stvarnih posjetitelja. Sam bot Amazonbot/0.1 (Amazonov indekser) samostalno je odgovoran za 26 do 37% svih dnevnih zahtjeva. Uz njega, značajan udio čine i SERankingBacklinksBot (SEO alat za praćenje povratnih poveznica), Baiduspider-render (kineski tražilički crawler koji u potpunosti renderira stranicu, uključujući sve slike), te ExaSearchBot i Reflectionbot. Amazonbot je u stručnoj i medijskoj literaturi iz 2025./2026. dobro dokumentiran kao agresivan crawler koji redovito preopterećuje manje web stranice, a njegovo poštivanje robots.txt datoteke nije pouzdano potvrđeno.
Iz ovoga proizlazi kako bi za pad WordPress stranica mogao biti krivac Amazonbot i slični bot alati koji ne donose ni posjetitelje ni SEO vrijednost već samo nepotrebno opterećenje servera. Oni drže PHP-FPM pool trajno blizu granice resursa dodijeljenih putem CloudLinux LVE sustava (Lightweight Virtualized Environment), odnosno mehanizma kojim CloudLinux svakom hosting računu ograničava CPU, memoriju i broj procesa. Svaki dodatni val prometa, bilo stvaran posjetitelj, WP-Cron zadatak ili tek još jedan bot, dovoljan je da pool bude ugašen (najvjerojatnije od strane samog LVE mehanizma, zbog prekoračenja memorije ili broja dopuštenih procesa).
Poduzete mjere
Na temelju ovih nalaza, na razini poslužitelja u .htaccess datoteci, prije nego što se WordPressova pravila preusmjeravanja uopće primijene, blokirao sam Amazonbot i ostale identificirane agresivne botove pravilom koje takve zahtjeve odbija s HTTP statusom 403, prije nego što uopće dođu do PHP-a:
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (Amazonbot|Reflectionbot|SERankingBacklinksBot) [NC]
RewriteRule .* - [F,L]
Ova mjera izravno smanjuje broj PHP-FPM procesa koje generira nepotreban promet. Međutim, to ne rješava temeljni uzrok (nedovoljno dimenzionirane resurse po računu) nego samo ublažava simptom sa strane koju kao korisnik mogu kontrolirati.
Komunikacija s pružateljem usluga
Pružatelju usluge poslao sam detaljan opis nalaza, uz konkretan upit:
Nastavno na 503 Service Unavailable problem... Analizom prometa na mojim WordPress stranicama (GoAccess, stvarni web logovi, ne cPanel bandwidth widget) može se vidjeti da stvaran dnevni promet iznosi konzistentno 1–1,3 GB dnevno (ne povremeno do 10 MB kako je prikazano u bandwidth grafu — taj graf očito netočno prikazuje većinu dana). 503 Service Unavailable greške pojavljuju se svaki dan u manjoj ili većoj mjeri (npr. 19.9. = 1.241 grešaka / 8,4% zahtjeva), što ukazuje na kroničan, ne povremen problem. Analiza pokazuje da 44–55% ukupnog prometa dolazi od automatiziranih crawlera, s botom "Amazonbot/0.1" samostalno odgovornim za 26–37% svih zahtjeva svaki dan. Sa svoje strane sada blokiram taj i slične botove na razini .htaccess. Molim da mi u svjetlu ovoga potvrdite jesu li trenutne PHP-FPM/LVE postavke za moj račun uopće dimenzionirane za promet ovog reda veličine (15.000–17.000 zahtjeva i ~1 GB prometa dnevno), i savjetujete li dodatne mjere (npr. poslužiteljsko rate-limiting pravilo za poznate agresivne botove) uz moju vlastitu blokadu.
Odgovor koji sam dobio glasio je, u cijelosti:
"Poštovani, radimo sa cwp developerima da se to riješi trajno jer hakerski napadi se učestalo pojačavaju te opterećuju php-fpm. Lp"
Sličan, gotovo identičan odgovor o “hakerskim napadima” dobio sam i prilikom prijašnje prijave, nekoliko mjeseci ranije.
Ovaj odgovor smatram nespecifičnim i djelomično netočnim s obzirom na prikupljene nalaze. Ono što je identificirano nije napad u smislu pokušaja neovlaštenog pristupa. Pokušaje te vrste (skeniranje /.env, /.git/config) je ModSecurity već ispravno i uredno blokirao sa statusom 403, prije nego što bi ijedan takav zahtjev uopće stigao do PHP-a. Ono što je stvarno preopterećivalo PHP-FPM pool jest legitiman, imenovan i lako prepoznatljiv promet, odnosno poznati indekseri i SEO alati (Amazonbot, Baiduspider, SERankingBacklinksBot), a ne napad. Nazivanje uobičajenog, dokumentiranog fenomena “hakerskim napadom” djeluje kao eksternalizacija problema (predstavlja ga kao vanjsku prijetnju koju je nemoguće kontrolirati) umjesto priznanja stvarnog uzroka: nedovoljno dimenzioniran ili neadekvatno konfiguriran PHP-FPM/LVE resurs za taj račun.
Vrijedi primijetiti i da odgovor spominje “cwp developere” što otvara pitanje koristi li pružatelj CWP (CentOS Web Panel), besplatnu alternativu cPanel-u koju manji provideri često administriraju samostalno, bez plaćene podrške proizvođača. Ako je tome tako, to bi ukazivalo na nepostojanje vlastitog specijaliziranog sistemskog administratorskog tima koji bi problem mogao riješiti izravno, nego se čeka na rješenje “izvana” (razvojne zajednice besplatnog alata) što bi objasnilo i sporost i nespecifičnost dobivenih odgovora. Ova pretpostavka zahtijeva dodatnu potvrdu, jer korišteni nazivi administratorskih funkcija (npr. “MultiPHP Manager”) inače upućuju na cPanel sučelje što je blaga nedosljednost vrijedna razjašnjenja s pružateljem.
Daljnji koraci
Deset godina ponavljajućih, a u posljednje vrijeme sve učestalijih ispada, teško je protumačiti kao niz nesretnih slučajnosti. Da je riječ o jednokratnom incidentu ili ograničenom lošem razdoblju, imalo bi smisla pričekati da se problem “trajno riješi”, kako je najavljeno. No dosljedan, desetljetni obrazac koji se pogoršava upućuje na strukturalni, a ne slučajan uzrok: prenapučen dijeljeni poslužitelj, preniski LVE limiti po računu, i nepostojanje ikakvog zaštitnog sloja (poput reverse proxyja, WAF-a s rate-limitingom, ili edge cachinga) koji bi uobičajeni automatizirani promet apsorbirao prije nego što dođe do PHP-a. Takav problem se ne rješava sam od sebe, pogotovo ne kod pružatelja koji deset godina u to očito nije investirao.
Zbog toga ozbiljno razmatram prelazak na drugog pružatelja usluga. Pritom sam svjestan da taj korak nosi vlastite izazove: kvalitetniji, dokazano pouzdaniji provideri realno koštaju značajno više od mojeg trenutnog jeftinog “Unlimited” paketa. Marketinški materijali sustavno naglašavaju povoljne specifikacije, a prešućuju stvarna ograničenja (npr. cijenu obnove nakon uvodnog razdoblja, koja zna biti i nekoliko puta viša od početne). Jamstvo 30 dana za povrat novca, koje nude pojedini provideri, ne jamči da se sličan scenarij (postupno “ograničenje resursa” i ponavljajući ciklus prijava bez konkretnog rješenja) neće ponoviti i nakon isteka tog razdoblja.
Najgore je što je u moru agresivnih reklama i plaćenih komentara vrlo teško naći neki relevantni forum ili recenzije za kvalitetu usluga pojedinih pružatelja web hostinga (posebice domaćih). Stječem dojam da sam ja jedan od rijetkih „sretnika“ koji ima s tim konstantne probleme. Smatram da je uzrok tome što i sa svojim web stranicama spadam u netipičnu kategoriju. Male statičke web stranice na jeftinim poslužiteljima vjerojatno nisu dovoljno zanimljive ni stvarnim posjetiteljima ni botovima te ostaju netaknute na serveru. Ozbiljne web stranice pak su obično smještene na bolje i skuplje servere. Ja sada već imam prilično veliku web stranicu (oko 1000 objava) sa specifičnim sadržajem, smještenu na jeftin server. Stranica je zbog puno autentičnih slika i tekstova očito zanimljiva botovima koji ju stalno agresivno napadaju. Ograničenja mojeg servera to ne mogu podnijeti.
Trenutni plan je dvojbeni: nastaviti borbu na trenutnom serveru i vršiti daljnji pritisak na postojećeg pružatelja da dâ konkretne odgovore (a ne generičke izjave) ili riskirati s prelaskom na neki bolji (skuplji) server. Možda je najbolja opcija prevesti sve WordPress objave u statičke stranice i time potpuno zaobići većinu problema koje sada imam. Ovo bi značilo i potpuno odustajanje od obrazaca za komentare, a također bi trebao koristiti i neke alternativne alate za automatski sadržaj, galeriju slika, tražilicu i slično.
Kako god bilo, za sada imam svoju offline kopiju cijelog web sjedišta, a što se tiče dijeljenja sadržaja na internetu, nekako nisam raspoložen trošiti nekoliko stotina eura godišnje samo za bolji web hosting. Naplaćivanje reklama koje bi se postavile na moje stranice također nije opcija jer to nije zamisao cijelog ovog projekta. Ovo treba biti baza praktično provjerenih znanja dostupna svima i besplatno, bez reklama, bez registracija, bez cenzura, bez obaveza i bez bilo kojih drugih skrivenih trikova i podvala kojima obiluje današnji internet. Cilj je pronaći krug sugovornika za specifične teme i voditi konstruktivne rasprave. Sve dok to bude moguće održavati po razumnoj cijeni, crowave.com će nekako opstajati na internetu.