«Έχω τεράστια προβλήματα με το VPS μου. Επανεγκαθιστώ το OpenClaw για 3η ή 4η φορά.»

Αυτό το μήνυμα εμφανίστηκε στο Discord του OpenClaw τον περασμένο μήνα. Ο χρήστης δεν ήταν ο μόνος. Περιηγηθείτε στα κανάλια της κοινότητας και θα βρείτε δεκάδες παραλλαγές στο ίδιο θέμα: το εργαλείο browser αποτυγχάνει, ο agent δεν μπορεί να φτάσει το Chromium, το VPS εξαντλεί τη μνήμη, χθες όλα δούλευαν και σήμερα όχι.

Αν διαβάζετε αυτό επειδή μόλις αναζητήσατε «OpenClaw browser δεν λειτουργεί VPS», είστε στο σωστό μέρος. Αυτό το άρθρο εξηγεί τα πέντε πράγματα που χαλάνε, γιατί αλληλεπιδρούν με απογοητευτικούς τρόπους, και πώς τα λύσαμε όλα στον Kubernetes operator του OpenClaw.rocks ώστε να μη χρειαστεί ποτέ ξανά να ασχοληθείτε με τη ρύθμιση browser.

Το σφάλμα που βλέπουν όλοι

Το πιο συνηθισμένο μήνυμα σφάλματος στην κοινότητα OpenClaw είναι αυτό:

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

Εμφανίζεται σε Ubuntu, Debian, στο Docker, σε Hetzner, Hostinger, GCP και παντού αλλού όπου δοκιμάζουν το OpenClaw με αυτοματοποίηση browser. Τα logs του gateway λένε «Browser control service ready.» Αλλά όταν ο agent προσπαθεί να χρησιμοποιήσει τον browser, λήγει ο χρόνος αναμονής.

Το σφάλμα είναι γενικό. Οι αιτίες δεν είναι. Υπάρχουν τουλάχιστον πέντε διακριτοί τρόποι αστοχίας, και από έξω φαίνονται πανομοιότυποι.

Αστοχία 1: Snap Chromium και το τείχος AppArmor

Σε ένα νέο Ubuntu 22.04+ server, η εντολή which chromium-browser επιστρέφει /usr/bin/chromium-browser. Φαίνεται σωστό. Δεν είναι.

Από το Ubuntu 22.04, το προεπιλεγμένο πακέτο Chromium είναι snap. Όταν το gateway του OpenClaw προσπαθεί να εκκινήσει αυτό το binary μέσω υπηρεσίας systemd, το επίπεδο περιορισμού του AppArmor το μπλοκάρει. Το πακέτο snap δεν μπορεί να ανοίξει τις θύρες αποσφαλμάτωσης του Chrome DevTools Protocol (CDP) μέσα από το sandbox. Το binary εκκινεί, φαίνεται να τρέχει, και μετά αποτυγχάνει σιωπηλά να ανοίξει τη θύρα που χρειάζεται το OpenClaw.

Στα logs θα δείτε «Failed to start Chrome CDP on port 18800», ή μερικές φορές τίποτα. Η διαδικασία του browser εκκινεί και πεθαίνει πριν γράψει μία γραμμή log.

Η λύση είναι να εγκαταστήσετε το .deb πακέτο του Google Chrome ή να χρησιμοποιήσετε το αυτόνομο Chromium binary του Playwright από ~/.cache/ms-playwright/. Και τα δύο παρακάμπτουν το snap sandbox. Αλλά η λύση δεν είναι προφανής. Η ανίχνευση browser του OpenClaw σαρώνει τις τυπικές διαδρομές κατά σειρά, βρίσκει πρώτο το snap binary και προσπαθεί να το χρησιμοποιήσει. Το GitHub issue #4978 περιέχει πλήρη περιγραφή.

Αστοχία 2: Προεπιλογές headless που προϋποθέτουν οθόνη

Το OpenClaw έρχεται με headless: false και noSandbox: false ως προεπιλογές browser. Αυτό έχει νόημα σε Mac ή Windows με οθόνη. Σε VPS δεν υπάρχει οθόνη. Χωρίς ρητή ρύθμιση, το Chromium προσπαθεί να ανοίξει παράθυρο σε display server που δεν υπάρχει.

