“VPS’imle devasa sorunlar yaşıyorum. OpenClaw’ı 3. veya 4. kez yeniden kuruyorum.”

Bu mesaj geçen ay OpenClaw Discord’da belirdi. Kullanıcı yalnız değildi. Topluluk kanallarını kaydırın ve aynı temanın düzinelerce varyasyonunu bulacaksınız: tarayıcı aracı başarısız oluyor, ajan Chromium’a erişemiyor, VPS’in belleği tükeniyor, dün her şey çalışıyordu bugün çalışmıyor.

Bunu okuyorsanız çünkü az önce “OpenClaw tarayıcı çalışmıyor VPS” araması yaptınız, doğru yerdesiniz. Bu yazı bozulan beş şeyi, neden sinir bozucu şekillerde etkileşime girdiklerini ve hepsini OpenClaw.rocks Kubernetes operatöründe nasıl çözdüğümüzü açıklıyor, böylece tarayıcı kurulumu hakkında bir daha düşünmenize gerek kalmaz.

Herkesin gördüğü hata

OpenClaw topluluğundaki en yaygın hata mesajı şudur:

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

Ubuntu, Debian, Docker, Hetzner, Hostinger, GCP ve OpenClaw’ı tarayıcı otomasyonuyla çalıştırmaya çalışan her yerde ortaya çıkıyor. Gateway logları “Browser control service ready.” diyor. Ama ajan tarayıcıyı kullanmaya çalıştığında zaman aşımına uğruyor.

Hata genel. Nedenler değil. En az beş farklı arıza modu var ve dışarıdan hepsi aynı görünüyor.

Arıza 1: Snap Chromium ve AppArmor duvarı

Yeni kurulmuş bir Ubuntu 22.04+ sunucuda which chromium-browser /usr/bin/chromium-browser döndürür. Doğru görünüyor. Değil.

Ubuntu 22.04’ten beri varsayılan Chromium paketi bir snap. OpenClaw gateway bu ikili dosyayı systemd servisi aracılığıyla başlatmaya çalıştığında, AppArmor’un kısıtlama katmanı onu engelliyor. Snap paketi, Chrome DevTools Protocol (CDP) hata ayıklama portlarını sandbox üzerinden bağlayamıyor. İkili dosya başlıyor, çalışıyor gibi görünüyor, sonra OpenClaw’ın ihtiyaç duyduğu portu sessizce açamıyor.

Loglarda “Failed to start Chrome CDP on port 18800” göreceksiniz, bazen hiçbir şey görmezsiniz. Tarayıcı işlemi başlıyor ve tek bir log satırı yazmadan ölüyor.

Çözüm Google Chrome’un .deb paketini kurmak veya ~/.cache/ms-playwright/ konumundan Playwright’ın bağımsız Chromium ikili dosyasını kullanmaktır. Her ikisi de snap sandbox’ını atlar. Ama çözüm bariz değil. OpenClaw’ın tarayıcı algılaması standart yolları sırayla tarar, snap ikili dosyasını önce bulur ve kullanmaya çalışır. GitHub issue #4978 tam açıklamayı içerir.

Arıza 2: Ekran varsayan headless varsayılanları

OpenClaw, tarayıcı varsayılanları olarak headless: false ve noSandbox: false ile gelir. Bu, ekranı olan bir Mac veya Windows makinede mantıklı. VPS’te ekran yok. Açık yapılandırma olmadan Chromium, var olmayan bir ekran sunucusunda pencere açmaya çalışır.

İki yapılandırma değişikliği bunu çözer:

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

Çoğu VPS rehberi bunu belirtir. Ama standart OpenClaw kurulum talimatlarını izliyorsanız, bu satırların hiçbiri görünmez. Kurarsınız, tarayıcıyı denersiniz, başarısız olur. Hatayı ararsınız. Bir blog yazısı bulursunuz. Yapılandırmayı değiştirirsiniz. Yeniden başlatırsınız. Ve üçüncü arızaya gelirsiniz.

Arıza 3: Görünmez OOM kill

Birkaç açık sayfası olan tek bir Chromium sekmesi 2 ila 4 GB RAM tüketir. 4 GB VPS’te OpenClaw’ın kendisi, işletim sistemi ve çalışan diğer servisler için neredeyse hiçbir şey kalmaz.

