Povežeš Claude ili neki drugi AI alat sa svojim WordPress sajtom preko MCP-a, sve radi nedelju dana, a onda veza počne da puca. Alat javlja da server nije dostupan, a sajt se u browseru otvara normalno. Prvi refleks je da kriviš plugin. Najčešće je krivac neko ko sedi između: CDN, proxy ili neko ograničenje na serveru.
Pre nego što krenemo, jedna ispravka. Naišao si možda na priču da Claude drži otvorenu SSE vezu i do sat vremena i da time zauzme jedan PHP worker. Tražili smo to u zvaničnoj MCP specifikaciji i u dokumentaciji WordPress MCP Adaptera i nismo našli nijedan izvor koji to tvrdi. Zato ovaj tekst ne polazi od te priče, nego od onoga što se može proveriti.
Šta je MCP veza u stvari
Današnji MCP preko HTTP-a se zove Streamable HTTP. Svaka poruka koju klijent pošalje je običan POST zahtev na jedan endpoint. Server na to može da odgovori na dva načina: običnim JSON odgovorom, ili otvaranjem SSE toka (Server-Sent Events) kroz koji stiže odgovor. Kad odgovor stigne, server treba da zatvori tok.
Postoji i druga mogućnost: klijent može da pošalje GET zahtev da bi otvorio tok za poruke koje server šalje sam od sebe. Taj tok je opcioni. Specifikacija kaže da server mora da vrati ili text/event-stream ili HTTP 405, što znači “ovde toka nema”. Dakle, 405 na GET zahtevu nije greška. To je ispravan odgovor servera koji ne nudi tok.
MCP Adapter za WordPress izlaže HTTP transport na adresi /wp-json/mcp/mcp-adapter-default-server, a klijent se prijavljuje preko Application Password-a. U njegovoj dokumentaciji ne piše ništa o SSE tokovima ni o dugim vezama. Za sad je razuman zaključak da običan poziv alata na tvom sajtu traje onoliko koliko traje sam posao, nekoliko sekundi, a ne sat vremena.
Gde se PHP worker uopšte pojavljuje
Dok traje jedan PHP zahtev, jedan PHP worker je zauzet. To važi za svaki zahtev, pa i za MCP poziv. Ako se desi da neki plugin ili server ostavi vezu otvorenom duže (otvoren tok, spor alat, poziv koji čeka eksterni API), taj worker ostaje blokiran sve to vreme. Na sajtu sa malo workera dovoljno je nekoliko takvih veza da posetioci počnu da čekaju u redu.
Koliko ti workera treba i kako da računaš koliko posetilaca sajt izdrži, objašnjeno je u tekstu PHP workeri i koliko posetilaca tvoj sajt izdrži. Ovde je bitna samo jedna stvar: dugačka veza nije besplatna, a kratka jeste. Zato je dobra stvar što većina MCP poziva spada u kratke.
Tri mesta gde veza puca
Kad je veza prekinuta posle skoro uvek istog vremena, to je potpis. Svaki sloj između klijenta i PHP-a ima svoj tajmer, i tačno vreme prekida ti govori ko ga je sekao.
Cloudflare ili drugi CDN ispred sajta
Cloudflare u dokumentaciji za grešku 524 navodi da origin ima 125 sekundi da počne da odgovara, a Enterprise klijenti taj limit mogu da podignu. Drugi izvori i prijave iz prakse pominju oko 100 sekundi. U jednoj prijavi na GitHub-u za MCP server iza Cloudflare-a vidi se kako SSE tok koji nema nikakav saobraćaj biva prekinut posle otprilike 100 sekundi, a klijent se posle toga sam ponovo povezuje. Predloženo rešenje je da server šalje SSE komentar (: ping) na svakih 30 sekundi, da tok ne bude tih.
Ako ti veza puca tačno na dva minuta, osumnjičeni broj jedan je CDN. Jedan način da to proveriš je da test uradiš preko poddomena koji ide direktno na server, bez proxy-ja. Ako tamo radi, znaš gde je problem. Trajno rešenje za zahteve koji su stalno duži od limita Cloudflare preporučuje upravo poddomen bez proxy-ja (DNS only), uz napomenu da tada taj poddomen gubi njegovu zaštitu.
Web server ispred PHP-a
Nginx ima fastcgi_read_timeout koji je po podrazumevanoj vrednosti 60 sekundi. Važno je kako ga čitaš: tajmer se računa između dva uzastopna čitanja, a ne za ceo odgovor. Ako PHP u tih 60 sekundi ne pošalje ni bajt, veza se zatvara. Zato odgovor koji se šalje u delovima preživi, a odgovor koji samo čeka ne preživi. Ako veza puca na oko minut, gledaj ovde.
Sam PHP
PHP-ov max_execution_time je po podrazumevanoj vrednosti 30 sekundi. Na većini Linux instalacija se u tih 30 sekundi računa procesorsko vreme, a ne čekanje na mrežu ili spavanje, pa skripta koja samo čeka može da traje duže. Ali kod PHP verzija kompajliranih sa posebnim tajmerima (podrazumevano za ZTS build od PHP 8.3) čekanje se računa. Zato nemoj unapred da pretpostaviš ni jedno ni drugo, nego pitaj hostera.
Kako da otkriješ ko seče vezu
Ne treba ti ništa komplikovano. Evo redosleda koji nas obično dovede do odgovora brzo:
- Zabeleži koliko tačno sekundi prođe pre prekida. Oko 30, oko 60, oko 100 do 125 ili neki drugi broj. Broj već sužava krug.
- Probaj isti poziv preko adrese koja zaobilazi CDN. Ako prođe, CDN je uzrok.
- Proveri šta endpoint vraća na GET zahtev sa
Accept: text/event-stream. Ako je odgovor 405, tok ne postoji i nema šta da puca na toj strani. - Pogledaj PHP i web server log u trenutku prekida. Greška od PHP-a izgleda drugačije od zatvorene konekcije.
- Isključi na kratko keš i bezbednosne plugine koji presecaju REST zahteve. Bezbednosni pluginovi ponekad odbiju REST zahteve, pa to može da liči na prekid veze iako je u pitanju odbijen zahtev.
Poslednja stavka je češća nego što bi se očekivalo. Ako dobijaš 401 ili 403 umesto prekinute veze, problem nije mrežni nego u pristupu, a to je druga priča.
Šta da pitaš hosting pre nego što poveriš sajt AI alatu
Većina pitanja ima kratak odgovor, a razlikuje hosting koji zna šta radi od onog koji ti samo prodaje prostor:
- Koliko PHP workera ima moj nalog i šta se dešava kad su svi zauzeti?
- Koji su
fastcgi_read_timeoutimax_execution_timena mom nalogu i mogu li se podesiti? - Da li je ispred sajta CDN ili proxy i ko upravlja njegovim podešavanjima?
- Da li mogu da vidim log grešaka za određeni vremenski opseg?
Ako ti odgovori nisu jasni, to je informacija sama po sebi. Na brzom WordPress hostingu ovakve stvari ne bi trebalo da budu misterija, a ako ti je sajt na WordPress hostingu koji već koristiš, ista pitanja možeš da postaviš podršci.
Kad prekidi nisu tvoj problem
Ako klijent nakon prekida sam uspostavi vezu i nastavi, a ti to osetiš samo kao jedan sporiji prvi poziv, nema potrebe da trošiš sate. Specifikacija je napravljena da klijent to preživi: server sme da zatvori tok u bilo kom trenutku, a klijent sme da se ponovo poveže, čak i da nastavi od poslednjeg primljenog događaja. Prekid toka nije prekid posla.
Pravi problem je kad pozivi alata stalno padaju na istoj tački. Tada nešto stvarno treba popraviti, i tu ti je potreban neko ko zna da pročita logove i konfiguraciju. Ako nemaš tog nekog, to je tipičan posao za održavanje WordPress sajta.
Ako tek planiraš da povežeš sajt sa AI alatom, pročitaj prvo kako to izgleda bez žargona u tekstu kako Claude stvarno uređuje tvoj sajt. Posle toga će ti prekidi veze biti mnogo manja misterija.
Ukratko
Veza koja puca skoro uvek puca na istom broju sekundi, a taj broj ti kaže ko je sekao: oko 30 je PHP, oko 60 je web server, oko 100 do 125 je CDN. Priča o SSE vezi od sat vremena koja guta workere nema potvrdu u izvorima koje smo čitali, a obični MCP pozivi su kratki. Izmeri, isključi sloj po sloj i pitaj hosting konkretna pitanja. To je sve što ti treba.