Δύο αλλαγές ρυθμίσεων λύνουν το πρόβλημα:

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

Οι περισσότεροι οδηγοί VPS το αναφέρουν. Αλλά αν ακολουθείτε τις τυπικές οδηγίες εγκατάστασης OpenClaw, καμία από τις δύο γραμμές δεν εμφανίζεται. Εγκαθιστάτε, δοκιμάζετε τον browser, αποτυγχάνει. Ψάχνετε το σφάλμα. Βρίσκετε ένα blog post. Αλλάζετε τη ρύθμιση. Κάνετε επανεκκίνηση. Και έρχεται η αστοχία νούμερο τρία.

Αστοχία 3: Το αόρατο OOM kill

Μία καρτέλα Chromium με μερικές ανοιχτές σελίδες καταναλώνει 2 έως 4 GB RAM. Σε VPS 4 GB, δεν μένει σχεδόν τίποτα για το ίδιο το OpenClaw, το λειτουργικό σύστημα και τυχόν άλλες υπηρεσίες.

Όταν στο Linux τελειώνει η μνήμη, ο OOM killer του kernel τερματίζει τη διαδικασία που καταναλώνει τη μεγαλύτερη μνήμη. Αυτό είναι το Chromium. Η διαδικασία πεθαίνει. Το OpenClaw καταγράφει timeout browser. Κανένα crash report, κανένα stack trace, καμία ένδειξη ότι η μνήμη ήταν το πρόβλημα.

Υπάρχει και μια πιο λεπτή εκδοχή αυτού του προβλήματος. Το Chromium δημιουργεί θυγατρικές renderer διαδικασίες για κάθε καρτέλα. Αν δεν εκκαθαριστούν σωστά, συσσωρεύονται. Ένα GitHub issue τεκμηρίωσε 39 ορφανές renderer διαδικασίες που κατανάλωναν 3,8 GB RAM σε VPS που θα έπρεπε να είχε αρκετό περιθώριο.

Μπορείτε να ελέγξετε εκ των υστέρων με dmesg | grep -i "oom\|killed\|chromium", αλλά οι περισσότεροι δεν σκέφτονται να κοιτάξουν εκεί. Κάνουν restart στο OpenClaw, λειτουργεί για λίγα λεπτά, και μετά ξανασυμβαίνει.

Η επίσημη σελίδα απαιτήσεων server συνιστά τουλάχιστον 4 GB για βασική εγκατάσταση. Αλλά αυτός ο αριθμός υποθέτει ότι δεν υπάρχει αυτοματοποίηση browser. Με ενεργοποιημένο browser, τα 8 GB είναι το ρεαλιστικό ελάχιστο. Στη Hetzner, αυτή είναι η διαφορά μεταξύ cpx22 (5 $/μήνα) και cpx42 (17 $/μήνα).

Αστοχία 4: Η ελλιπής κοινόχρηστη μνήμη του Docker

Αν τρέχετε OpenClaw σε Docker (συνηθισμένο για εγκαταστάσεις VPS), υπάρχει ακόμα μία παγίδα. Το προεπιλεγμένο /dev/shm του Docker είναι 64 MB. Το Chromium χρησιμοποιεί κοινόχρηστη μνήμη για επικοινωνία μεταξύ διαδικασιών. Όταν εξαντληθεί, οι καρτέλες κρασάρουν σιωπηλά ή εμφανίζουν κενές σελίδες.

Η λύση είναι μία γραμμή στο docker-compose.yml:

shm_size: '2gb'

Ή κάντε mount ρητά:

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

Αυτό δεν τεκμηριώνεται στον οδηγό εγκατάστασης OpenClaw. Είναι μια συμπεριφορά ειδική για Docker που επηρεάζει κάθε εφαρμογή που χρησιμοποιεί Chromium, αλλά αν δεν έχετε εγκαταστήσει headless browsers σε Docker πριν, δεν θα ξέρατε να το ψάξετε.

Αστοχία 5: Συγκρούσεις θυρών για τις οποίες κανείς δεν προειδοποίησε

Η υπηρεσία ελέγχου browser του OpenClaw τρέχει σε ξεχωριστή θύρα από το gateway. Εξ ορισμού, είναι η θύρα του gateway συν 2. Αν το gateway είναι στη 18789, η υπηρεσία ελέγχου browser πρέπει να είναι στη 18791, και το extension relay στη 18792.

