„Turiu didžiulių problemų su savo VPS. Perinstaliuoju OpenClaw 3-ią ar 4-ą kartą.”

Ši žinutė pasirodė OpenClaw Discord praėjusį mėnesį. Vartotojas nebuvo vienintelis. Peržiūrėkite bendruomenės kanalus ir rasite dešimtis to paties variacijų: naršyklės įrankis neveikia, agentas negali pasiekti Chromium, VPS baigiasi atmintis, vakar viskas veikė, o šiandien ne.

Jei skaitote tai, nes ką tik ieškojote „OpenClaw naršyklė neveikia VPS”, esate tinkamoje vietoje. Šis įrašas paaiškina penkis dalykus, kurie sugenda, kodėl jie sąveikauja varginančiais būdais, ir kaip juos visus išsprendėme OpenClaw.rocks Kubernetes operatoriuje, kad jums niekada nebereikėtų rūpintis naršyklės konfigūracija.

Klaida, kurią mato visi

Dažniausias klaidos pranešimas OpenClaw bendruomenėje yra šis:

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

Jis pasirodo Ubuntu, Debian, Docker, Hetzner, Hostinger, GCP ir visur kitur, kur bandoma paleisti OpenClaw su naršyklės automatizavimu. Gateway žurnalai sako „Browser control service ready.” Bet kai agentas bando naudoti naršyklę, baigiasi laukimo laikas.

Klaida yra bendrinė. Priežastys ne. Yra mažiausiai penki skirtingi gedimo režimai, ir iš išorės jie visi atrodo identiškai.

Gedimas 1: Snap Chromium ir AppArmor siena

Šviežiame Ubuntu 22.04+ serveryje which chromium-browser grąžina /usr/bin/chromium-browser. Tai atrodo teisingai. Nėra.

Nuo Ubuntu 22.04 numatytasis Chromium paketas yra snap. Kai OpenClaw gateway bando paleisti šį dvejetainį failą per systemd paslaugą, AppArmor apribojimų sluoksnis jį blokuoja. Snap paketas negali susieti Chrome DevTools Protocol (CDP) derinimo prievadų per smėlio dėžę. Dvejetainis failas paleidžiamas, atrodo, kad veikia, ir tada tyliai nepavyksta atidaryti prievado, kurio OpenClaw reikia.

Žurnaluose matysite „Failed to start Chrome CDP on port 18800” arba kartais nieko. Naršyklės procesas paleidžiamas ir miršta prieš parašydamas vieną žurnalo eilutę.

Sprendimas yra įdiegti Google Chrome .deb paketą arba naudoti Playwright atskirą Chromium dvejetainį failą iš ~/.cache/ms-playwright/. Abu apeina snap smėlio dėžę. Bet sprendimas nėra akivaizdus. OpenClaw naršyklės aptikimas skenuoja standartinius kelius eilės tvarka, pirmiausia randa snap dvejetainį failą ir bando jį naudoti. GitHub issue #4978 turi pilną aprašymą.

Gedimas 2: Headless numatytosios reikšmės, kurios numano ekraną

OpenClaw pateikiamas su headless: false ir noSandbox: false kaip naršyklės numatytosiomis reikšmėmis. Tai prasminga Mac arba Windows kompiuteryje su ekranu. VPS neturi ekrano. Be aiškios konfigūracijos Chromium bando atidaryti langą ekrano serveryje, kuris neegzistuoja.

Du konfigūracijos pakeitimai tai išsprendžia:

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

Dauguma VPS vadovų tai mini. Bet jei sekate standartines OpenClaw diegimo instrukcijas, nė viena eilutė nepasirodo. Įdiegiate, bandote naršyklę, nepavyksta. Ieškote klaidos. Randate tinklaraščio įrašą. Pakeičiate konfigūraciją. Paleidžiate iš naujo. Ir tada ateina gedimas numeris trys.

Gedimas 3: Nematomas OOM žudymas

Vienas Chromium skirtukas su keliomis atidarytomis puslapiais sunaudoja 2 iki 4 GB RAM. 4 GB VPS beveik nieko nelieka pačiam OpenClaw, operacinei sistemai ir kitoms veikiančioms paslaugoms.

