Start » Hosting » Tehnička podrška » Problemi sa hosting serverima i sajtovima

Problemi sa hosting serverom i sajtom

Problemi sa hosting serverima i sajtovima

Updated: 01/06/2020.

U ovom članku pisaću o problemima sa sajtovima i hosting serverima na koje sam nailazio tokom godina, kao i o (utvrđenim) uzricima tih problema i njihovim rešenjima. Zamišljen je u formi niza “problem – odgovor”, koji će se godinama dopunjavati, ažurirati. Da sve bude na jednom mestu, relativno lako pretraživo. Gde god to nije od ključnog značaja, neću navoditi konkretne sajtove, niti hosting provajdere, ili tipove servera – kako bi podaci bili što sažetiji i što lakši za pretragu.

Za pitanje-odgovor koristiću format “FAQ”, koji omogućava Yoast SEO plagin (batalio sam Yoast i prešao na The SEO Framework). Za razliku od samog WordPress-a, Yoast-ov FAQ pravi blokove u schema.org kompatibilnom formatu (opširnije o tome sam pisao u članku o WordPress 5 i Gutenberg editor). No, da pređemo na stvar.

Sadržaj:
Uvod – Zlatno pravilo

  1. “403 Forbidden” greška
  2. Problem sa dostavom mejlova, tipa a
  3. Connection refused PHP greška
  4. Ne šalju se mejlovi iz WordPress-a i druge aplikacije


1. Zlatno pravilo

Uvek, ali uvek proverite sve na svojoj strani, prvo.

  • Da li vaša Internet konekcija radi normalno za ostale sajtove?
  • Je li vam računar možda ima neki virus?
  • Jeste li platili sve račune?

Zatim proverite status servera/mreže hosting provajdera:

Provera statusa servera/mreže hosting provajdera. Objave uočenih problema obično budu tu prikazane.
Provera statusa servera/mreže hosting provajdera. Objave uočenih problema obično budu tu prikazane
Slika 1


Više detalja o ovome napisao sam u članku o teh. podršci.

Tek nakon toga, probajte instrukcije napisane ispod, u zavisnosti od problema sa kojim se suočavate:


Problem 1 – “403 Forbidden” greška

Kada pokušam otvoriti stranicu sajta, dobijam:
“403 Forbidden
Access to this resource on the server is denied!”

Prva stvar koju treba proveriti je blokirana IP adresa od strane WAF-a hosting provajdera (Web Access Firewall).
Ovo se može lako proveriti tako što se pokuša konekcija putem VPN-a, sa drugom IP adresom (može i TOR browser da se koristi u tu svrhu), ili korištenjem Internet mreže provajdera mobilne telefonije, sa pametnog telefona (ne preko kućnog/poslovnog Wi-Fi, pošto će tada verovatno biti ista IP adresa kao i na računaru).
Ako tada sve radi normalno, znači da treba deblokirati svoju IP adresu iz kontrol panela hosting provajdera. Kada se ulogujete na panel i izaberete meni kao na slici ispod, obično vaša IP adresa bude automatski detektovana. Ako to nije slučaj, koristite whatismyip.com.

Kako deblokirati svoju IP adresu iz korisničkog kontrol panela hosting provajdera.
Kako deblokirati svoju IP adresu iz korisničkog kontrol panela hosting provajdera
Slika P1-1


Šta ako konekcija preko druge IP adrese takođe ne radi? Naredna slika daje uputstvo za prvi korak:

Provera statusa servera/mreže hosting provajdera. Objave uočenih problema obično budu tu prikazane.
Provera statusa servera/mreže hosting provajdera. Objave uočenih problema obično budu tu prikazane
Slika P1-2