Στο Docker, αν εκθέσετε μόνο τη θύρα 18789, η υπηρεσία ελέγχου browser δεν είναι προσβάσιμη εκτός container. Ακόμα χειρότερα, το gateway καταγράφει «Browser control service ready» ακόμα και όταν η θύρα 18791 δεν δεσμεύεται ποτέ. Το issue #17584 ανίχνευσε αυτό ως πρόβλημα εισαγωγής λάθους module από το gateway: ένα που καταγράφει το μήνυμα «ready» χωρίς να ξεκινά τον HTTP server. Το log λέει ότι όλα είναι εντάξει. Η θύρα είναι νεκρή.

Στο Kubernetes, αν ένα άλλο container στο ίδιο pod χρησιμοποιεί ήδη τη θύρα 9222 (τυπική θύρα CDP), η συνάρτηση ensurePortAvailable() του OpenClaw εντοπίζει τη θύρα ως κατειλημμένη και αρνείται τη σύνδεση, ακόμα κι αν ο κάτοχος είναι ακριβώς η παρουσία Chromium με την οποία πρέπει να επικοινωνεί το OpenClaw.

Το GitHub issue #10994 τεκμηριώνει μια περίπτωση όπου η εγκατάσταση VPS του χρήστη λειτουργούσε σωστά. Στη συνέχεια, μετά από μερικές αυτοματοποιημένες ενέργειες, η θύρα CDP κόλλησε. Η μόνη λύση ήταν να βρεθούν και να τερματιστούν τα εγκαταλελειμμένα Chromium processes που κρατούσαν τη θύρα.

Γιατί αυτές οι αστοχίες πολλαπλασιάζονται

Καθένα από αυτά τα πέντε προβλήματα έχει γνωστή λύση. Αλλά αλληλεπιδρούν. Λύνετε το πρόβλημα snap και πέφτετε στην προεπιλογή headless. Διορθώνετε τη ρύθμιση και το Chromium ξεκινά. Τρέχει δέκα λεπτά, μετά ο OOM killer χτυπά. Προσθέτετε swap, και τώρα το όριο κοινόχρηστης μνήμης Docker προκαλεί σιωπηλά σφάλματα rendering. Τα διορθώνετε και ανακαλύπτετε ότι η θύρα 18791 δεν είναι εκτεθειμένη.

Ο κύκλος αποσφαλμάτωσης μοιάζει έτσι: αναζήτηση σφάλματος, εύρεση μερικής λύσης, εφαρμογή λύσης, πτώση στο επόμενο σφάλμα, επανάληψη. Ένας χρήστης Discord περιέγραψε ότι επανεγκατέστησε ολόκληρο το λειτουργικό «για 3η ή 4η φορά». Ένας άλλος ανέφερε ότι ο browser ήταν «ασταθής» μετά από αυτό που πίστευε ότι ήταν πλήρης εγκατάσταση. Ένας τρίτος άνοιξε issue με τίτλο απλά «Browser tool consistently fails on VPS».

Το πρόβλημα δεν είναι ότι κάθε μεμονωμένη διόρθωση είναι δύσκολη. Το πρόβλημα είναι ότι υπάρχουν πέντε, εξαρτώνται από το συγκεκριμένο λειτουργικό σύστημα, τον package manager, το container runtime και τον πάροχο VPS σας, και ένα μόνο λάθος στην αλυσίδα σημαίνει ότι ο browser δεν λειτουργεί.

Η ομάδα OpenClaw αξίζει αναγνώριση που σταθερά διορθώνει σχετικά bugs. Το παραπλανητικό «ready» log, η εκκαθάριση ορφανών renderers και ο χειρισμός θύρας CDP έχουν βελτιωθεί σε πρόσφατες εκδόσεις. Αλλά οι upstream διορθώσεις αντιμετωπίζουν συμπτώματα μέσα στον κώδικα OpenClaw. Δεν μπορούν να εγκαταστήσουν το σωστό Chromium binary στον server σας, να ρυθμίσουν την κοινόχρηστη μνήμη Docker ή να εκχωρήσουν αρκετή RAM για αυτοματοποίηση browser. Αυτά παραμένουν δική σας ευθύνη.

Πώς χαλάσαμε το Chromium τρεις φορές (και τι μάθαμε)

