“Kam probleme te medha me VPS-in tim. Po e riinstaloj OpenClaw per heren e 3-te apo te 4-te tani.”

Ky mesazh u shfaq ne OpenClaw Discord muajin e kaluar. Perdoruesi nuk ishte i vetem. Nese shfletoni kanalet e komunitetit, do te gjeni dhjetera variacione te te njejtit problem: mjeti i shfletuesit deshton, agjenti nuk arrin Chromium, VPS-it i mbaron memoria, gjithcka funksiononte dje dhe sot jo me.

Nese po e lexoni kete artikull sepse sapo kerkuat “OpenClaw shfletuesi nuk funksionon VPS,” jeni ne vendin e duhur. Ky postim shpjegon pese gjerat qe prishen, pse nderveprojne ne menyre frustruese dhe si i zgjidhbem te gjitha ne OpenClaw.rocks Kubernetes operator qe te mos mendoni me kurre per konfigurimin e shfletuesit.

Gabimi qe te gjithe e shohin

Mesazhi me i zakonshem i gabimit ne komunitetin OpenClaw eshte ky:

Can't reach the OpenClaw browser control service
(timed out after 15000ms)

Shfaqet ne Ubuntu, Debian, ne Docker, ne Hetzner, Hostinger, GCP dhe kudo tjeter ku njerezit provojne te ekzekutojne OpenClaw me automatizim shfletuesi. Log-et e gateway-t thone “Browser control service ready.” Por kur agjenti provon te perdore shfletuesin, ndodh nje timeout.

Gabimi eshte gjenerik. Shkaqet nuk jane. Ka te pakten pese menyra te ndryshme deshtimi dhe te gjitha duken identike nga jashte.

Deshtimi 1: Snap Chromium dhe muri i AppArmor

Ne nje server te ri Ubuntu 22.04+, which chromium-browser kthen /usr/bin/chromium-browser. Duket e sakte. Nuk eshte.

Qe nga Ubuntu 22.04, paketa standarde e Chromium eshte nje snap. Kur gateway-i i OpenClaw provon te nise ate binary permes nje sherbimi systemd, shtresa e izolimit te AppArmor e bllokon. Paketa snap nuk mund te lidhe portat e Chrome DevTools Protocol (CDP) per debugging permes sandbox-it. Binary-ja niset, duket sikur fillon, pastaj deshton ne heshtje ne hapjen e portit qe i nevojitet OpenClaw.

Ne log-e do te shihni “Failed to start Chrome CDP on port 18800”, ose nganjehhere asgje fare. Procesi i shfletuesit nis dhe vdes para se te shkruaje nje rresht te vetem log-u.

Zgjidhja eshte instalimi i paketes .deb te Google Chrome ose perdorimi i binary-se se pavarur te Chromium nga Playwright ne ~/.cache/ms-playwright/. Te dyja anashkalojne sandbox-in e snap. Por zgjidhja nuk eshte e dukshme. Zbulimi i shfletuesit te OpenClaw skanon rruget standarde sipas rradhes, gjen binary-ne snap te paren dhe provon ta perdore. GitHub issue #4978 ka nje pershkrim te plote.

Deshtimi 2: Cilesimet standarde headless qe supozojne nje ekran

OpenClaw vine me headless: false dhe noSandbox: false si cilesimet standarde te shfletuesit. Kjo ka kuptim ne nje Mac ose kompjuter Windows me ekran. Ne nje VPS, nuk ka ekran. Pa konfigurim eksplicit, Chromium provon te hape nje dritare ne nje server ekrani qe nuk ekziston.

Dy ndryshime konfigurimi e rregullojne:

openclaw config set browser.headless true
openclaw config set browser.noSandbox true

Shumica e udhezuesve per VPS e permendin kete. Por nese ndiqni udhezuesin standard te instalimit te OpenClaw, asnjera rresht nuk shfaqet. Instaloni, provoni shfletuesin, deshton. Kerkoni gabimin. Gjeni nje postim blogu. Shtoni konfigurimin. Rinisni. Tani jeni tek deshtimi numer tre.

Deshtimi 3: OOM kill qe nuk e shihni

Nje tab i vetem Chromium me disa faqe te hapura konsumon 2 deri ne 4 GB RAM. Ne nje VPS me 4 GB, kjo nuk le pothuajse asgje per vete OpenClaw, sistemin operativ dhe sherbimet e tjera qe ekzekutoni.

