“Valtavia ongelmia VPS:ni kanssa. Asennan OpenClawia uudelleen nyt 3. tai 4. kertaa.”

Tämä viesti ilmestyi OpenClawn Discordiin viime kuussa. Käyttäjä ei ollut ainoa. Selaa yhteisökanavia läpi, niin löydät kymmeniä muunnelmia samasta aiheesta: selaintyökalu epäonnistuu, agentti ei pääse Chromiumiin käsiksi, VPS:n muisti loppuu, kaikki toimi eilen mutta nyt ei.

Jos luet tätä, koska hait juuri “OpenClaw selain ei toimi VPS”, olet oikeassa paikassa. Tämä artikkeli selittää viisi asiaa, jotka menevät pieleen, miksi ne yhdessä aiheuttavat turhautumista, ja miten ratkaisimme ne kaikki OpenClaw.rocks Kubernetes-operaattorissa, jotta sinun ei tarvitse enää koskaan miettiä selaimen asetuksia.

Virhe, jonka kaikki näkevät

Yleisin virheilmoitus OpenClaw-yhteisössä on tämä:

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

Se ilmenee Ubuntussa, Debianissa, Dockerissa, Hetznerillä, Hostingerilla, GCP:ssä ja kaikkialla muualla, missä OpenClawia yritetään käyttää selainautomaation kanssa. Gateway-lokit sanovat “Browser control service ready.” Mutta kun agentti yrittää käyttää selainta, tulee aikakatkaisu.

Virhe on yleisluonteinen. Syyt eivät ole. On vähintään viisi erillistä vikatilaaa, ja ulkopuolelta ne näyttävät identtisiltä.

Vika 1: Snap Chromium ja AppArmor-muuri

Tuoreella Ubuntu 22.04+ -palvelimella which chromium-browser palauttaa polun /usr/bin/chromium-browser. Se näyttää oikealta. Ei ole.

Ubuntu 22.04:stä lähtien oletusarvoinen Chromium-paketti on snap. Kun OpenClawn gateway yrittää käynnistää tämän binäärin systemd-palvelun kautta, AppArmorin rajoituskerros estää sen. Snap-paketti ei pysty sitomaan Chrome DevTools Protocol (CDP) -debug-portteja hiekkalaatikon läpi. Binääri käynnistyy, näyttää toimivan, ja epäonnistuu sitten äänettömästi avaamaan portin, jota OpenClaw tarvitsee.

Lokeissa näkyy “Failed to start Chrome CDP on port 18800” tai joskus ei mitään. Selainprosessi käynnistyy ja kuolee ennen kuin se kirjoittaa yhtäkään lokirivi.

Ratkaisu on asentaa Google Chromen .deb-paketti tai käyttää Playwrightin itsenäistä Chromium-binääriä hakemistosta ~/.cache/ms-playwright/. Molemmat ohittavat snap-hiekkalaatikon. Mutta ratkaisu ei ole ilmeinen. OpenClawn selaintunnistus skannaa vakiopolkuja järjestyksessä, löytää snap-binäärin ensin ja yrittää käyttää sitä. GitHub issue #4978 sisältää täydellisen kuvauksen.

Vika 2: Headless-oletusarvot, jotka olettavat näytön

OpenClaw toimitetaan asetuksilla headless: false ja noSandbox: false selaimen oletusarvoina. Tämä on järkevää Macilla tai Windows-koneella, jossa on näyttö. VPS:llä ei ole näyttöä. Ilman nimenomaista konfiguraatiota Chromium yrittää avata ikkunan näyttöpalvelimelle, jota ei ole olemassa.

Kaksi konfiguraatiomuutosta korjaa ongelman:

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

Useimmat VPS-oppaat mainitsevat tämän. Mutta jos seuraat OpenClawn vakioasennusohjeita, kumpikaan rivi ei ilmesty. Asennat, kokeilet selainta, se epäonnistuu. Haet virhettä. Löydät blogikirjoituksen. Muutat asetuksia. Käynnistät uudelleen. Ja sitten tulee vika numero kolme.

Vika 3: Näkymätön OOM-tappo

Yksi Chromium-välilehti muutamalla avoimella sivulla kuluttaa 2-4 GB RAM-muistia. 4 GB:n VPS:llä ei jää juuri mitään OpenClawille itselleen, käyttöjärjestelmälle ja muille käynnissä oleville palveluille.