Kai Linux baigiasi atmintis, branduolio OOM žudikas nutraukia daugiausiai atminties naudojantį procesą. Tai Chromium. Procesas miršta. OpenClaw registruoja naršyklės laukimo pabaigą. Jokio gedimo ataskaitos, jokio steko pėdsako, jokio požymio, kad atmintis buvo problema.

Yra ir subtilesnė šios problemos versija. Chromium paleidžia vaikų renderer procesus kiekvienam skirtukui. Jei jie tinkamai nesutvarkyti, jie kaupiasi. Vienas GitHub issue dokumentavo 39 our procesus, naudojančius 3,8 GB RAM VPS, kuris turėjo turėti pakankamai atsargos.

Galite patikrinti po fakto su dmesg | grep -i "oom\|killed\|chromium", bet dauguma žmonių negalvoja ten pažiūrėti. Jie paleidžia OpenClaw iš naujo, veikia kelias minutes, ir tada nutinka vėl.

Oficialus serverio reikalavimų puslapis rekomenduoja mažiausiai 4 GB bazinei konfigūracijai. Bet šis skaičius numano, kad naršyklės automatizavimo nėra. Su įjungta naršykle 8 GB yra realistinis minimumas. Hetzner tai skirtumas tarp cpx22 (5 $/mėn.) ir cpx42 (17 $/mėn.).

Gedimas 4: Docker trūkstama bendroji atmintis

Jei paleidžiate OpenClaw Docker (įprasta VPS diegimams), yra dar viena spąstai. Docker numatytasis /dev/shm yra 64 MB. Chromium naudoja bendrąją atmintį tarpprocesiniam ryšiui. Kai ji baigiasi, skirtukai tyliai sugenda arba atvaizduoja tuščius puslapius.

Sprendimas yra viena eilutė jūsų docker-compose.yml:

shm_size: '2gb'

Arba prijunkite aiškiai:

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

Tai nėra dokumentuota OpenClaw nustatymo vadove. Tai Docker specifinė elgsena, kuri paveikia bet kurią Chromium naudojančią programą, bet jei niekada nesate diegę headless naršyklių Docker, nežinotumėte, kad to ieškoti.

Gedimas 5: Prievadų kolizijos, apie kurias niekas neįspėjo

OpenClaw naršyklės valdymo paslauga veikia atskirame prievade nuo gateway. Numatytai tai gateway prievadas plius 2. Jei jūsų gateway yra 18789, naršyklės valdymo paslauga turėtų būti 18791, o plėtinių perdavimo relė 18792.

Docker, jei atidarote tik 18789 prievadą, naršyklės valdymo paslauga nepasiekiama iš konteinerio išorės. Dar blogiau, gateway registruoja „Browser control service ready” net kai 18791 prievadas niekada iš tikrųjų nesusiejamas. Issue #17584 atsekė tai iki gateway importuojančio neteisingą modulį: tokį, kuris registruoja „ready” pranešimą nepaleidęs HTTP serverio. Žurnalas sako, kad viskas gerai. Prievadas miręs.

Kubernetes, jei kitas konteineris tame pačiame pod jau naudoja 9222 prievadą (standartinį CDP prievadą), OpenClaw ensurePortAvailable() funkcija aptinka prievadą kaip užimtą ir atsisako prisijungti, net jei užėmėjas yra būtent ta Chromium instancija, su kuria OpenClaw turėtų bendrauti.

GitHub issue #10994 dokumentuoja atvejį, kai vartotojo VPS konfigūracija veikė teisingai. Tada, po kelių automatizuotų veiksmų, CDP prievadas užstrigo. Vienintelis sprendimas buvo rasti ir nutraukti klaidžiojančius Chromium procesus, laikančius prievadą.

Kodėl šie gedimai kaupiasi

Kiekviena iš šių penkių problemų turi žinomą sprendimą. Bet jos sąveikauja. Išsprendžiate snap problemą ir susiduriate su headless numatytąja reikšme. Pataisote konfigūraciją ir Chromium paleidžiamas. Veikia dešimt minučių, tada OOM žudikas smogia. Pridedate swap erdvę, o dabar Docker bendrosios atminties limitas sukelia tylias atvaizdavimo klaidas. Pataisote tai ir sužinote, kad 18791 prievadas neatidarytas.