Ako vaš server/mreža nisu na spisku trenutno “problematičnih”, onda jedino ostaje da se obratite tehničkoj podršci provajdera, da utvrde u čemu je problem i reše ga. Kada pišete tiket, objasnite da ste proverili status servera/mreže i da ste pokušali konekciju sa (barem) dve različite IP adrese. Najverovatnije je problem do WAF (ModSecurity) pravila servera, ali moglo bi biti i nešto treće.


Problem 2 – Problem sa dostavom mejlova, tipa a

Imam više domena (sajtova) i mejlovi sa (barem) jednog od njih ne stižu na drugi (druge)

Kada se domen postavi na jednom hosting serveru, server će mejlove upućene tom domenu, a poslate sa domena hostovanih na istom serveru, pokušavati proslediti na isti server. Čak i ako se domen (sajt) migrira na drugi server (kod drugog hosting provajdera), svi mejlovi poslati sa istog (starog) servera, biće dostavljani lokalno.
Ako obrišete domen i inbox za dati mejl, može se desiti da mejlovi budu samo odbijeni (bounce nakon pokušaja dostave na isti server).

Na primer, bikegremlin.com i io.bikegremlin.com su na serveru A.
Premestim bikegremlin.com na server B.
Šaljem mejl sa [email protected] na [email protected] i taj mejl ne stiže gde treba (biva dostavljen na server A, a ako obrišem bikegremlin.com sa servera A, stiže bounced izveštaj o grešci).

Rešenje: pre migracije podesiti mejlove da idu preko eksternog servisa. Ako se koristi eksterni mejl servis, ovo bi svakako trebalo podesiti, čak i ako se ne premešta sajt. Sledite uputstvo za podešavanje eksternog mejl servisa.


Problem 3 – Connection refused PHP greška

S vremena na vreme nije loše proveriti sadržaj direktorijuma u kojem se sajt nalazi na hostin serveru (lokacija sajta i error logova na cPanel i DirectAdmin kontrolnim panelima). Prilikom pregleda primetio sam da se fajl za greške PHP-a (error_log u cPanel-u) puni ovakvim linijama:

[19-May-2020 18:33:14 UTC] Connection refused
[19-May-2020 18:35:15 UTC] Connection refused
[19-May-2020 18:37:16 UTC] Connection refused
[19-May-2020 18:38:15 UTC] Connection refused

Nova linija se upisuje svakih minut, ili kraće. OK, nešto pokušava da se nakači negde i ne uspeva. 🙂 Ovako je išlo moje utvrđivanje uzroka problema:

U pitanju je bio WordPress sajt.

Imam identične kopije sajta – dve na istom i jednu na drugom hosting serveru (druga kopija na istom serveru služi za testiranje brzine i optimizacije sajta i plaginova – radi lakšeg poređenja). Ovakve identične kopije sajtova se zovu stejdžing (eng. “staging”) sajt. Korisne su za testiranje stvari pre stavljanja ih na pravi (“produkcioni”) sajt.

Zahvaljujući tome, mogao sam proveriti da li se problem javlja na drugom, istom takvom sajtu (ista WordPress tema, plaginovi i sadržaj) na istom serveru, kao i da li se javlja takođe i na drugom serveru. Utvrdio sam da se na drugom serveru ne javlja, pa sam zaključio da je problem najverovatnije sa hostingom, a ne sa sajtom/temom/plaginovima.

Tada sam se obratio tehničkoj podršci hosting provajdera i, kao što sam očekivao, rekli su da je problem najverovatnije do nekog WordPress plagina. Što me je podestilo na sličan scenario koji sam opisao u članku o tehničkoj podršci hosting provajdera – nazvao sam ga “Kvaka 22”. Uglavnom, tehnička podrška je predložila da isključim sve plagine, pa testiram jedan po jedan, da vidim kada će se greška pojaviti.

OK, shvatio sam da ću morati sam da “kopam” malo. I uradio sam to – jasno je da moram otkriti koji plagin pravi problem i dati tehničkoj podršci više informacija. Ovo ni na koji način nije kritika tehničke podrške. Zaista je premalo informacija za rešavanje problema, dok tehnička podrška uglavnom ima desetine tiketa za podršku u svakom trenutku (videti tehnička podrška telefonom naspram tiketa).