Kur Linux mbetet pa memorie, OOM killer i kernelit mbyll procesin me te uritur per memorie. Ky eshte Chromium. Procesi vdes. OpenClaw regjistron nje timeout shfletuesi. Nuk ka raport crash-i, nuk ka stack trace, asnje tregues qe memoria ishte problemi.

Ka edhe nje version me te holle te ketij problemi. Chromium nis procese renderer per cdo tab. Nese keto procese nuk pastrohen si duhet, ato grumbullohen. Nje GitHub issue dokumentoi 39 procese renderer te braktisura qe konsumonin 3.8 GB RAM ne nje VPS qe supozohej te kishte hapesire te mjaftueshme.

Mund ta kontrolloni pas faktit me dmesg | grep -i "oom\|killed\|chromium", por shumica e njerezve nuk mendojne te shikojne atje. Rinisin OpenClaw, funksionon per disa minuta, pastaj ndodh perseri.

Faqja zyrtare e kerkesave te serverit rekomandon minimum 4 GB per nje konfigurim bazik. Por ky numer supozon qe nuk ka automatizim shfletuesi. Me shfletuesin te aktivizuar, 8 GB eshte dyshemeja realiste. Ne Hetzner, kjo eshte ndryshimi midis nje cpx22 (5 $/muaj) dhe nje cpx42 (17 $/muaj).

Deshtimi 4: Shared memory qe i mungon Docker-it

Nese ekzekutoni OpenClaw ne Docker (e zakonshme per deployimet VPS), ka nje grackë tjeter. /dev/shm standarde e Docker eshte 64 MB. Chromium perdor shared memory per komunikimin ndermjet proceseve. Kur mbaron, tab-et prishen ne heshtje ose shfaqin faqe boshe.

Zgjidhja eshte nje rresht ne docker-compose.yml:

shm_size: '2gb'

Ose montimi eksplicit:

volumes:
  - /dev/shm:/dev/shm

Kjo nuk eshte e dokumentuar ne udhezuesin e konfigurimit te OpenClaw. Eshte nje sjellje specifike e Docker qe prek cdo aplikacion qe perdor Chromium, por nese nuk keni deployuar me pare shfletues headless ne Docker, nuk do ta dinit ta kerkonit.

Deshtimi 5: Perplasje portash per te cilat askush nuk ju paralajmeroi

Sherbimi i kontrollit te shfletuesit te OpenClaw ekzekutohet ne nje port te ndryshem nga gateway-i. Si standard, eshte porti i gateway-t plus 2. Nese gateway-i juaj eshte ne 18789, sherbimi i kontrollit te shfletuesit duhet te jete ne 18791 dhe extension relay ne 18792.

Ne Docker, nese ekspozoni vetem portin 18789, sherbimi i kontrollit te shfletuesit eshte i paarritshëm nga jashte kontejnerit. Me keq, gateway-i regjistron “Browser control service ready” edhe kur porti 18791 nuk lidhet ndonjehhere. Issue #17584 e gjurmoi kete tek gateway-i qe importonte modulin e gabuar: nje qe regjistron mesazhin “ready” pa nisur serverin HTTP. Log-u ju thote qe gjithcka eshte ne rregull. Porti eshte i vdekur.

Ne Kubernetes, nese nje kontejner tjeter ne te njejtin pod tashme perdor portin 9222 (portin standard CDP), funksioni ensurePortAvailable() i OpenClaw e zbulon portin si te zene dhe refuzon lidhjen, edhe nese zeneësi eshte pikerisht instanca e Chromium me te cilen OpenClaw duhet te komunikoje.

GitHub issue #10994 dokumenton nje rast ku konfigurimi VPS i perdoruesit funksiononte sakte. Pastaj, pas disa veprimeve te automatizuara, porti CDP u bllokua. Zgjidhja e vetme ishte gjetja dhe mbyllja e proceseve te humbura te Chromium qe mbanin portin.

Pse keto deshtime bashkeveprojne

Secili nga keto pese probleme ka nje zgjidhje te njohur. Por ato nderveprojne. Zgjidhni problemin e snap dhe hasni ne cilesimet standarde headless. Rregulloni konfigurimin dhe Chromium niset. Funksionon per dhjete minuta, pastaj OOM killer e rrëzon. Shtoni swap space dhe tani limiti i shared memory te Docker shkakton deshtimi te heshtur renderimi. Rregulloni ate dhe zbuloni qe porti 18791 nuk eshte i ekspozuar.