Linux belleği tükendiğinde, çekirdeğin OOM killer’ı en çok bellek tüketen işlemi sonlandırır. Bu Chromium’dur. İşlem ölür. OpenClaw tarayıcı zaman aşımı kaydeder. Çökme raporu yok, yığın izi yok, belleğin sorun olduğuna dair bir belirti yok.

Bu sorunun daha ince bir versiyonu da var. Chromium her sekme için alt renderer işlemleri başlatır. Bunlar düzgün temizlenmezse birikir. Bir GitHub issue, yeterli yedek alanı olması gereken bir VPS’te 3,8 GB RAM tüketen 39 yetim renderer işlemi belgeledi.

Sonradan dmesg | grep -i "oom\|killed\|chromium" ile kontrol edebilirsiniz, ama çoğu insan oraya bakmayı düşünmez. OpenClaw’ı yeniden başlatırlar, birkaç dakika çalışır ve sonra tekrar olur.

Resmi sunucu gereksinimleri sayfası temel kurulum için minimum 4 GB önerir. Ama bu rakam tarayıcı otomasyonu olmadığını varsayar. Tarayıcı etkinken 8 GB gerçekçi minimumdur. Hetzner’de bu cpx22 (5 $/ay) ve cpx42 (17 $/ay) arasındaki farktır.

Arıza 4: Docker’ın eksik paylaşılan belleği

OpenClaw’ı Docker’da çalıştırıyorsanız (VPS dağıtımlarında yaygın), bir tuzak daha var. Docker’ın varsayılan /dev/shm’si 64 MB. Chromium, işlemler arası iletişim için paylaşılan bellek kullanır. Tükendiğinde sekmeler sessizce çöker veya boş sayfalar gösterir.

Çözüm docker-compose.yml’de bir satır:

shm_size: '2gb'

Veya açıkça bağlayın:

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

Bu OpenClaw kurulum rehberinde belgelenmemiş. Docker’a özgü bir davranıştır ve Chromium kullanan her uygulamayı etkiler, ama daha önce Docker’da headless tarayıcılar dağıtmadıysanız bunu arayacağınızı bilmezdiniz.

Arıza 5: Kimsenin uyarmadığı port çarpışmaları

OpenClaw’ın tarayıcı kontrol servisi gateway’den ayrı bir portta çalışır. Varsayılan olarak gateway portu artı 2’dir. Gateway’iniz 18789’daysa, tarayıcı kontrol servisi 18791’de, uzantı aktarıcı 18792’de olmalıdır.

Docker’da sadece 18789 portunu açarsanız, tarayıcı kontrol servisi konteyner dışından erişilemez. Daha kötüsü, gateway 18791 portu hiç bağlanmasa bile “Browser control service ready” kaydeder. Issue #17584 bunu yanlış modülü içe aktaran gateway’e kadar izledi: HTTP sunucusunu başlatmadan “ready” mesajını kaydeden bir modül. Log her şeyin yolunda olduğunu söylüyor. Port ölü.

Kubernetes’te, aynı pod’daki başka bir konteyner zaten 9222 portunu (standart CDP portu) kullanıyorsa, OpenClaw’ın ensurePortAvailable() fonksiyonu portu meşgul olarak algılar ve bağlanmayı reddeder, meşgul eden OpenClaw’ın iletişim kurması gereken tam o Chromium örneği olsa bile.

GitHub issue #10994 kullanıcının VPS kurulumunun doğru çalıştığı bir vakayı belgeliyor. Sonra birkaç otomatik eylemden sonra CDP portu takıldı. Tek çözüm portu tutan başıboş Chromium işlemlerini bulup öldürmekti.

Bu arızalar neden birikim yapar

Bu beş sorunun her birinin bilinen bir çözümü var. Ama etkileşime giriyorlar. Snap sorununu çözersiniz ve headless varsayılanına çarparsınız. Yapılandırmayı düzeltirsiniz ve Chromium başlar. On dakika çalışır, sonra OOM killer vurur. Swap alanı eklersiniz ve şimdi Docker’ın paylaşılan bellek limiti sessiz render hataları yaratır. Bunu düzeltirsiniz ve 18791 portunun açılmadığını keşfedersiniz.