Kun Linuxilta loppuu muisti, ytimen OOM-killer lopettaa eniten muistia kuluttavan prosessin. Se on Chromium. Prosessi kuolee. OpenClaw kirjaa selaimen aikakatkaisun. Ei kaatumisraporttia, ei pinojälkeä, ei mitään viitteitä siitä, että muisti oli ongelma.

Tästä ongelmasta on myös hienovaraisempi versio. Chromium käynnistää lapsirenderöintiprosesseja jokaiselle välilehdelle. Jos niitä ei siivota kunnolla, ne kasaantuvat. Eräs GitHub issue dokumentoi 39 orpoa renderöintiprosessia, jotka kuluttivat 3,8 GB RAM:ia VPS:llä, jolla piti olla runsaasti varaa.

Voit tarkistaa jälkikäteen komennolla dmesg | grep -i "oom\|killed\|chromium", mutta useimmat eivät tule ajatelleeksi katsoa sieltä. He käynnistävät OpenClawn uudelleen, se toimii muutaman minuutin, ja sitten se tapahtuu taas.

Virallinen palvelinvaatimussivu suosittelee vähintään 4 GB perusasennukseen. Mutta tämä luku olettaa, ettei selainautomaatiota ole käytössä. Selaimen ollessa päällä 8 GB on realistinen minimi. Hetznerillä tämä on ero cpx22:n ($5/kk) ja cpx42:n ($17/kk) välillä.

Vika 4: Dockerin puuttuva jaettu muisti

Jos ajat OpenClawia Dockerissa (yleistä VPS-asennuksissa), on vielä yksi ansa. Dockerin oletus-/dev/shm on 64 MB. Chromium käyttää jaettua muistia prosessien väliseen viestintään. Kun se loppuu, välilehdet kaatuvat äänettömästi tai renderöivät tyhjiä sivuja.

Ratkaisu on yksi rivi docker-compose.yml-tiedostossasi:

shm_size: '2gb'

Tai mounttaa se erikseen:

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

Tätä ei ole dokumentoitu OpenClawn asennusoppaassa. Se on Docker-kohtainen käyttäytyminen, joka vaikuttaa kaikkiin Chromiumia käyttäviin sovelluksiin, mutta ellet ole aiemmin asentanut headless-selaimia Dockeriin, et tietäisi etsiä sitä.

Vika 5: Porttitörmäykset, joista kukaan ei varoita

OpenClawn browser control service toimii erillisessä portissa gatewaystä. Oletuksena se on gateway-portti plus 2. Jos gatewatysi on portissa 18789, browser control servicen pitäisi olla portissa 18791 ja extension relayn portissa 18792.

Dockerissa, jos paljastat vain portin 18789, browser control service on tavoittamattomissa kontin ulkopuolelta. Pahempaa, gateway kirjaa “Browser control service ready”, vaikka portti 18791 ei koskaan todellisuudessa sitoudu. Issue #17584 jäljitti tämän gatewayn tuomaan väärän moduulin: sellaisen, joka kirjaa “ready”-viestin käynnistämättä HTTP-palvelinta. Loki sanoo, että kaikki on kunnossa. Portti on kuollut.

Kubernetesissa, jos toinen kontti samassa podissa käyttää jo porttia 9222 (standardi CDP-portti), OpenClawn ensurePortAvailable()-funktio havaitsee portin varattuna ja kieltäytyy yhdistämästä, vaikka varaaja on juuri se Chromium-instanssi, jonka kanssa OpenClawn pitäisi kommunikoida.

GitHub issue #10994 dokumentoi tapauksen, jossa käyttäjän VPS-asennus toimi oikein. Sitten muutaman automatisoidun toiminnon jälkeen CDP-portti jumiutui. Ainoa ratkaisu oli löytää ja tappaa harhailevat Chromium-prosessit, jotka pitivät portista kiinni.

Miksi nämä viat kertautuvat

Jokaiseen näistä viidestä ongelmasta on tunnettu ratkaisu. Mutta ne vaikuttavat toisiinsa. Ratkaiset snap-ongelman ja törmäät headless-oletusarvoon. Korjaat konfiguraation ja Chromium käynnistyy. Se toimii kymmenen minuuttia, sitten OOM-killer iskee. Lisäät swap-tilaa, ja nyt Dockerin jaetun muistin raja aiheuttaa hiljaisia renderöintivirheitä. Korjaat sen ja huomaat, ettei portti 18791 ole paliastettu.

