„Man ir milzīgas problēmas ar manu VPS. Pārinstalēju OpenClaw 3. vai 4. reizi.”

Šī ziņa parādījās OpenClaw Discord pagājušajā mēnesī. Lietotājs nebija vienīgais. Pāršķirojiet kopienas kanālus, un atradīsiet desmitiem variāciju par to pašu tēmu: pārlūkprogrammas rīks neizdodas, aģents nevar sasniegt Chromium, VPS beidzas atmiņa, vakar viss strādāja un šodien ne.

Ja lasāt šo, jo tikko meklējāt „OpenClaw pārlūkprogramma nedarbojas VPS”, esat īstajā vietā. Šis ieraksts izskaidro piecas lietas, kas sabojājas, kāpēc tās mijiedarbojas frustrējošos veidos, un kā mēs tās visas atrisinājām OpenClaw.rocks Kubernetes operatorā, lai jums nekad vairs nebūtu jādomā par pārlūkprogrammas iestatīšanu.

Kļūda, ko redz visi

Biežākais kļūdas ziņojums OpenClaw kopienā ir šis:

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

Tas parādās Ubuntu, Debian, Docker, Hetzner, Hostinger, GCP un visur citur, kur cilvēki mēģina palaist OpenClaw ar pārlūkprogrammas automatizāciju. Gateway žurnāli ziņo „Browser control service ready.” Bet kad aģents mēģina izmantot pārlūkprogrammu, iestājas noildze.

Kļūda ir vispārīga. Cēloņi nav. Ir vismaz pieci atšķirīgi kļūmes režīmi, un no ārpuses tie visi izskatās identiski.

Kļūme 1: Snap Chromium un AppArmor siena

Svaigā Ubuntu 22.04+ serverī which chromium-browser atgriež /usr/bin/chromium-browser. Izskatās pareizi. Nav.

Kopš Ubuntu 22.04 noklusējuma Chromium pakete ir snap. Kad OpenClaw gateway mēģina palaist šo bināro failu caur systemd pakalpojumu, AppArmor ierobežojumu slānis to bloķē. Snap pakete nevar piesaistīt Chrome DevTools Protocol (CDP) atkļūdošanas portus caur smilškasti. Binārais fails palaiž, šķietami darbojas, un pēc tam klusi neizdodas atvērt portu, kas OpenClaw nepieciešams.

Žurnālos redzēsiet „Failed to start Chrome CDP on port 18800” vai dažreiz neko. Pārlūkprogrammas process sākas un mirst pirms vienas žurnāla rindas uzrakstīšanas.

Risinājums ir instalēt Google Chrome .deb paketi vai izmantot Playwright atsevišķo Chromium bināro failu no ~/.cache/ms-playwright/. Abi apiet snap smilškasti. Bet risinājums nav acīmredzams. OpenClaw pārlūkprogrammas noteikšana skenē standarta ceļus secīgi, vispirms atrod snap bināro failu un mēģina to izmantot. GitHub issue #4978 satur pilnu aprakstu.

Kļūme 2: Headless noklusējuma vērtības, kas pieņem ekrānu

OpenClaw tiek piegādāts ar headless: false un noSandbox: false kā pārlūkprogrammas noklusējuma vērtībām. Tam ir jēga Mac vai Windows datorā ar ekrānu. VPS nav ekrāna. Bez tiešas konfigurācijas Chromium mēģina atvērt logu displeja serverī, kas neeksistē.

Divas konfigurācijas izmaiņas to atrisina:

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

Vairums VPS ceļvežu to piemin. Bet ja sekojat standarta OpenClaw instalācijas instrukcijām, neviena rinda neparādās. Instalējat, izmēģināt pārlūkprogrammu, neizdodas. Meklējat kļūdu. Atrodat bloga ierakstu. Maināt konfigurāciju. Restartējat. Un nonākat pie kļūmes numur trīs.

Kļūme 3: Neredzamā OOM nogalināšana

Viena Chromium cilne ar dažām atvērtām lapām patērē 2 līdz 4 GB RAM. 4 GB VPS gandrīz nekas nepaliek pašam OpenClaw, operētājsistēmai un citiem darbojošajiem pakalpojumiem.