Derinimo ciklas atrodo taip: ieškoti klaidos, rasti dalinį pataisymą, pritaikyti pataisymą, susidurti su kita klaida, kartoti. Vienas Discord vartotojas aprašė visos operacinės sistemos perinstaliavimą „3-ią ar 4-ą kartą.” Kitas pranešė, kad naršyklė buvo „nestabili” po to, ką laikė pilna konfigūracija. Trečias atidarė issue pavadintą tiesiog „Browser tool consistently fails on VPS.”

Problema ne ta, kad kiekvienas atskiras pataisymas būtų sudėtingas. Problema ta, kad jų yra penki, jie priklauso nuo jūsų konkrečios operacinės sistemos, paketų tvarkyklės, konteinerių vykdymo aplinkos ir VPS tiekėjo, ir viena klaida grandinėje reiškia, kad naršyklė neveikia.

OpenClaw komanda nusipelno pripažinimo už nuolatinį susijusių klaidų taisymą. Klaidinantis „ready” žurnalas, our rendererių valymas ir CDP prievado tvarkymas pagerėjo naujose versijose. Bet upstream pataisymai sprendžia simptomus OpenClaw kode. Jie negali įdiegti tinkamo Chromium dvejetainio failo jūsų serveryje, sukonfigūruoti Docker bendrosios atminties ar skirti pakankamai RAM naršyklės automatizavimui. Tai lieka jūsų atsakomybe.

Kaip sulaužėme Chromium tris kartus (ir ko išmokome)

Kiekvieną OpenClaw.rocks agentą paleidžiame Kubernetes su mūsų atvirojo kodo operatoriumi. Naršyklės sidecar užtruko savaites, kol pradėjo tinkamai veikti. Susidūrėme su savo kiekvienos aukščiau aprašytos problemos versija, plius keliomis, kurios pasirodo tik konteinerių orkestravimo kontekste.

Idėja buvo paprasta: paleisti Chromium kaip atskirą konteinerį šalia OpenClaw, sujungtą per CDP. Viena eilutė Custom Resource ir naršyklė tiesiog veikia.

spec:
  chromium:
    enabled: true

Štai kaip ta viena eilutė iš tikrųjų atsirado.

Gedimas 1: Neteisingas vartotojas, tik skaitoma failų sistema

Pirmas bandymas paleido Chromium konteinerį kaip UID 1001 su tik skaitoma šakninę failų sistema. Saugumo geriausia praktika. Ir visiškai sugadinta. Browserless atvaizdas tikisi UID 999 (blessuser), o Node.js paleidimo metu iškviečia os.userInfo(), kuris nepavyksta su ENOENT, kai UID neturi /etc/passwd įrašo. Net pataisius UID, tik skaitoma failų sistema blokavo Chrome rašyti laikinus failus. Sidecar griūdavo kiekvieną paleidimą prieš parašydamas vieną žurnalo eilutę. Issue #12 turi pilną istoriją.

Gedimas 2: WebSocket saugumo siena

Konteineriui pagaliau veikiant, Chromium buvo aktyvus, CDP atsakė 9222 prievade, bet OpenClaw atsisakė juo naudotis. Gateway susiejosi su pod LAN IP (reikalingas Kubernetes Service maršrutizavimui), o OpenClaw saugumo sluoksnis blokavo atviro teksto ws:// jungtis prie ne-loopback adresų: „SECURITY ERROR: Gateway URL uses plaintext ws:// to a non-loopback address. Both credentials and chat data would be exposed to network interception.”

Teisėtas saugumo patikrinimas. Bet Kubernetes pod visi konteineriai dalijasi tinklo vardų erdve. Srautas tarp jų niekada nepalieka mazgo. Negalėjome pakeisti OpenClaw saugumo patikrinimo, todėl pridėjome nginx reverse proxy sidecar, kuris klausosi visuose sąsajose ir persiunčia gateway loopback. Gateway lieka saugus. Service lieka pasiekiamas. Issue #135 dokumentuoja derinimą.

Gedimas 3: 3000 prievado kolizija