Virheenetsintäkierre näyttää tältä: hae virhettä, löydä osittainen korjaus, sovella korjausta, törmää seuraavaan virheeseen, toista. Eräs Discord-käyttäjä kuvasi asentaneensa koko käyttöjärjestelmänsä uudelleen “3. tai 4. kerran.” Toinen raportoi selaimen olevan “epävakaa” sen jälkeen, minkä hän uskoi olevan täydellinen asennus. Kolmas avasi issuen yksinkertaisella otsikolla “Browser tool consistently fails on VPS.”

Ongelma ei ole, että yksittäinen korjaus olisi vaikea. Ongelma on, että niitä on viisi, ne riippuvat sinun käyttöjärjestelmästäsi, paketinhallinnastasi, konttiympäristöstäsi ja VPS-tarjoajastasi, ja yksikin virhe ketjussa tarkoittaa, ettei selain toimi.

OpenClaw-tiimi ansaitsee tunnustusta siitä, että se korjaa vakaasti liittyviä bugeja. Harhaanjohtava “ready”-loki, orpojen renderöijien siivous ja CDP-portin käsittely ovat kaikki parantuneet viimeaikaisissa versioissa. Mutta ylävirran korjaukset käsittelevät oireita OpenClawn koodissa. Ne eivät voi asentaa oikeaa Chromium-binääriä palvelimellesi, konfiguroida Docker-jaettua muistia tai varata tarpeeksi RAM:ia selainautomaatioon. Se jää sinun vastuullesi.

Miten rikoimme Chromiumin kolmesti (ja mitä opimme)

Ajamme jokaista OpenClaw.rocks-agenttia Kubernetesissa avoimen lähdekoodin operaattorillamme. Selain-sidecarin saaminen toimimaan vei viikkoja. Kohtasimme oman versiomme jokaisesta yllä kuvatusta ongelmasta sekä muutamia, jotka ilmenevät vain konttien orkestroinnin yhteydessä.

Idea oli yksinkertainen: ajaa Chromiumia erillisenä konttina OpenClawn vieressä, yhdistettynä CDP:n kautta. Yksi rivi Custom Resourcessa ja selain vain toimii.

spec:
  chromium:
    enabled: true

Näin tämä yksi rivi syntyi käytännössä.

Kaatuminen 1: Väärä käyttäjä, vain luku -tiedostojärjestelmä

Ensimmäinen yrityksemme ajoi Chromium-konttia UID 1001:nä vain luku -juuritiedostojärjestelmällä. Turvallisuuden parhaita käytäntöjä. Ja täysin rikki. Browserless-kuva odottaa UID 999:ää (blessuser), ja Node.js kutsuu käynnistyessä os.userInfo():ta, joka epäonnistuu ENOENT-virheellä kun UID:lla ei ole /etc/passwd-merkintää. UID:n korjaamisen jälkeenkin vain luku -tiedostojärjestelmä esti Chromea kirjoittamasta väliaikaistiedostoja. Sidecar kaatui jokaisella käynnistyskerralla ennen yhdenkään lokirivin kirjoittamista. Issue #12 kertoo koko tarinan.

Kaatuminen 2: WebSocket-turvamuuri

Kontin vihdoin toimiessa Chromium oli pystyssä, CDP vastasi portissa 9222, mutta OpenClaw kieltäytyi käyttämästä sitä. Gateway sitoutui podin LAN-IP:hen (vaatimus Kubernetes Service -reititykselle), ja OpenClawn turvakerros esti selkokieliset ws://-yhteydet ei-loopback-osoitteisiin: “SECURITY ERROR: Gateway URL uses plaintext ws:// to a non-loopback address. Both credentials and chat data would be exposed to network interception.”

Oikeutettu turvatarkistus. Mutta Kubernetes-podissa kaikki kontit jakavat verkko-namespacen. Liikenne niiden välillä ei koskaan poistu nodelta. Emme voineet muuttaa OpenClawn turvatarkistusta, joten lisäsimme nginx reverse proxy -sidecarin, joka kuuntelee kaikilla rajapinnoilla ja välittää gatewaylle loopbackissa. Gateway pysyy turvallisena. Service pysyy tavoitettavissa. Issue #135 dokumentoi virheenetsinnän.

Kaatuminen 3: Portti 3000 -törmäys