Τρέχουμε κάθε agent OpenClaw.rocks σε Kubernetes με τον open source operator μας. Ο browser sidecar μας πήρε εβδομάδες μέχρι να λειτουργήσει σωστά. Αντιμετωπίσαμε τη δική μας εκδοχή κάθε προβλήματος που περιγράφτηκε παραπάνω, συν μερικά που εμφανίζονται μόνο σε πλαίσιο ενορχήστρωσης containers.

Η ιδέα ήταν απλή: τρέξτε Chromium ως ξεχωριστό container δίπλα στο OpenClaw, συνδεδεμένο μέσω CDP. Μία γραμμή στο Custom Resource και ο browser απλά λειτουργεί.

spec:
  chromium:
    enabled: true

Δείτε πώς αυτή η μία γραμμή πραγματικά υλοποιήθηκε.

Κατάρρευση 1: Λάθος χρήστης, σύστημα αρχείων μόνο για ανάγνωση

Η πρώτη μας προσπάθεια έτρεξε το container Chromium ως UID 1001 με σύστημα αρχείων root μόνο για ανάγνωση. Βέλτιστη πρακτική ασφαλείας. Και εντελώς σπασμένο. Το browserless image αναμένει UID 999 (blessuser), και το Node.js καλεί os.userInfo() κατά την εκκίνηση, που αποτυγχάνει με ENOENT όταν το UID δεν έχει εγγραφή στο /etc/passwd. Ακόμα και μετά τη διόρθωση του UID, το σύστημα αρχείων μόνο για ανάγνωση εμπόδιζε το Chrome να γράψει προσωρινά αρχεία. Ο sidecar κατέρρεε σε κάθε εκκίνηση πριν γράψει μία γραμμή log. Το issue #12 έχει ολόκληρη την ιστορία.

Κατάρρευση 2: Το τείχος ασφαλείας WebSocket

Με το container τελικά σε λειτουργία, το Chromium ήταν ενεργό, το CDP απαντούσε στη θύρα 9222, αλλά το OpenClaw αρνούνταν να το χρησιμοποιήσει. Το gateway δεσμευόταν στη LAN IP του pod (απαραίτητο για routing Kubernetes Service), και το επίπεδο ασφαλείας του OpenClaw μπλόκαρε τις plaintext ws:// συνδέσεις σε μη-loopback διευθύνσεις: «SECURITY ERROR: Gateway URL uses plaintext ws:// to a non-loopback address. Both credentials and chat data would be exposed to network interception.»

Ένας νόμιμος έλεγχος ασφαλείας. Αλλά σε Kubernetes pod, όλα τα containers μοιράζονται network namespace. Η κίνηση μεταξύ τους δεν φεύγει ποτέ από τον κόμβο. Δεν μπορούσαμε να αλλάξουμε τον έλεγχο ασφαλείας του OpenClaw, οπότε προσθέσαμε έναν nginx reverse proxy sidecar που ακούει σε όλα τα interfaces και προωθεί στο gateway σε loopback. Το gateway παραμένει ασφαλές. Το Service παραμένει προσβάσιμο. Το issue #135 τεκμηριώνει την αποσφαλμάτωση.

Κατάρρευση 3: Σύγκρουση θύρας 3000

Το Chromium έτρεχε. Το gateway είχε proxy. Αλλά ο browser ακόμα δεν συνδεόταν. Το browserless image χρησιμοποιεί τη θύρα 3000 εξ ορισμού, που συγκρουόταν με την εσωτερική υπηρεσία ελέγχου browser του OpenClaw. Και όταν αλλάξαμε στη θύρα 9222, η ensurePortAvailable() του OpenClaw την εντόπισε ως «σε χρήση από κάτι άλλο» και αρνήθηκε σύνδεση, γιατί σε κοινό network namespace, η θύρα του sidecar φαίνεται τοπική.

Η λύση ήταν η χρήση της IP διεύθυνσης του pod (μέσω Kubernetes Downward API) αντί για localhost στο CDP URL. Μια μη-loopback διεύθυνση λέει στο OpenClaw να χρησιμοποιήσει remote/attach-only mode: συνδεθείτε σε αυτό που ήδη τρέχει αντί να προσπαθήσετε να εκκινήσετε δικό σας browser. Το PR #183 το έλυσε.