Chromium veikė. Gateway turėjo proxy. Bet naršyklė vis dar nesijungė. Browserless atvaizdas naudoja 3000 prievadą numatytai, kuris kolidavo su OpenClaw vidine naršyklės valdymo paslauga. Kai perjungėme į 9222, OpenClaw ensurePortAvailable() aptiko jį kaip „naudojamą kažko kito” ir atsisakė jungties, nes bendrojoje tinklo vardų erdvėje sidecar prievadas atrodo vietinis.

Sprendimas buvo naudoti pod IP adresą (per Kubernetes Downward API) vietoj localhost CDP URL. Ne-loopback adresas sako OpenClaw naudoti remote/attach-only režimą: prisijungti prie to, kas jau veikia, vietoj bandymo paleisti savo naršyklę. PR #183 tai išsprendė.

Rezultatas: penki pataisymai, automatiškai pritaikyti

Kiekvienas iš šių gedimų mus kažko išmokė. Dabartinis operatorius koduoja visa tai:

Sidecar izoliacija. Chromium veikia savo konteineryje. Be snap. Be Playwright. Be headless vėliavėlių. Browserless atvaizdas tuo pasirūpina.

Skirti ištekliai. Sidecar gauna savo CPU ir atminties limitus (250m-1000m CPU, 512Mi-2Gi RAM numatytai, konfigūruojama). Jei Chromium viršija atminties limitą, Kubernetes perkrauna tik naršyklės konteinerį. Jūsų agentas veikia toliau.

Bendroji atmintis. Operatorius automatiškai prijungia 1 GB atminties pagrindu veikiantį tomą /dev/shm. Nereikia Docker shm_size konfigūracijos.

Prievadų maršrutizavimas. Pod IP CDP URL aktyvuoja nuotolinį režimą. OpenClaw jungiasi prie sidecar vietoj bandymo užimti prievadą. ensurePortAvailable() konfliktas dingsta.

Integruotas anti-bot aptikimas. Daugelis svetainių aptinka numatytąjį headless Chromium ir blokuoja automatizavimą. Operatorius palaiko extraArgs Chromium sidecar, kad galėtumėte perduoti vėliavėles kaip --disable-blink-features=AutomationControlled ir pasirinktinius user agentus nekurdami pasirinktinio konteinerio atvaizdo:

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"

Saugumas be kompromisų. Visos Linux galimybės pašalintos, privilegijų eskalacija išjungta, seccomp RuntimeDefault, ne-root UID 999. Be --no-sandbox kaip root.

Ką tai reiškia jums

Jei paleidžiate OpenClaw VPS ir naršyklė veikia, sveikiname. Navigavote per penkis skirtingus gedimo režimus ir išėjote iš kitos pusės. Pasilikite savo konfigūraciją. Pasidarykite atsarginę kopiją.

Jei naršyklė neveikia, arba veikia protarpiais, arba pavargote derinti Chromium 5 dolerių VPS, pagalvokite, kiek vertas jūsų laikas.

OpenClaw.rocks paleidžia kiekvieną agentą Kubernetes su aukščiau aprašytu operatoriumi. Naršyklės sidecar yra iš anksto sukonfigūruotas. Atmintis skirta. Prievadai nukreipti. Saugumas sustiprintas. Nieko nediegiate, nieko nekonfigūruojate ir nieko nederinate.

Jūsų agentas gauna naršyklę, kuri veikia. Kiekvieną kartą. Paruošta naudoti.

Penki pataisymai apibendrintai

Jei norite likti prie savarankiško diegimo, štai pilnas kontrolinis sąrašas:

  1. Pakeiskite snap Chromium Google Chrome .deb paketu arba Playwright atskiru dvejetainiu failu
  2. Įjunkite headless režimą: openclaw config set browser.headless true ir browser.noSandbox true
  3. Skirkite 8 GB+ RAM arba pridėkite 4 GB swap naršyklės automatizavimui
  4. Prijunkite bendrąją atmintį Docker: shm_size: '2gb'
  5. Atidarykite visus tris prievadus: gateway, naršyklės valdymas (gateway + 2) ir plėtinių relė (gateway + 3)

Arba praleiskite sąrašą. Gaukite savo asistentą OpenClaw.rocks ir leiskite mums pasirūpinti infrastruktūra.