Cikli i debugimit duket keshtu: kerkoni gabimin, gjeni zgjidhje te pjesshme, aplikoni zgjidhjen, hasni gabimin tjeter, perseritni. Nje perdorues ne Discord pershkroi riinstalimin e te gjithe OS-it “per heren e 3-te apo te 4-te.” Nje tjeter raportoi qe shfletuesi ishte “i paqendrueshem” pas asaj qe mendonte se ishte nje konfigurim i plote. Nje i trete hapi nje issue me titullin e thjeshte “Browser tool consistently fails on VPS.”

Problemi nuk eshte qe nje zgjidhje e vetme eshte e veshtire. Problemi eshte qe jane pese prej tyre, varen nga OS-i juaj specifik, menaxheri i paketave, kontejner runtime dhe ofruesi i VPS, dhe nje gabim i vetem ne zinxhir do te thote qe shfletuesi nuk funksionon.

Per meriten e tyre, ekipi i OpenClaw ka rregulluar ne menyre te vazhdueshme gabime te lidhura. Log-u mashtrues “ready”, pastrimi i rendererve te braktisur dhe trajtimi i portit CDP jane permiresuar te gjitha ne versionet e fundit. Por rregullimet upstream adresojne simptoma brenda kodit te OpenClaw. Ato nuk mund te instalojne binary-ne e duhur te Chromium ne serverin tuaj, te konfigurojne shared memory te Docker, ose te alokojne mjaftueshem RAM per automatizim shfletuesi. Keto mbeten pergjegjesia juaj.

Si e prisbem Chromium tre here (dhe cfare mesuam)

Ne ekzekutojme cdo agjent te OpenClaw.rocks ne Kubernetes duke perdorur operatorin tone open-source. Sidecar-i i shfletuesit na mori javë te tera per ta bere sakte. Hasem versionin tone te cdo problemi te pershkruar me siper, plus disa qe shfaqen vetem ne kontekstin e orkestrimit te kontejnereve.

Ideja ishte e thjeshte: ekzekutoni Chromium si nje kontejner te ndryshem prane OpenClaw, te lidhur permes CDP. Nje rresht ne custom resource dhe shfletuesi thjesht funksionon.

spec:
  chromium:
    enabled: true

Ja si u realizua ne te vertete ky rresht i vetem.

Prishje 1: Perdoruesi i gabuar, sistem skedaresh vetem per lexim

Perpjekja jone e pare ekzekutoi kontejnerin Chromium si UID 1001 me nje sistem skedaresh root vetem per lexim. Praktike e mire sigurie. Gjithashtu plotesisht e prishur. Imazhi browserless pret UID 999 (blessuser) dhe Node.js therret os.userInfo() ne nisje, e cila deshton me ENOENT kur UID nuk ka hyrje ne /etc/passwd. Edhe pas rregullimit te UID, sistemi i skedareve vetem per lexim bllokoi Chrome nga shkrimi i skedareve te perkohshme. Sidecar-i u prish ne cdo nisje para se te shkruante nje rresht te vetem log-u. Issue #12 ka historine e plote.

Prishje 2: Muri i sigurise WebSocket

Me kontejnerin me ne fund duke funksionuar, Chromium ishte aktiv, CDP pergjigjej ne portin 9222, por OpenClaw refuzoi ta perdorte. Gateway-i po lidhej me IP-ne LAN te pod-it (e kerkuar per Kubernetes Service routing) dhe shtresa e sigurise se OpenClaw bllokoi lidhjet ws:// ne tekst te qarte ne adresa jo-loopback: “SECURITY ERROR: Gateway URL uses plaintext ws:// to a non-loopback address. Both credentials and chat data would be exposed to network interception.”

Nje kontroll legjitim sigurie. Por ne nje pod Kubernetes, te gjithe kontejneret ndajne nje namespace rrjeti. Trafiku midis tyre nuk largohet kurre nga node-i. Nuk mund te ndryshoshim kontrollin e sigurise se OpenClaw, keshtu qe shtuam nje sidecar nginx reverse proxy qe degjon ne te gjitha nderfaqet dhe percjell ne gateway ne loopback. Gateway-i mbetet i sigurt. Sherbimi mbetet i arritshëm. Issue #135 dokumenton debugging-un.

Prishje 3: Perplasja e portit 3000

