„Mám obrovské problémy se svým VPS. Přeinstalovávám OpenClaw po 3. nebo 4. krát.”

Tato zpráva se objevila na OpenClaw Discordu minulý měsíc. Uživatel nebyl sám. Projděte komunitní kanály a najdete desítky variací na stejné téma: nástroj prohlížeče selhává, agent se nedokáže připojit k Chromiu, VPS dochází paměť, včera všechno fungovalo a dnes ne.

Pokud čtete tento článek, protože jste právě hledali „OpenClaw prohlížeč nefunguje VPS”, jste na správném místě. Tento příspěvek vysvětluje pět věcí, které se pokazí, proč spolu interagují frustrujícím způsobem, a jak jsme je všechny vyřešili v operátoru Kubernetes OpenClaw.rocks, abyste se už nikdy nemuseli zabývat nastavením prohlížeče.

Chyba, kterou vidí všichni

Nejčastější chybová zpráva v komunitě OpenClaw je tato:

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

Objevuje se na Ubuntu, Debianu, v Dockeru, na Hetzner, Hostinger, GCP a všude jinde, kde se lidé pokoušejí provozovat OpenClaw s automatizací prohlížeče. Logy gateway hlásí „Browser control service ready.” Ale když se agent pokusí použít prohlížeč, vyprší časový limit.

Chyba je obecná. Příčiny ne. Existuje nejméně pět odlišných módů selhání a zvenčí vypadají všechny identicky.

Selhání 1: Snap Chromium a zeď AppArmor

Na čerstvém serveru Ubuntu 22.04+ vrací which chromium-browser cestu /usr/bin/chromium-browser. Vypadá to správně. Není.

Od Ubuntu 22.04 je výchozí balíček Chromium snap. Když se gateway OpenClaw pokusí spustit tento binární soubor přes službu systemd, omezovací vrstva AppArmor ho zablokuje. Balíček snap nemůže vázat ladicí porty Chrome DevTools Protocol (CDP) přes sandbox. Binární soubor se spustí, zdá se, že běží, a pak tiše selže při otevření portu, který OpenClaw potřebuje.

V logách uvidíte „Failed to start Chrome CDP on port 18800”, nebo někdy vůbec nic. Proces prohlížeče se spustí a zemře, než zapíše jedinou řádku logu.

Řešením je nainstalovat balíček .deb Google Chrome nebo použít samostatný binární soubor Chromium od Playwright z ~/.cache/ms-playwright/. Oba obcházejí sandbox snap. Ale řešení není zřejmé. Detekce prohlížeče v OpenClaw skenuje standardní cesty v pořadí, najde binární soubor snap jako první a pokusí se ho použít. GitHub issue #4978 obsahuje úplný popis.

Selhání 2: Výchozí hodnoty headless předpokládající displej

OpenClaw se dodává s headless: false a noSandbox: false jako výchozími hodnotami prohlížeče. To dává smysl na Macu nebo počítači s Windows s displejem. Na VPS žádný displej není. Bez explicitní konfigurace se Chromium pokusí otevřít okno na displeji, který neexistuje.

Dvě změny konfigurace to vyřeší:

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

Většina VPS průvodců to zmiňuje. Ale pokud postupujete podle standardních instalačních pokynů OpenClaw, žádný z těchto řádků se neobjeví. Nainstalujete, vyzkoušíte prohlížeč, selže. Hledáte chybu. Najdete blogový příspěvek. Změníte konfiguraci. Restartujete. A pak přijde selhání číslo tři.

Selhání 3: Neviditelný OOM kill

Jediná karta Chromium s několika otevřenými stránkami spotřebovává 2 až 4 GB RAM. Na VPS se 4 GB nezůstane téměř nic pro samotný OpenClaw, operační systém a jakékoli další běžící služby.

Když Linuxu dojde paměť, OOM killer jádra ukončí proces s největší spotřebou paměti. To je Chromium. Proces zemře. OpenClaw zaloguje timeout prohlížeče. Žádný crash report, žádný stack trace, žádná indikace, že problémem byla paměť.

Existuje i subtilnější verze tohoto problému. Chromium spouští podřízené renderer procesy pro každou kartu. Pokud nejsou správně vyčištěny, hromadí se. Jeden GitHub issue zdokumentoval 39 osiřelých renderer procesů spotřebovávajících 3,8 GB RAM na VPS, které mělo mít dostatek rezervy.

Můžete to zkontrolovat zpětně pomocí dmesg | grep -i "oom\|killed\|chromium", ale většina lidí by nenapadlo se tam podívat. Restartují OpenClaw, funguje pár minut, a pak se to stane znovu.

Oficiální stránka serverových požadavků doporučuje minimálně 4 GB pro základní konfiguraci. Ale toto číslo předpokládá absenci automatizace prohlížeče. Se zapnutým prohlížečem je 8 GB realistické minimum. Na Hetzner je to rozdíl mezi cpx22 (5 $/měs.) a cpx42 (17 $/měs.).