Kad Linux beidzas atmiņa, kodola OOM nogalinātājs beidz procesu, kas patērē visvairāk atmiņas. Tas ir Chromium. Process mirst. OpenClaw reģistrē pārlūkprogrammas noildzi. Nav avārijas ziņojuma, nav steka izsekojuma, nav norādes, ka atmiņa bija problēma.

Ir arī smalkāka šīs problēmas versija. Chromium palaiž bērnu renderer procesus katrai cilnei. Ja tie netiek pareizi iztīrīti, tie uzkrājas. Viens GitHub issue dokumentēja 39 bāreņu renderer procesus, kas patērēja 3,8 GB RAM VPS, kam vajadzēja būt pietiekami daudz rezerves.

Varat pārbaudīt pēc tam ar dmesg | grep -i "oom\|killed\|chromium", bet vairums cilvēku nedomā tur skatīties. Viņi restartē OpenClaw, tas darbojas dažas minūtes, un tad tas notiek atkal.

Oficiālā servera prasību lapa iesaka vismaz 4 GB pamata iestatīšanai. Bet šis skaitlis pieņem, ka nav pārlūkprogrammas automatizācijas. Ar ieslēgtu pārlūkprogrammu 8 GB ir reālistiskais minimums. Hetzner tā ir starpība starp cpx22 (5 $/mēn.) un cpx42 (17 $/mēn.).

Kļūme 4: Docker trūkstošā koplietotā atmiņa

Ja palaižat OpenClaw Docker (bieži VPS izvietošanā), ir vēl viens slazds. Docker noklusējuma /dev/shm ir 64 MB. Chromium izmanto koplietoto atmiņu starpprocesu komunikācijai. Kad tā beidzas, cilnes klusi avarē vai renderē tukšas lapas.

Risinājums ir viena rinda jūsu docker-compose.yml:

shm_size: '2gb'

Vai pievienojiet tiešā veidā:

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

Tas nav dokumentēts OpenClaw iestatīšanas ceļvedī. Tā ir Docker specifiska uzvedība, kas ietekmē jebkuru lietotni, kas izmanto Chromium, bet ja nekad neesat izvietojuši headless pārlūkprogrammas Docker, jūs nezinātu, ka to meklēt.

Kļūme 5: Portu kolīzijas, par kurām neviens nebrīdināja

OpenClaw pārlūkprogrammas vadības pakalpojums darbojas atsevišķā portā no gateway. Noklusēti tas ir gateway ports plus 2. Ja jūsu gateway ir uz 18789, pārlūkprogrammas vadības pakalpojumam jābūt uz 18791, un paplašinājumu relejs uz 18792.

Docker, ja atsedzat tikai 18789 portu, pārlūkprogrammas vadības pakalpojums nav pieejams ārpus konteinera. Vēl sliktāk, gateway reģistrē „Browser control service ready” pat kad 18791 ports nekad faktiski nepiesaistās. Issue #17584 izsekoja to līdz gateway, kas importēja nepareizu moduli: tādu, kas reģistrē „ready” ziņojumu, nepalaidot HTTP serveri. Žurnāls saka, ka viss ir kārtībā. Ports ir miris.

Kubernetes, ja cits konteineris tajā pašā podā jau izmanto 9222 portu (standarta CDP ports), OpenClaw ensurePortAvailable() funkcija atklāj portu kā aizņemtu un atsakās pieslēgties, pat ja aizņēmējs ir tieši tā Chromium instance, ar kuru OpenClaw vajadzētu sazināties.

GitHub issue #10994 dokumentē gadījumu, kad lietotāja VPS iestatīšana darbojās pareizi. Tad pēc dažām automatizētām darbībām CDP ports iestrēga. Vienīgais risinājums bija atrast un nogalināt noklīdušos Chromium procesus, kas turēja portu.

Kāpēc šīs kļūmes kumulējas

Katrai no šīm piecām problēmām ir zināms risinājums. Bet tās mijiedarbojas. Atrisināt snap problēmu un uzduramies uz headless noklusējuma vērtību. Izlabot konfigurāciju un Chromium startē. Darbojas desmit minūtes, tad OOM nogalinātājs sit. Pievienot swap telpu, un tagad Docker koplietotās atmiņas limits izraisa klusas renderēšanas kļūdas. Izlabot to un atklāt, ka 18791 ports nav atsegts.