Uključivanjem po jednog plagina dok su ostali deaktivirani, utvrdio sam da LiteSpeed cache plagin pravi probleme (zašto je LiteSpeed za mene najbolji opisao sam u članku o keširanju WordPress sajta). Kako bih bio siguran, aktivirao sam sve ostale plagine, osim LiteSpeed cache, da vidim je li se tada javlja problem – nije se javljao.

Javio sam to tehničkoj podršci, ali nije bilo dovoljno za rešavanje problema, tako da sam se udubio u podešavanja/opcije “problematičnog” plagina, tražeći šta ga navodi da stalno pokušava neuspešne konekcije. Ušao sam u meni za keširanje:

LiteSpeed Cache opcije za object cache
LiteSpeed Cache opcije za object cache
Slika P3-1


Ko god da je pravio plagin, uradio je odličan posao:

LiteSpeed Cache object cache podešavanja i izveštaj o statusu
LiteSpeed Cache object cache podešavanja i izveštaj o statusu
Slika P3-2


Jasno je napisano obaveštenje o uzroku problema. Memcached piše “Disabled” (1) pošto sam tu PHP ekstenziju isključio u PHP opcijama na serveru, jer je ne koristim. Ali test konekcije (2) pogazuje problem sa izabranim Redis-om. Klik na link pored tog izveštaja lepo sve objašnjava – “Learn More“.

Kada sam to preneo tehničkoj podršci, reinstalirali su Redis servis (za koji kažu da su tada utvrdili da posle apdejta nije radio kako treba) i sve je radilo kako treba. 🙂


Problem 4 – Ne šalju se mejlovi iz WordPress-a i druge aplikacije

Trudim se držati ovu rubriku “anonimnom” – iz mog iskustva, mnogi problemi su “univerzalni”, pa ne bih da “nepravedno” pravim lošu reputaciju za bilo koju kompaniju. Ovde sam ipak naveo sve provajdere i plagine, sa dobrim razlogom: za slučaj da je problem do blokiranja odrđenog opsega IP adresa, ili nekompatibilnosti određenih funkcionalnosti. Ovaj tekst služi za pomoć tehničkoj podršci u tome da reši problem.

a)

Koristim MXroute servis za mejlove. Radi lakšeg korištenja pri dopisivanju, povezao sam mejl nalog sa Gmail-om.
I ovo radi bez problema.

b)

Podesio sam bio WordPress slanje mejlova preko SMTP servisa MXroute, koristeći Easy WP SMTP plagin, kako se ne bih oslanjao na nepouzdane WordPress mejling funkcije.
Ovo je prestalo raditi. Problem sam primetion 30. maja 2020.
Greška koju dobijam kada šaljem test mejl:

SMTP ERROR: Failed to connect to server:  (0)SMTP connect() failed. https://github.com/PHPMailer/PHPMailer/wiki/Troubleshooting

c)

Za WordPress mejling liste koristim Newsletter plagin. Podešen je da isto koristi MXroute SMTP (ne ide preko drugih plaginova za slanje mejlova, niti preko WordPress mejling funkcija).
Ovo radi.

d)

Koristim (u fazi testiranja, imam nekih dilema, ali to ovde nije tema) aplikaciju InfiniteWP za nadzor WordPress sajtova (uz plagin InfiniteWP Client instaliran na sajtovima koji se nadziru – pomoću kojeg se WordPress sajt “javlja” aplikaciji). Aplikacija je instalirana na hosting serveru, i podešena da koristi MXrotue SMTP za slanje mejlova.
Ni u ovoj aplikaciji slanje mejlova sada ne radi.

h1)

Jedan od hostinga koje koristim je HostMantis (moja ocena & iskustvo).

h2)

