openclawはインストールした時点で「だいたい構成が決まってる」ので、基本は 用意された構成をそのまま使うだけ…のはず。
なのに詰まった。しかも最後に分かったのは トークンが原因だった、という話です。
※ドメイン名・IPは伏せています（example.com / AAA.BBB.CCC.DDD）
ゴール
- openclaw を既定の構成で立ち上げる
- CLI から接続（pairing）できる状態にする
- （おまけ）CaddyでHTTPS化して外部公開する
全体像（ここだけ先に）
- openclawは「サーバ側（コンテナ）」と「CLI」などのクライアントがいる
- 接続の肝は “同じトークンを見ていること”
- pairing が失敗する原因はだいたい トークン不一致（環境変数／.env／コンテナ内の値のズレ）
まず疑うべき：トークンの“参照元ズレ”
今回のオチはこれでした。
- CLIで接続しようとしているトークン
- サーバ（docker側）が参照しているトークン
この2つが 同じじゃない → pairing できない
「設定したつもり」でも、
.envを直したがコンテナが読んでない- コンテナ内に別の
.envがある- CLIが別の環境変数を見てる
みたいな“あるある”でズレます。
最短チェック：CLIとコンテナで「同じトークンか」確認する
1) CLI側が見ているトークン（例）
まず自分がCLIを叩いているシェルで、環境変数を確認。
env | egrep -i 'TOKEN|OPENCLAW|SESSION|KEY' || true
もし .env を使っているなら、読み込みが効いているかも確認。
cat .env | egrep -i 'TOKEN|OPENCLAW|SESSION|KEY' || true
注：export した値が残っていて .env の変更が効いてないことがあるので、
“今このターミナルが何を見てるか” を必ず確認するのが吉。
2) サーバ（docker）側が見ているトークン（例）
openclawのコンテナ（または該当コンテナ）に入って確認。
docker exec -it <openclaw系コンテナ名> sh -lc 'env | egrep -i "TOKEN|OPENCLAW|SESSION|KEY" || true'
また、composeで指定された環境変数が想定通りかも見る。
docker inspect <openclaw系コンテナ名> --format '{{json .Config.Env}}' | head -c 2000; echo
3) 「一致してるか？」の結論を出す
- CLI側のトークンと
- コンテナ側のトークンが
完全一致してないと、だいたい pairing が詰む。
注：末尾の改行・引用符・空白が混じってるケースもあるので、
値のコピペは慎重に（特に長いトークン）。
直し方の定石：どちらかに寄せて“再起動”
トークンがズレていたら、基本はこのどれかで直ります。
パターンA：.env を直した → でもコンテナに反映されてない
このタイプは コンテナ再作成 が確実。
docker compose up -d --force-recreate
（構成によっては --build も）
docker compose up -d --build --force-recreate
パターンB：CLIが別の値を見ている（exportが残ってる等）
- 該当の環境変数を unset
- そのうえで .env を読み直す、もしくは正しい値を export
unset <怪しい環境変数名>
# または
export <正しい環境変数名>=<正しい値>
パターンC：コンテナ内に別の設定ファイルがある（想定外）
「ホストで見てる .env と、コンテナ内で見てる .env が別物」みたいなやつ。
- どのファイルがマウントされているか（volume）を確認
- コンテナ内のパスを特定して、そこを正にする
docker inspect <コンテナ名> --format '{{range .Mounts}}{{println .Source "->" .Destination "mode=" .Mode}}{{end}}'
pairingで詰まったら：ログは“トークン周辺”だけ見ればOK
通信の深掘り（tcpdump等）に行く前に、まずはこれで足ります。
- CLIの実行ログ（エラー文）
- openclaw側コンテナログ
docker logs --tail=200 <openclaw系コンテナ名>
ポイントは「認証が通ってない」「トークンが無い」「無効」系の匂いがあるかどうか。
（おまけ）Caddyで外に出す：最小例 + 気をつける点
pairingが済んで動作確認できたら、最後に外へ出すだけ。
Caddyfile（最小例）
example.com {
reverse_proxy openclaw:3000
log
}
気をつける点（これだけ）
- Caddyfileをコンテナ内で編集しようとして沼らない
- :ro でマウントしていたらコンテナ内は編集不可
- ホスト側のCaddyfileを編集 → docker restart caddy が基本
（おまけ）DNS確認：ここが通ればOK
深掘りしなくてOK。確認はこの3つだけ。
# 権威DNS（ネームサーバ）に直接聞く（最優先）
dig @ns1.provider.example example.com A +short
# パブリックDNS（浸透具合を見る）
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short
そして最終チェック：
curl -sI http://example.com | egrep -i 'HTTP/|server:|location:'
curl -skI https://example.com | egrep -i 'HTTP/|server:|via|location:'
まとめ（今回の学び）
- openclawは「構成を組む」というより **既定構成を“正しく使う”**が近い
- 詰まるとしたら トークン（＝認証情報）
- pairingできないときは、通信より先に
- CLIが見てるトークン
- コンテナが見てるトークン
を 同じにするのが最短ルート