Atkļūdošanas cilpa izskatās šādi: meklēt kļūdu, atrast daļēju labojumu, pielietot labojumu, sadurties ar nākamo kļūdu, atkārtot. Viens Discord lietotājs aprakstīja visas operētājsistēmas pārinstalēšanu „3. vai 4. reizi.” Cits ziņoja, ka pārlūkprogramma bija „nestabila” pēc tā, ko uzskatīja par pilnīgu iestatīšanu. Trešais atvēra issue ar virsrakstu vienkārši „Browser tool consistently fails on VPS.”

Problēma nav tā, ka katrs atsevišķais labojums būtu grūts. Problēma ir tā, ka to ir pieci, tie ir atkarīgi no jūsu konkrētās operētājsistēmas, pakešu pārvaldnieka, konteineru izpildlaika vides un VPS nodrošinātāja, un viena kļūda ķēdē nozīmē, ka pārlūkprogramma nedarbojas.

OpenClaw komanda ir pelnījusi atzinību par pastāvīgu saistītu kļūdu labošanu. Maldinošais „ready” žurnāls, bāreņu rendereru tīrīšana un CDP porta apstrāde ir uzlabojusies nesenajās versijās. Bet upstream labojumi risina simptomus OpenClaw kodā. Tie nevar instalēt pareizo Chromium bināro failu jūsu serverī, konfigurēt Docker koplietoto atmiņu vai piešķirt pietiekami daudz RAM pārlūkprogrammas automatizācijai. Tas paliek jūsu atbildība.

Kā mēs sabojājām Chromium trīs reizes (un ko iemācījāmies)

Katru OpenClaw.rocks aģentu palaižam Kubernetes ar mūsu atvērtā pirmkoda operatoru. Pārlūkprogrammas sidecar mums prasīja nedēļas, lai pareizi sāktu darboties. Mēs saskārāmies ar savu katras iepriekš aprakstītās problēmas versiju, plus dažām, kas parādās tikai konteineru orķestrēšanas kontekstā.

Ideja bija vienkārša: palaist Chromium kā atsevišķu konteineru blakus OpenClaw, savienotu caur CDP. Viena rinda Custom Resource un pārlūkprogramma vienkārši darbojas.

spec:
  chromium:
    enabled: true

Lūk, kā šī viena rinda faktiski tapa.

Avārija 1: Nepareizs lietotājs, tikai lasāma failu sistēma

Mūsu pirmais mēģinājums palaida Chromium konteineru kā UID 1001 ar tikai lasāmu saknes failu sistēmu. Drošības labākā prakse. Un pilnīgi sabojāts. Browserless attēls gaida UID 999 (blessuser), un Node.js startējot izsauc os.userInfo(), kas neizdodas ar ENOENT, kad UID nav /etc/passwd ieraksta. Pat pēc UID labošanas tikai lasāmā failu sistēma bloķēja Chrome no pagaidu failu rakstīšanas. Sidecar avarēja katrā startēšanā pirms vienas žurnāla rindas uzrakstīšanas. Issue #12 satur pilnu stāstu.

Avārija 2: WebSocket drošības siena

Ar konteineru beidzot darbojošos, Chromium bija aktīvs, CDP atbildēja uz 9222 porta, bet OpenClaw atteicās to izmantot. Gateway piesaistījās poda LAN IP (nepieciešams Kubernetes Service maršrutēšanai), un OpenClaw drošības slānis bloķēja vienkārša teksta ws:// savienojumus uz ne-loopback adresēm: „SECURITY ERROR: Gateway URL uses plaintext ws:// to a non-loopback address. Both credentials and chat data would be exposed to network interception.”

Leģitīma drošības pārbaude. Bet Kubernetes podā visi konteineri koplieto tīkla vārdtelpu. Trafiks starp tiem nekad neatstāj mezglu. Mēs nevarējām mainīt OpenClaw drošības pārbaudi, tāpēc pievienojām nginx reverse proxy sidecar, kas klausās uz visām saskarnēm un pārsūta uz gateway uz loopback. Gateway paliek drošs. Service paliek pieejams. Issue #135 dokumentē atkļūdošanu.

Avārija 3: 3000 porta kolīzija