Drugi hosting koji koristim je MyW.pt (moja ocena & iskustvo).

Ponašanje je isto na više servera i sajtova (svim sajtovima), kod oba navedena hosting provajdera.

e)

Za probu, kada se problem javio, instalirao sam drugi plagin za SMTP slanje mejlova: WP Mail SMTP by WPForms (isključio sam prethodno korišteni SMTP plagin).
Ni ovaj plagin ne radi.
Greška koju dobijam pri slanju testnog mejla:

Could not connect to the SMTP host.

This means your web server was unable to connect to friday.mxlogin.com.

Typically this error is returned for one of the following reasons:

-SMTP settings are incorrect (wrong port, security setting, incorrect host).
-Your web server is blocking the connection.
-Your SMTP host is rejecting the connection.

Recommended next steps:
Triple check your SMTP settings including host address, email, and password, port, and security.
Contact your web hosting provider and ask them to verify your server can connect to friday.mxlogin.com on port 465 using ssl encryption. Additionally, ask them if a firewall or security policy may be preventing the connection - many shared hosts block certain ports.
Note: this is the most common cause of this issue.
Contact your SMTP host to confirm you are using the correct username and password.
Verify with your SMTP host that your account has permissions to send emails using outside connections.

f)

Proverio sam error logove servera kod oba provajdera – nema prijavljenih (PHP) grešaka (lokacija error logova u DirectAdmin-u i cPanel-u).

g)

Objasnio sam sve ovo na sličan način HostMantis i MyW.pt tehničkoj podršci, a postovao sam opis problema i na MXroute forumu za podršku. Na tom forumu sam dobio povratnu informaciju drugog korisnika, koji je isto kod MyW.pt, ali koristi drugi MXroute server – korsiniku sve radi.

h)

Probao sam slanje mejla preko sajta koji koristi SMTP hosting provajdera (a ne MXroute).
Sve radi.

i)

Konačno – isprobao sam sa sajta koji je na istom hostingu, ali koristi drugi MXroute server (ali je isto preko MXroute).
Tu isto sve radi.
Ali, dok sam se setio to probati, proradilo je i sve ostalo.

Moje razmišljanje (pretpostavke) o potencijalnom uzroku problema:

  • Pošto a) i c) rade – na oba servera, na svim sajtovima, pretpostavljam da MXroute sam po sebi radi OK.
  • Pošto b) i e) ne rade ni na jednom serveru, na više sajtova, pretpostavljam da problem može biti vezan za stack koji koriste oba provajdera (CloudLinux, PHP 7.3, LiteSpeed – ili nešto četvrto), ili neki firewall blokira pristup MXroute.
    d) sam testirao samo na h2), tamo ne radi, pa zbog toga takođe sumnjam na ovaj problem.
  • Nije nemoguće, ali je malo verovatno, da su b), d) i e) prestali raditi zbog problema (sa plaginima i aplikacijom) svi u isto vreme.
  • g) i h) me navodi na to da možda neki firewall blokira određeni MXroute server. Nisam siguran – nisam ekspert.
  • i) navodi na to da je postojao neki problem sa MXroute – osim ako su oba provajdera nešto namestili, a da niko od njih nije javio. Ali (za) sada sve radi. 🙂

Postavio sam pitanje i na forumu za podršku Easy WP SMTP plagina – za slučaj da njima nešto padne na pamet (iako ne mislim više da je do plagina – kako sam i dopisao tamo).

I poslao sam link ka ovom pisaniju i tehničkim podrškama hosting provajdera i MXroute – ako njima nešto pomogne.

Proradilo je ponovo, nakon kraćeg “štucanja”. MXroute sugeriše da je ovo moglo biti uzrok:
https://support.cpanel.net/hc/en-us/articles/360048670574-Root-CA-Certificate-Expiration

Share...

1 misao o “Problemi sa hosting serverima i sajtovima”

Komentiraj

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.