Hata ayıklama döngüsü şöyle görünür: hata ara, kısmi düzeltme bul, düzeltmeyi uygula, sonraki hataya çarp, tekrarla. Bir Discord kullanıcısı tüm işletim sistemini “3. veya 4. kez” yeniden kurduğunu anlattı. Bir diğeri tam kurulum sandığı şeyden sonra tarayıcının “kararsız” olduğunu bildirdi. Üçüncü biri basitçe “Browser tool consistently fails on VPS” başlıklı bir issue açtı.

Sorun her bir düzeltmenin zor olması değil. Sorun beş tane olması, belirli işletim sisteminize, paket yöneticinize, konteyner çalışma zamanınıza ve VPS sağlayıcınıza bağlı olmaları ve zincirdeki tek bir hata tarayıcının çalışmadığı anlamına gelmesi.

OpenClaw ekibi ilgili hataları istikrarlı bir şekilde düzelttiği için takdiri hak ediyor. Yanıltıcı “ready” logu, yetim renderer temizliği ve CDP port işleme son sürümlerde iyileşti. Ama upstream düzeltmeler OpenClaw kodundaki semptomları ele alıyor. Sunucunuza doğru Chromium ikili dosyasını kuramaz, Docker paylaşılan belleğinizi yapılandıramaz veya tarayıcı otomasyonu için yeterli RAM ayıramaz. Bunlar sizin sorumluluğunuzda.

Chromium’u nasıl üç kez bozduk (ve ne öğrendik)

Her OpenClaw.rocks ajanını açık kaynak operatörümüzle Kubernetes üzerinde çalıştırıyoruz. Tarayıcı sidecar’ının düzgün çalışması haftalar aldı. Yukarıda açıklanan her sorunun kendi versiyonumuza rastladık, artı sadece konteyner orkestrasyon bağlamında ortaya çıkan birkaç tane.

Fikir basitti: Chromium’u OpenClaw’ın yanında ayrı bir konteyner olarak çalıştırın, CDP üzerinden bağlayın. Custom Resource’da tek satır ve tarayıcı sadece çalışır.

spec:
  chromium:
    enabled: true

İşte bu tek satır gerçekte böyle oluştu.

Çökme 1: Yanlış kullanıcı, salt okunur dosya sistemi

İlk denememiz Chromium konteynerini UID 1001 olarak salt okunur kök dosya sistemiyle çalıştırdı. Güvenlik en iyi uygulaması. Ve tamamen bozuk. Browserless imajı UID 999 (blessuser) bekliyor ve Node.js başlangıçta os.userInfo() çağırıyor; UID’nin /etc/passwd girdisi yoksa ENOENT ile başarısız oluyor. UID’yi düzelttikten sonra bile salt okunur dosya sistemi Chrome’un geçici dosya yazmasını engelledi. Sidecar her başlangıçta tek bir log satırı yazmadan çöküyordu. Issue #12 tam hikayeyi içerir.

Çökme 2: WebSocket güvenlik duvarı

Konteyner sonunda çalışırken Chromium aktifti, CDP 9222 portunda yanıt veriyordu, ama OpenClaw kullanmayı reddetti. Gateway pod’un LAN IP’sine bağlanıyordu (Kubernetes Service yönlendirmesi için gerekli) ve OpenClaw’ın güvenlik katmanı düz metin ws:// bağlantılarını loopback olmayan adreslere engelliyordu: “SECURITY ERROR: Gateway URL uses plaintext ws:// to a non-loopback address. Both credentials and chat data would be exposed to network interception.”

Meşru bir güvenlik kontrolü. Ama Kubernetes pod’unda tüm konteynerler ağ namespace’ini paylaşır. Aralarındaki trafik asla düğümü terk etmez. OpenClaw’ın güvenlik kontrolünü değiştiremezdik, bu yüzden tüm arayüzlerde dinleyen ve gateway’e loopback üzerinden yönlendiren bir nginx reverse proxy sidecar ekledik. Gateway güvende kalır. Service erişilebilir kalır. Issue #135 hata ayıklamayı belgeliyor.

Çökme 3: Port 3000 çarpışması