Chromium darbojās. Gateway bija proxy. Bet pārlūkprogramma joprojām nepieslēdzās. Browserless attēls noklusēti izmanto 3000 portu, kas kolidēja ar OpenClaw iekšējo pārlūkprogrammas vadības pakalpojumu. Un kad pārslēdzāmies uz 9222 portu, OpenClaw ensurePortAvailable() to atklāja kā „izmantotu kaut ko citu” un atteicās pieslēgties, jo koplietotā tīkla vārdtelpā sidecar ports izskatās lokāls.

Risinājums bija izmantot poda IP adresi (caur Kubernetes Downward API) nevis localhost CDP URL. Ne-loopback adrese saka OpenClaw izmantot remote/attach-only režīmu: pieslēgties tam, kas jau darbojas, nevis mēģināt palaist savu pārlūkprogrammu. PR #183 to atrisināja.

Rezultāts: pieci labojumi, automātiski pielietoti

Katra no šīm avārijām mums kaut ko iemācīja. Pašreizējais operators kodē visu:

Sidecar izolācija. Chromium darbojas savā konteinerā. Nav snap. Nav Playwright. Nav headless karodziņu. Browserless attēls par visu parūpējas.

Atvēlēti resursi. Sidecar saņem savus CPU un atmiņas limitus (250m-1000m CPU, 512Mi-2Gi RAM noklusēti, konfigurējams). Ja Chromium pārsniedz savu atmiņas limitu, Kubernetes restartē tikai pārlūkprogrammas konteineru. Jūsu aģents turpina darboties.

Koplietotā atmiņa. Operators automātiski pievieno 1 GB atmiņā balstītu sējumu /dev/shm. Nav nepieciešama Docker shm_size konfigurācija.

Portu maršrutēšana. Poda IP CDP URL aktivizē attālo režīmu. OpenClaw pieslēdzas sidecar nevis mēģina aizņemt portu. ensurePortAvailable() konflikts pazūd.

Iebūvēta anti-bot noteikšana. Daudzas tīmekļa vietnes atklāj noklusējuma headless Chromium un bloķē automatizāciju. Operators atbalsta extraArgs Chromium sidecar, lai jūs varētu nodot karodziņus kā --disable-blink-features=AutomationControlled un pielāgotus user agentus nebūvējot pielāgotu konteinera attēlu:

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"

Drošība bez kompromisiem. Visas Linux spējas noņemtas, privilēģiju eskalācija atspējota, seccomp RuntimeDefault, ne-root UID 999. Nav --no-sandbox kā root.

Ko tas nozīmē jums

Ja palaižat OpenClaw VPS un pārlūkprogramma darbojas, apsveicam. Esat navigējuši cauri pieciem atšķirīgiem kļūmes režīmiem un iznākuši otrā pusē. Saglabājiet savu iestatīšanu. Dublējiet konfigurāciju.

Ja pārlūkprogramma nedarbojas, vai darbojas periodiski, vai esat noguruši no Chromium atkļūdošanas 5 dolāru VPS, padomājiet, cik vērts ir jūsu laiks.

OpenClaw.rocks palaiž katru aģentu Kubernetes ar iepriekš aprakstīto operatoru. Pārlūkprogrammas sidecar ir iepriekš konfigurēts. Atmiņa ir piešķirta. Porti ir maršrutēti. Drošība ir nostiprināta. Jūs neko neinstalējat, neko nekonfigurējat un neko neatkļūdojat.

Jūsu aģents saņem pārlūkprogrammu, kas darbojas. Katru reizi. Gatavs lietošanai.

Pieci labojumi kopsavilkumā

Ja vēlaties palikt pie pašmitināšanas, šeit ir pilns kontrolsaraksts:

  1. Aizvietojiet snap Chromium ar Google Chrome .deb paketi vai Playwright atsevišķo bināro failu
  2. Ieslēdziet headless režīmu: openclaw config set browser.headless true un browser.noSandbox true
  3. Piešķiriet 8 GB+ RAM vai pievienojiet 4 GB swap pārlūkprogrammas automatizācijai
  4. Pievienojiet koplietoto atmiņu Docker: shm_size: '2gb'
  5. Atsedziet visus trīs portus: gateway, pārlūkprogrammas vadība (gateway + 2) un paplašinājumu relejs (gateway + 3)

Vai izlaidiet sarakstu. Iegūstiet savu asistentu OpenClaw.rocks un ļaujiet mums rūpēties par infrastruktūru.