La visualizzazione di Servizio non disponibile in OpenClaw non identifica un singolo problema. Nella discussione della community IceWhale di febbraio 2026, la risoluzione dei problemi ha rivelato in sequenza tre livelli diversi: un token gateway obbligatorio, autorizzazioni insufficienti per ispezionare Docker dall'account host ZimaOS e, infine, un container OpenClaw che non aveva mai completato la configurazione iniziale.
La discussione è particolarmente utile perché alcuni suggerimenti intermedi si sono rivelati errati per l'immagine pacchettizzata Big-Bear. L'aggiunta di un GATEWAY_MODE la variabile d'ambiente non ha risolto il ciclo di riavvio e l'aggiunta di --gateway.mode=local al comando sbagliato ha prodotto un opzione sconosciuta errore. La documentazione attuale di OpenClaw conferma che gateway.mode=local deve essere presente nella configurazione persistente di OpenClaw e che le distribuzioni Docker debbano eseguire l'onboarding o la configurazione per creare tale configurazione.
Verifica innanzitutto che il container OpenClaw sia effettivamente in esecuzione
Il post originale mostrava che l'app OpenClaw segnalava che l'applicazione non funzionava correttamente e visualizzava un suggerimento su OPENCLAW_GATEWAY_TOKEN.
Prima di modificare le impostazioni dell'applicazione, controlla lo stato del container dall'host ZimaOS o CasaOS:
docker ps -a | grep openclawSe il container si riavvia o è terminato, leggi i log:
docker logs big-bear-openclaw --tail 100Il nome esatto del container può variare. Usa docker ps -a per identificare il nome effettivo, invece di presumere che sia sempre big-bear-openclaw.
Generare e archiviare OPENCLAW_GATEWAY_TOKEN
Il primo suggerimento della community era generare un token gateway casuale e robusto:
openssl rand -hex 32Se OpenSSL non è disponibile, la discussione proponeva un'alternativa locale per generare byte casuali:
head -c 32 /dev/urandom | xxd -p -c 32Anche la documentazione Docker ufficiale attuale di OpenClaw utilizza OPENCLAW_GATEWAY_TOKEN per l'autenticazione del gateway. Il suo script di configurazione standard genera un token e lo scrive nel file di distribuzione .env automaticamente il file. In un'applicazione CasaOS pacchettizzata manualmente, inserisci il valore generato nel campo della variabile d'ambiente previsto da quell'immagine.
Tratta questo token come un segreto. Non incollarlo in un forum pubblico, in uno screenshot, in un ticket di supporto o in un repository.
Un errore di autorizzazione Docker non è un errore di autorizzazione OpenClaw
Dopo aver aggiunto un token, l'autore originale ha riscontrato:
autorizzazione negata durante il tentativo di connessione al socket del demone Docker
/var/run/docker.sock: connessione: autorizzazione negata
La raccomandazione della community era elevare temporaneamente i privilegi prima di eseguire comandi Docker amministrativi:
sudo -i
docker psUsa i privilegi root solo per i comandi che ne hanno realmente bisogno. Non indebolire /var/run/docker.sock permessi o rendere il socket Docker accessibile in scrittura a chiunque solo per eliminare l'errore. L'accesso a Docker concede di fatto il controllo amministrativo sull'host.
Il vero errore di OpenClaw era «Missing config»
Una volta ottenuto l'accesso ai log Docker, è apparso il messaggio importante:
Missing config. Run `openclaw setup` or set gateway.mode=local
Questo era più utile della generica pagina «Service Unavailable». La documentazione attuale del gateway di OpenClaw conferma che il gateway rifiuta di avviarsi normalmente finché la sua configurazione non contiene:
gateway.mode = localAnche l'attuale OpenClaw specifica che configurazione di OpenClaw oppure openclaw onboard --mode local scrive la modalità gateway locale nella configurazione persistente.
Perché GATEWAY_MODE=local non ha risolto il problema con questa immagine
Una risposta intermedia della community suggeriva di aggiungere:
GATEWAY_MODE=localL'utente ci ha provato, ma il ciclo di riavvio è continuato. È una correzione importante da preservare: la documentazione ufficiale attuale di OpenClaw non definisce una generica GATEWAY_MODE variabile d'ambiente come sostituta dell' gateway.mode impostazione utilizzata da questo flusso di lavoro.
Non convertire ogni chiave di configurazione OpenClaw con i punti in una variabile d'ambiente maiuscola inventata. Usa il metodo di configurazione documentato per l'immagine OpenClaw o il modello di distribuzione esatto.
Perché --gateway.mode=local ha prodotto «Unknown option»
Un tentativo successivo della community ha aggiunto:
--gateway.mode=localal comando del container CasaOS. L'immagine ha quindi restituito:
unknown option '--gateway.mode'La discussione ha identificato correttamente il motivo: CasaOS aggiungeva il flag a un livello del comando che non lo accettava. L'attuale CLI di OpenClaw utilizza comandi come openclaw gateway, configurazione di OpenClaw, openclaw onboarde openclaw config set; gateway.mode è una chiave di configurazione, non un flag runtime universale di primo livello che può essere inserito ovunque nel comando del container.
L'immagine Big-Bear aveva bisogno di una directory di configurazione persistente e inizializzata
La diagnosi finale della community si è concentrata su questo mount:
/DATA/AppData/big-bear-openclaw
→ /home/node/.openclawIl container si aspettava la configurazione in /home/node/.openclaw, ma la directory montata non era stata inizializzata. Ciò è coerente con la documentazione Docker attuale di OpenClaw: la directory di configurazione montata contiene i dati persistenti openclaw.json, i dati del profilo di autenticazione e i segreti forniti dall'ambiente.
Il suggerimento finale della discussione era eseguire la configurazione all'interno del container, così la directory montata avrebbe ricevuto una configurazione effettiva di OpenClaw. Tuttavia, l'autore del post originale non è tornato a fornire una conferma finale dopo quell'ultima risposta. Consideralo come la diagnosi più plausibile della discussione, non come una soluzione finale verificata.
Preferisci la configurazione iniziale Docker attuale di OpenClaw su una nuova installazione
Per una distribuzione attuale, segui la guida ufficiale all'installazione di OpenClaw con Docker invece di ricostruire la sequenza di risoluzione dei problemi del 2026 un errore alla volta.
L'attuale OpenClaw fornisce uno script di configurazione Docker che:
- crea o scarica l'immagine del gateway;
- esegue la configurazione iniziale;
- genera un token del gateway;
- scrive la configurazione persistente;
- crea le directory necessarie per i segreti;
- avvia il gateway tramite Docker Compose.
Per le distribuzioni Docker headless, OpenClaw documenta anche la configurazione iniziale non interattiva con modalità gateway locale e autenticazione tramite token. È preferibile rispetto all'invenzione manuale di variabili d'ambiente o all'aggiunta di flag non supportati.
Schema di configurazione manuale attuale
L'attuale guida Docker di OpenClaw documenta uno schema manuale equivalente a:
openclaw onboard --mode local --no-install-daemon
openclaw config set gateway.mode local
openclaw config set gateway.bind lanIn Docker Compose, questi comandi vengono normalmente eseguiti tramite il container CLI o di configurazione iniziale dedicato definito dal progetto. Non incollare comandi destinati all'host in un'immagine CasaOS pacchettizzata senza aver prima verificato il relativo entrypoint e i mount.
L'attuale documentazione della CLI del gateway OpenClaw conferma che openclaw setup e openclaw onboard --mode local creano la configurazione locale del gateway necessaria.
Usa lo stesso token del gateway nell'interfaccia di controllo
La documentazione Docker attuale di OpenClaw espone l'interfaccia di controllo sulla porta 18789 nella configurazione standard di Compose e indica agli utenti di incollare nelle impostazioni dell'interfaccia il token del gateway proveniente dall'ambiente di distribuzione.
Una mancata corrispondenza del token può causare errori di autenticazione dopo che il gateway è operativo, ma è diversa da un container che si chiude ripetutamente perché non esiste alcuna configurazione. Diagnostica prima l'avvio, poi l'autenticazione dell'interfaccia.
Non usare --allow-unconfigured come soluzione permanente
OpenClaw fornisce --allow-unconfigured per l'avvio occasionale o di sviluppo. La documentazione attuale specifica che bypassa il controllo della modalità locale senza scrivere o riparare la configurazione. È utile per i test, ma non sostituisce la corretta configurazione iniziale di un server persistente.
Lista di controllo per la risoluzione dei problemi del servizio OpenClaw non disponibile
- Controlla se il container OpenClaw è in esecuzione, terminato o in riavvio continuo.
- Leggi i log attuali del container prima di modificare le impostazioni.
- Verifica
OPENCLAW_GATEWAY_TOKENesista e venga trattato come un segreto. - Se i comandi Docker restituiscono un errore di autorizzazione sul socket, usa una shell amministrativa autorizzata invece di ridurre le autorizzazioni del socket Docker.
- Cerca in particolare
Configurazione mancanteoppuregateway.mode=localerrori. - Verifica che il percorso AppData dell’host sia montato nella directory di configurazione di OpenClaw prevista dall’immagine.
- Esegui il flusso di configurazione o onboarding supportato da OpenClaw, in modo che
openclaw.jsonviene creata nello spazio di archiviazione persistente. - Non fare affidamento su
GATEWAY_MODE=locala meno che la documentazione esatta dell’immagine non lo definisca esplicitamente. - Non aggiungere
--gateway.mode=locala un comando arbitrario del container CasaOS. - Riavvia il container e controlla nuovamente i log dopo aver scritto la configurazione.
- Solo dopo che il gateway rimane attivo, verifica l’autenticazione tramite token della Control UI o la configurazione del provider del modello.
Domande frequenti sulla mancata disponibilità del servizio OpenClaw
OpenClaw richiede OPENCLAW_GATEWAY_TOKEN?
Le distribuzioni Docker attuali di OpenClaw lo supportano e lo usano comunemente OPENCLAW_GATEWAY_TOKEN per l’autenticazione del gateway. Lo script di configurazione ufficiale può generarne automaticamente uno. Le immagini di terze parti pacchettizzate possono esporre il valore in modo diverso, quindi segui lo schema effettivo delle variabili d’ambiente dell’immagine.
Cosa significa “permission denied /var/run/docker.sock”?
Significa che l’utente attuale dell’host non può accedere al daemon Docker. Questo, da solo, non significa che la directory dati interna di OpenClaw non sia scrivibile. Usa un account amministrativo autorizzato per la diagnostica di Docker.
Come imposto gateway.mode=local?
Usa il comando di configurazione, onboarding o setup supportato da OpenClaw, in modo che il valore venga scritto in openclaw.json. La documentazione attuale indica configurazione di OpenClaw oppure openclaw onboard --mode local crea questa impostazione.
Devo aggiungere GATEWAY_MODE=local?
Non sulla base di questa discussione. Quel suggerimento non ha risolto il ciclo di riavvio dell’immagine pacchettizzata dell’utente, e la documentazione upstream attuale considera gateway.mode come impostazione di configurazione, anziché come variabile d’ambiente generica denominata GATEWAY_MODE.
Perché --gateway.mode=local restituisce “opzione sconosciuta”?
Perché l’opzione è stata aggiunta al livello di comando sbagliato nel pacchetto CasaOS. Una chiave di configurazione con notazione a punti non è automaticamente un flag della riga di comando valido per ogni binario o punto di ingresso di OpenClaw.
La discussione della community è stata risolta definitivamente?
La discussione è arrivata a una diagnosi finale ben definita: una directory di configurazione persistente non inizializzata, e raccomandava di eseguire configurazione di OpenClaw all’interno del container. L’autore originale del post non ha pubblicato una conferma finale dopo quell’ultima istruzione, quindi la pagina non dovrebbe dichiarare una risoluzione verificata che la fonte non contiene.