Chromium toimi. Gateway oli proxattu. Mutta selain ei silti yhdistänyt. Browserless-kuva käyttää oletuksena porttia 3000, joka törmäsi OpenClawn sisäiseen browser control serviceen. Ja kun vaihdoimme porttiin 9222, OpenClawn ensurePortAvailable() havaitsi sen “jonkun muun käytössä” ja kieltäytyi yhdistämästä, koska jaetussa verkko-namespacessa sidecarin portti näyttää paikalliselta.

Ratkaisu oli käyttää podin IP-osoitetta (Kubernetes Downward API:n kautta) localhostin sijaan CDP-URL:ssa. Ei-loopback-osoite käskee OpenClawia käyttämään remote/attach-only-tilaa: yhdistää jo käynnissä olevaan selaimeen sen sijaan, että yrittäisi käynnistää omaa. PR #183 ratkaisi tämän.

Tulos: viisi korjausta, automaattisesti sovellettuina

Jokainen näistä kaatumisista opetti meille jotain. Nykyinen operaattori koodaa kaiken tämän:

Sidecar-eristys. Chromium toimii omassa kontissaan. Ei snapia. Ei Playwrightia. Ei headless-lippuja. Browserless-kuva hoitaa kaiken.

Dedikoitut resurssit. Sidecar saa omat CPU- ja muistirajat (250m-1000m CPU, 512Mi-2Gi RAM oletuksena, konfiguroitavissa). Jos Chromium ylittää muistirajansa, Kubernetes käynnistää uudelleen vain selainkontin. Agenttisi jatkaa toimintaansa.

Jaettu muisti. Operaattori mounttaa automaattisesti 1 GB:n muistipohjaisen taltion /dev/shm:ään. Ei Docker shm_size -konfiguraatiota tarvita.

Porttireititys. Podin IP CDP-URL:ssa aktivoi etätilan. OpenClaw yhdistää sidecariin sen sijaan, että yrittäisi varata porttia. ensurePortAvailable()-ristiriita katoaa.

Sisäänrakennettu anti-bot-tunnistus. Monet verkkosivustot tunnistavat oletus headless Chromiumin ja estävät automaation. Operaattori tukee extraArgs -parametreja Chromium-sidecarissa, joten voit antaa lippuja kuten --disable-blink-features=AutomationControlled ja mukautettuja user agentteja rakentamatta mukautettua konttikuvaa:

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"

Turvallisuus ilman kompromisseja. Kaikki Linux-kyvykkyydet poistettu, oikeuksien eskalaatio estetty, seccomp RuntimeDefault, ei-root UID 999. Ei --no-sandbox rootina.

Mitä tämä tarkoittaa sinulle

Jos ajat OpenClawia VPS:llä ja selain toimii, onnittelut. Olet navigoinut viiden erillisen vikatilan läpi ja selvinnyt toiselle puolelle. Pidä asennuksesi. Varmuuskopioi konfiguraatiosi.

Jos selain ei toimi, tai toimii satunnaisesti, tai olet kyllästynyt Chromiumin debuggaamiseen 5 dollarin VPS:llä, mieti mitä aikasi on arvoista.

OpenClaw.rocks ajaa jokaista agenttia Kubernetesissa yllä kuvatulla operaattorilla. Selain-sidecar on esikonfiguroitu. Muisti on varattu. Portit on reititetty. Turvallisuus on kovennettu. Et asenna mitään, konfiguroi mitään tai debuggaa mitään.

Agenttisi saa selaimen, joka toimii. Joka kerta. Suoraan paketista.

Viisi korjausta yhteenvetona

Jos haluat jatkaa itse hostaamista, tässä on täydellinen tarkistuslista:

  1. Korvaa snap Chromium Google Chromen .deb-paketilla tai Playwrightin itsenäisellä binäärillä
  2. Ota headless-tila käyttöön: openclaw config set browser.headless true ja browser.noSandbox true
  3. Varaa 8 GB+ RAM:ia tai lisää 4 GB swapia selainautomaatiota varten
  4. Mounttaa jaettu muisti Dockerissa: shm_size: '2gb'
  5. Paljasta kaikki kolme porttia: gateway, browser control (gateway + 2) ja extension relay (gateway + 3)

Tai ohita tarkistuslista. Hanki avustajasi OpenClaw.rocksista ja anna meidän hoitaa infrastruktuuri.