Selhání 4: Chybějící sdílená paměť Dockeru

Pokud provozujete OpenClaw v Dockeru (běžné u VPS nasazení), je tu další past. Výchozí /dev/shm Dockeru je 64 MB. Chromium používá sdílenou paměť pro meziprocesorovou komunikaci. Když dojde, karty tiše padají nebo renderují prázdné stránky.

Řešení je jeden řádek v docker-compose.yml:

shm_size: '2gb'

Nebo namontujte explicitně:

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

Toto není dokumentováno v průvodci nastavením OpenClaw. Je to chování specifické pro Docker, které ovlivňuje jakoukoli aplikaci používající Chromium, ale pokud jste nikdy nedeployovali headless prohlížeče v Dockeru, nevěděli byste, že to máte hledat.

Selhání 5: Kolize portů, na které nikdo neupozornil

Browser control service OpenClaw běží na samostatném portu od gateway. Výchozí je port gateway plus 2. Pokud váš gateway běží na 18789, browser control service by měla být na 18791 a extension relay na 18792.

V Dockeru, pokud vystavíte pouze port 18789, je browser control service nedostupná zvenčí kontejneru. Ještě hůř, gateway loguje „Browser control service ready” i když se port 18791 nikdy skutečně nenavíže. Issue #17584 vystopoval problém ke gateway importujícímu špatný modul: takový, který loguje zprávu „ready” bez spuštění HTTP serveru. Log říká, že je vše v pořádku. Port je mrtvý.

V Kubernetes, pokud jiný kontejner ve stejném podu již používá port 9222 (standardní CDP port), funkce ensurePortAvailable() OpenClaw detekuje port jako obsazený a odmítne se připojit, i když je obsazující právě ta instance Chromium, se kterou by OpenClaw měl komunikovat.

GitHub issue #10994 dokumentuje případ, kdy nastavení VPS uživatele fungovalo správně. Pak po několika automatizovaných akcích se CDP port zasekl. Jediným řešením bylo najít a ukončit zatoulané procesy Chromium blokující port.

Proč se tato selhání kumulují

Každý z těchto pěti problémů má známé řešení. Ale vzájemně interagují. Vyřešíte problém snap a narazíte na výchozí hodnotu headless. Opravíte konfiguraci a Chromium se spustí. Běží deset minut, pak udeří OOM killer. Přidáte swap, a teď limit sdílené paměti Dockeru způsobuje tiché chyby renderování. Opravíte to a zjistíte, že port 18791 není vystavený.

Smyčka ladění vypadá takto: hledat chybu, najít částečné řešení, aplikovat řešení, narazit na další chybu, opakovat. Jeden uživatel Discordu popsal, že přeinstaloval celý operační systém „po 3. nebo 4. krát.” Jiný hlásil, že prohlížeč byl „nestabilní” po tom, co považoval za kompletní nastavení. Třetí otevřel issue s prostým názvem „Browser tool consistently fails on VPS.”

Problém není v tom, že by jednotlivá oprava byla obtížná. Problém je, že jich je pět, závisí na vašem konkrétním operačním systému, správci balíčků, container runtime a poskytovateli VPS, a jediná chyba v řetězci znamená, že prohlížeč nefunguje.

Tým OpenClaw si zaslouží uznání za stabilní opravování souvisejících bugů. Zavádějící log „ready”, čištění osiřelých rendererů a zpracování CDP portu se v posledních verzích zlepšily. Ale upstream opravy řeší symptomy uvnitř kódu OpenClaw. Nemohou nainstalovat správný binární soubor Chromium na váš server, nakonfigurovat sdílenou paměť Dockeru nebo přidělit dostatek RAM pro automatizaci prohlížeče. To zůstává vaší odpovědností.

Jak jsme rozbili Chromium třikrát (a co jsme se naučili)

Každého agenta OpenClaw.rocks provozujeme na Kubernetes s naším open source operátorem. Sidecar prohlížeče nám trvalo týdny, než začal správně fungovat. Narazili jsme na vlastní verzi každého výše popsaného problému plus několik, které se projeví pouze v kontextu orchestrace kontejnerů.

Myšlenka byla jednoduchá: provozovat Chromium jako samostatný kontejner vedle OpenClaw, připojený přes CDP. Jeden řádek v Custom Resource a prohlížeč prostě funguje.

spec:
  chromium:
    enabled: true

Takto ten jeden řádek skutečně vznikl.

Pád 1: Špatný uživatel, souborový systém pouze pro čtení

Náš první pokus spouštěl kontejner Chromium jako UID 1001 se souborovým systémem root pouze pro čtení. Bezpečnostní best practice. A kompletně rozbitý. Image browserless očekává UID 999 (blessuser) a Node.js při startu volá os.userInfo(), což selže s ENOENT, když UID nemá záznam v /etc/passwd. I po opravě UID souborový systém pouze pro čtení bránil Chrome v zápisu dočasných souborů. Sidecar padal při každém startu, než zapsal jedinou řádku logu. Issue #12 obsahuje celý příběh.