Chromium po funksiononte. Gateway-i ishte i proxy-uar. Por shfletuesi akoma nuk lidhej. Imazhi browserless perdor si standard portin 3000, i cili perplasej me sherbimin e brendshem te kontrollit te shfletuesit te OpenClaw. Dhe kur kaluam ne portin 9222, ensurePortAvailable() e OpenClaw e zbuloi si “ne perdorim nga dicka tjeter” dhe refuzoi lidhjen, sepse ne nje namespace rrjeti te ndare, porti i sidecar-it duket lokal.

Zgjidhja ishte perdorimi i adreses IP te pod-it (permes Kubernetes Downward API) ne vend te localhost per URL-ne CDP. Nje adrese jo-loopback i thote OpenClaw te perdore modalitetin remote/attach-only: lidhu me ate qe tashme po funksionon ne vend qe te provosh te nisesh shfletuesin tend. PR #183 e zgjidhi kete.

Rezultati: pese rregullime, te aplikuara automatikisht

Secila nga keto prishje na mesoi dicka. Operatori aktual i kodon te gjitha:

Izolimi i sidecar-it. Chromium ekzekutohet ne kontejnerin e vet. Pa snap. Pa Playwright. Pa flamuj headless. Imazhi browserless merret me te gjitha keto.

Burime te dedikuara. Sidecar-i merr limitet e veta te CPU dhe memories (250m-1000m CPU, 512Mi-2Gi RAM si standard, te konfigurueshme). Nese Chromium tejkalon limitin e memories, Kubernetes rinis vetem kontejnerin e shfletuesit. Agjenti juaj vazhdon te funksionoje.

Shared memory. Operatori monton automatikisht nje volume te mbeshtetur ne memorie prej 1 GB ne /dev/shm. Nuk nevojitet konfigurim i Docker shm_size.

Drejtim portash. IP e pod-it per URL-ne CDP aktivizon modalitetin remote. OpenClaw lidhet me sidecar-in ne vend qe te provoje te zoteroje portin. Konflikti ensurePortAvailable() zhduket.

Mbrojtje e integruar kunder zbulimit si bot. Shume faqe interneti identifikojne Chromium standarde headless dhe bllokojne automatizimin. Operatori mbeshtet extraArgs ne sidecar-in Chromium, keshtu qe mund te kaloni flamuj si --disable-blink-features=AutomationControlled dhe user agent te personalizuara pa ndertuar nje imazh kontejneri te personalizuar:

spec:
  chromium:
    enabled: true
    extraArgs:
      - "--disable-blink-features=AutomationControlled"
      - "--user-agent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
      - "--window-size=1920,1080"

Siguri pa kompromis. Te gjitha Linux capabilities te hequra, privilege escalation i desaktivizuar, seccomp RuntimeDefault, non-root UID 999. Pa --no-sandbox si root.

Cfare do te thote kjo per ju

Nese ekzekutoni OpenClaw ne nje VPS dhe shfletuesi funksionon, urime. Keni kaluar pese menyra te ndryshme deshtimi dhe keni dale ne anen tjeter. Mbajeni konfigurimin tuaj. Beni backup.

Nese shfletuesi nuk funksionon, ose funksionon me nderprerje, ose nese jeni te lodhur duke debuguar Chromium ne nje VPS 5 dollare, mendoni se sa vlene koha juaj.

OpenClaw.rocks ekzekuton cdo agjent ne Kubernetes me operatorin e pershkruar me siper. Sidecar-i i shfletuesit eshte i parakonfiguruar. Memoria eshte e alokuar. Portat jane te drejtuara. Siguria eshte e forcuar. Nuk instaloni asgje, nuk konfiguroni asgje, nuk debugoni asgje.

Agjenti juaj merr nje shfletues qe funksionon. Cdo here. Menjehere.

Pese rregullimet, te permbledhura

Nese deshironi te mbeteni me self-hosting, ja lista e plote:

  1. Zevendesoni Chromium snap me Google Chrome .deb ose binary-ne e pavarur te Playwright
  2. Aktivizoni modalitetin headless: openclaw config set browser.headless true dhe browser.noSandbox true
  3. Alokoni 8 GB+ RAM ose shtoni 4 GB swap per automatizim shfletuesi
  4. Montoni shared memory ne Docker: shm_size: '2gb'
  5. Ekspozoni te tre portat: gateway, browser control (gateway + 2) dhe extension relay (gateway + 3)

Ose kaloni listen. Merrni asistentin tuaj ne OpenClaw.rocks dhe na lini infrastrukturen neve.