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が見てるトークン
- コンテナが見てるトークン
  を同じにするのが最短ルート