Chromium çalışıyordu. Gateway proxy edilmişti. Ama tarayıcı hala bağlanmıyordu. Browserless imajı varsayılan olarak 3000 portunu kullanıyor, bu OpenClaw’ın dahili tarayıcı kontrol servisiyle çarpışıyordu. 9222 portuna geçtiğimizde OpenClaw’ın ensurePortAvailable() bunu “başka bir şey tarafından kullanılıyor” olarak algıladı ve bağlanmayı reddetti, çünkü paylaşılan ağ namespace’inde sidecar’ın portu yerel görünüyor.

Çözüm, CDP URL’si için localhost yerine pod’un IP adresini (Kubernetes Downward API aracılığıyla) kullanmaktı. Loopback olmayan bir adres OpenClaw’a remote/attach-only modunu kullanmasını söyler: kendi tarayıcısını başlatmaya çalışmak yerine zaten çalışana bağlanır. PR #183 bunu çözdü.

Sonuç: otomatik uygulanan beş düzeltme

Bu çökmelerden her biri bize bir şey öğretti. Mevcut operatör hepsini kodlar:

Sidecar izolasyonu. Chromium kendi konteynerinde çalışır. Snap yok. Playwright yok. Headless bayrakları yok. Browserless imajı her şeyle ilgilenir.

Ayrılmış kaynaklar. Sidecar kendi CPU ve bellek limitlerine sahiptir (varsayılan 250m-1000m CPU, 512Mi-2Gi RAM, yapılandırılabilir). Chromium bellek limitini aşarsa, Kubernetes sadece tarayıcı konteynerini yeniden başlatır. Ajanınız çalışmaya devam eder.

Paylaşılan bellek. Operatör otomatik olarak /dev/shm’ye 1 GB bellekli volume bağlar. Docker shm_size yapılandırması gerekmez.

Port yönlendirme. CDP URL’si için pod IP’si uzak modu etkinleştirir. OpenClaw portu almaya çalışmak yerine sidecar’a bağlanır. ensurePortAvailable() çakışması kaybolur.

Yerleşik anti-bot algılama. Birçok web sitesi varsayılan headless Chromium’u algılar ve otomasyonu engeller. Operatör Chromium sidecar’ında extraArgs destekler, böylece özel konteyner imajı oluşturmadan --disable-blink-features=AutomationControlled gibi bayraklar ve özel user agent’lar geçirebilirsiniz:

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"

Taviz vermeden güvenlik. Tüm Linux yetenekleri kaldırıldı, ayrıcalık yükseltme devre dışı, seccomp RuntimeDefault, root olmayan UID 999. Root olarak --no-sandbox yok.

Sizin için ne anlama geliyor

VPS’te OpenClaw çalıştırıyorsanız ve tarayıcı çalışıyorsa, tebrikler. Beş farklı arıza modundan geçip diğer tarafa ulaştınız. Kurulumunuzu koruyun. Yapılandırmanızı yedekleyin.

Tarayıcı çalışmıyorsa, veya kesintili çalışıyorsa, veya 5 dolarlık VPS’te Chromium hata ayıklamaktan bıktıysanız, zamanınızın ne kadar değerli olduğunu düşünün.

OpenClaw.rocks her ajanı yukarıda açıklanan operatörle Kubernetes’te çalıştırır. Tarayıcı sidecar’ı önceden yapılandırılmış. Bellek ayrılmış. Portlar yönlendirilmiş. Güvenlik sertleştirilmiş. Hiçbir şey kurmaz, yapılandırmaz veya hata ayıklamazsınız.

Ajanınız çalışan bir tarayıcı alır. Her seferinde. Kutudan çıkar çıkmaz.

Beş düzeltme özeti

Kendi barındırmanızda kalmak istiyorsanız, işte tam kontrol listesi:

  1. Snap Chromium’u değiştirin: Google Chrome .deb paketi veya Playwright’ın bağımsız ikili dosyasıyla
  2. Headless modunu etkinleştirin: openclaw config set browser.headless true ve browser.noSandbox true
  3. 8 GB+ RAM ayırın veya tarayıcı otomasyonu için 4 GB swap ekleyin
  4. Paylaşılan belleği bağlayın: Docker’da shm_size: '2gb'
  5. Üç portu da açın: gateway, tarayıcı kontrol (gateway + 2) ve uzantı aktarıcı (gateway + 3)

Veya listeyi atlayın. OpenClaw.rocks’ta asistanınızı edinin ve altyapıyı bize bırakın.