Pád 2: WebSocket bezpečnostní zeď

S konečně běžícím kontejnerem bylo Chromium aktivní, CDP odpovídal na portu 9222, ale OpenClaw ho odmítl používat. Gateway se navázal na LAN IP podu (nutné pro routing Kubernetes Service) a bezpečnostní vrstva OpenClaw blokovala nešifrovaná ws:// připojení na non-loopback adresy: „SECURITY ERROR: Gateway URL uses plaintext ws:// to a non-loopback address. Both credentials and chat data would be exposed to network interception.”

Legitimní bezpečnostní kontrola. Ale v Kubernetes podu všechny kontejnery sdílejí síťový namespace. Provoz mezi nimi nikdy neopustí uzel. Nemohli jsme změnit bezpečnostní kontrolu OpenClaw, proto jsme přidali nginx reverse proxy sidecar, který naslouchá na všech rozhraních a předává na gateway na loopback. Gateway zůstává bezpečný. Service zůstává dosažitelný. Issue #135 dokumentuje ladění.

Pád 3: Kolize portu 3000

Chromium běžel. Gateway měl proxy. Ale prohlížeč se stále nepřipojoval. Image browserless používá výchozí port 3000, který kolidoval s interní browser control service OpenClaw. A když jsme přepnuli na port 9222, funkce ensurePortAvailable() OpenClaw ho detekovala jako „používaný něčím jiným” a odmítla připojení, protože ve sdíleném síťovém namespace port sidecaru vypadá jako lokální.

Řešením bylo použití IP adresy podu (přes Kubernetes Downward API) místo localhost pro CDP URL. Non-loopback adresa říká OpenClaw, aby použil režim remote/attach-only: připojit se k tomu, co již běží, místo pokusu spustit vlastní prohlížeč. PR #183 to vyřešil.

Výsledek: pět oprav, aplikovaných automaticky

Každý z těchto pádů nás něco naučil. Aktuální operátor kóduje vše:

Izolace sidecar. Chromium běží ve vlastním kontejneru. Žádný snap. Žádný Playwright. Žádné headless flagy. Image browserless se o vše postará.

Dedikované zdroje. Sidecar dostává vlastní limity CPU a paměti (250m-1000m CPU, 512Mi-2Gi RAM výchozí, konfigurovatelné). Pokud Chromium překročí svůj limit paměti, Kubernetes restartuje pouze kontejner prohlížeče. Váš agent běží dál.

Sdílená paměť. Operátor automaticky montuje 1 GB paměťově zálohovaný svazek na /dev/shm. Žádná konfigurace Docker shm_size.

Směrování portů. IP podu pro CDP URL aktivuje vzdálený režim. OpenClaw se připojí k sidecaru místo pokusu zabrat port. Konflikt ensurePortAvailable() zmizí.

Vestavěná anti-bot detekce. Mnoho webů detekuje výchozí headless Chromium a blokuje automatizaci. Operátor podporuje extraArgs na sidecaru Chromium, takže můžete předávat flagy jako --disable-blink-features=AutomationControlled a vlastní user agenty bez sestavení vlastního image kontejneru:

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"

Bezpečnost bez kompromisů. Všechny Linux capabilities odebrány, eskalace oprávnění zakázána, seccomp RuntimeDefault, non-root UID 999. Žádné --no-sandbox jako root.

Co to znamená pro vás

Pokud provozujete OpenClaw na VPS a prohlížeč funguje, gratulujeme. Prošli jste pěti odlišnými módy selhání a dostali se na druhou stranu. Ponechte si své nastavení. Zálohujte konfiguraci.

Pokud prohlížeč nefunguje, nebo funguje sporadicky, nebo vás unavilo ladit Chromium na VPS za 5 dolarů, zamyslete se nad tím, kolik stojí váš čas.

OpenClaw.rocks provozuje každého agenta na Kubernetes s operátorem popsaným výše. Sidecar prohlížeče je předkonfigurovaný. Paměť je přidělena. Porty jsou směrovány. Bezpečnost je posílena. Nic neinstalujete, nic nekonfigurujete a nic neladíte.

Váš agent dostane prohlížeč, který funguje. Pokaždé. Ihned po nasazení.

Pět oprav v souhrnu

Pokud chcete zůstat u self-hostingu, zde je kompletní checklist:

  1. Nahraďte snap Chromium balíčkem .deb Google Chrome nebo samostatným binárním souborem Playwright
  2. Zapněte headless režim: openclaw config set browser.headless true a browser.noSandbox true
  3. Přidělte 8 GB+ RAM nebo přidejte 4 GB swap pro automatizaci prohlížeče
  4. Namontujte sdílenou paměť v Dockeru: shm_size: '2gb'
  5. Vystavte všechny tři porty: gateway, browser control (gateway + 2) a extension relay (gateway + 3)

Nebo checklist přeskočte. Získejte svého asistenta na OpenClaw.rocks a nechte infrastrukturu na nás.