Το αποτέλεσμα: πέντε διορθώσεις, αυτόματα εφαρμοσμένες

Καθεμία από αυτές τις καταρρεύσεις μας δίδαξε κάτι. Ο τρέχων operator κωδικοποιεί όλα αυτά:

Απομόνωση sidecar. Το Chromium τρέχει στο δικό του container. Χωρίς snap. Χωρίς Playwright. Χωρίς headless flags. Το browserless image τα χειρίζεται όλα.

Αποκλειστικοί πόροι. Ο sidecar παίρνει δικά του όρια CPU και μνήμης (250m-1000m CPU, 512Mi-2Gi RAM εξ ορισμού, ρυθμιζόμενο). Αν το Chromium υπερβεί το όριο μνήμης, το Kubernetes επανεκκινεί μόνο το container browser. Ο agent σας συνεχίζει.

Κοινόχρηστη μνήμη. Ο operator τοποθετεί αυτόματα 1 GB volume βασισμένο στη μνήμη στο /dev/shm. Χωρίς ρύθμιση Docker shm_size.

Δρομολόγηση θυρών. Η IP του pod στο CDP URL ενεργοποιεί τον απομακρυσμένο τρόπο. Το OpenClaw συνδέεται στον sidecar αντί να προσπαθεί να καταλάβει τη θύρα. Η σύγκρουση ensurePortAvailable() εξαφανίζεται.

Ενσωματωμένη ανίχνευση anti-bot. Πολλά sites εντοπίζουν το προεπιλεγμένο headless Chromium και μπλοκάρουν την αυτοματοποίηση. Ο operator υποστηρίζει extraArgs στον Chromium sidecar, ώστε να μπορείτε να περάσετε flags όπως --disable-blink-features=AutomationControlled και custom user agents χωρίς να χτίσετε custom container image:

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"

Ασφάλεια χωρίς συμβιβασμούς. Όλα τα Linux capabilities αφαιρεμένα, κλιμάκωση δικαιωμάτων απενεργοποιημένη, seccomp RuntimeDefault, non-root UID 999. Χωρίς --no-sandbox ως root.

Τι σημαίνει αυτό για εσάς

Αν τρέχετε OpenClaw σε VPS και ο browser λειτουργεί, συγχαρητήρια. Πλοηγηθήκατε μέσα από πέντε διακριτούς τρόπους αστοχίας και βγήκατε από την άλλη πλευρά. Κρατήστε τη ρύθμιση σας. Κάντε backup.

Αν ο browser δεν λειτουργεί, ή λειτουργεί σποραδικά, ή έχετε βαρεθεί να αποσφαλματώνετε Chromium σε VPS 5 δολαρίων, σκεφτείτε πόσο αξίζει ο χρόνος σας.

Το OpenClaw.rocks τρέχει κάθε agent σε Kubernetes με τον operator που περιγράφτηκε παραπάνω. Ο browser sidecar είναι προρυθμισμένος. Η μνήμη είναι κατανεμημένη. Οι θύρες είναι δρομολογημένες. Η ασφάλεια είναι ενισχυμένη. Δεν εγκαθιστάτε τίποτα, δεν ρυθμίζετε τίποτα, δεν αποσφαλματώνετε τίποτα.

Ο agent σας παίρνει browser που λειτουργεί. Κάθε φορά. Έτοιμος για χρήση.

Οι πέντε διορθώσεις σε σύνοψη

Αν θέλετε να μείνετε στο self-hosting, εδώ είναι η πλήρης λίστα ελέγχου:

  1. Αντικαταστήστε το snap Chromium με το .deb του Google Chrome ή το αυτόνομο binary του Playwright
  2. Ενεργοποιήστε headless mode: openclaw config set browser.headless true και browser.noSandbox true
  3. Εκχωρήστε 8 GB+ RAM ή προσθέστε 4 GB swap για αυτοματοποίηση browser
  4. Τοποθετήστε κοινόχρηστη μνήμη στο Docker: shm_size: '2gb'
  5. Εκθέστε και τις τρεις θύρες: gateway, browser control (gateway + 2) και extension relay (gateway + 3)

Ή παραλείψτε τη λίστα. Αποκτήστε τον βοηθό σας στο OpenClaw.rocks και αφήστε μας να χειριστούμε την υποδομή.