リモートNodeとTailscale Serveで詰まりやすい五つの誤読パターン
リモートNodeは「別マシンからGatewayの制御面に乗る」経路です。2026年時点では、到達性が取れた直後にデバイスペアリングが第二の関門になります。ここで危ないのは、curlの成功、Tailscaleの緑表示、WebSocketハンドシェイクの開始をすべて「接続完了」とみなすことです。以下の五つは、六リージョン移行の前に引き継ぎ可能な証跡を残すための署名です。二つ以上が重なる場合は、モデルやスキルを増やす前にdevices一覧とバックアップの整合を凍結してください。
「Serveが動いている」＝「Nodeが承認済み」：Tailscale Serveはローカル18789への転送をtailnetに載せますが、OpenClaw側のデバイス台帳が空のままだと、クライアントは依然としてpairing requiredで閉じます。Serveの設定画面とopenclaw devices listは別証跡として保存します。
「1008はネットワーク障害」：Closeコード 1008はポリシー拒否を示すことが多く、未承認Node、失効したペアリング、Gatewayのgateway.remote方針不一致が典型です。まずdevicesのpendingを確認し、無闇にポートやリージョンを変えません。
「scpで~/.openclawをコピーすれば移行完了」：状態ディレクトリにはチャネル秘密、デバイス鍵、ログが同居します。tarで丸ごと持ち込むと、旧リージョンのデバイスIDが新ホストと衝突します。openclaw backupで明示的スナップショットを取り、復元後に再ペアリングが要る項目を表に書きます。
「ホットリロードでNode設定も自動追従」：Gatewayのreloadはプロセスと設定の再読込であり、クライアントNodeの承認状態は別です。reload後に1008が再発する場合は、サイト内のホットリロード記事でポート隔離を確認したうえでdevicesを再承認します。
「六地域を回すほど速い」：東京からシンガポールへホストだけ変え、バックアップとTailscale ACLを持ち込まないと、RTTだけが改善しペアリングとチャネルは旧状態のまま残ります。移行票にバックアップハッシュ・devices一覧・Serve設定の三列を必須にします。
署名を切り分けたら、当日の作業を入口検証、devices承認、バックアップ復元とスモークの三段に分け、各段末にUTCタイムスタンプ付きテキストを残すことをおすすめします。チームがヘッドレス初時間チェックリストを既に持っている場合でも、リモートNodeは承認台帳が追加されるため、同じ表形式で行を足すと監査が楽になります。
18789直公開、リバプロ、Tailscale Serve：入口方式で停止面を揃える
クラウドMacでGatewayを常駐させ、開発者のノートPCからNodeで接続する典型構成では、どの層までを事業者のセキュリティグループに晒すかが最初の設計判断です。公網直公開はprobeが簡単ですが、ペアリングとトークン漏えいの影響面が広がります。Tailscale Serveはtailnet内に入口を閉じやすく、監査向きです。リバプロは既存の証明書運用に乗せられますが、WebSocket Upgradeとデバイス承認は別問題のまま残ります。下表は十分以内に「欠けている能力」を揃える粗い粒度です。
| 観点 | 18789＋セキュリティグループ | HTTPSリバプロ | Tailscale Serve |
|---|---|---|---|
| 到達性の証明 | 公網curlと外部probeが直感的 | 証明書とUpgradeの二重確認が必要 | tailnet内クライアントからの層別検証 |
| ペアリングとの関係 | 到達しても1008は未承認で再現 | TLS成功とdevices承認を混同しやすい | Serve成功でもapproveは別手順 |
| 六リージョン移行 | SGごとにSGルールを書き換え | DNSと証明書の切替が増える | ACLとServe設定を移行票に同梱 |
| ログと個人情報 | 公網アクセスログが増える | リバプロログの保持方針が要る | tailnet内に閉じやすい |
| 推奨順序 | 最終段階のスモーク向き | 既存Ingressがあるチーム向き | リモートNode初回接続の第一候補 |
リモートNodeの受け入れは「誰が18789に届くか」では終わらず、「どのデバイスIDが承認されているか」まで一枚の表に含める必要があります。
シンガポールから米国西部まで日次レンタルでホストを回すチームでは、入口方式をリージョンごとに変えないことが重要です。東京でServe、ソウルで直公開と混在すると、障害時に1008の原因が入口なのか承認なのか切れません。移行ウィンドウごとに方式を固定し、バックアップ復元後に同じ六ステップRunbookを繰り返すと、比較可能なKPIが残ります。
関門コマンド骨格：Serve、devices approve、openclaw backup
Gatewayホストでは、まずdaemonと18789のローカル生存を確認し、Tailscale Serveでtailnet入口を立て、pendingデバイスを承認してからクライアントNodeを再接続します。移行日は稼働前にバックアップを取得し、復元後はdoctorとchannels probeでチャネル面を切り分けます。複数ユーザー環境では、バックアップ出力の所有者と復元先のUIDを変更票に紐づけてください。
openclaw gateway status tailscale serve --bg --https=443 http://127.0.0.1:18789 openclaw devices list openclaw devices approve <request-id> openclaw backup create --output /tmp/openclaw-$(date -u +%Y%m%d).tgz openclaw doctor openclaw channels status --probe
devices approveのあとにクライアントを再起動しないと、古いWebSocketセッションが1008を繰り返すことがあります。バックアップは暗号化ストレージへ退避し、六地域をまたぐ転送ではチェックサムと復元ログを同一チケットに添付します。チャネルはオンラインでも無言になる場合があるため、承認後も接続済みでも返信しないの層別手順と突き合わせてください。バージョンを上げる移行では、安定チャネルのpin方針に沿ったアップグレードRunbookを先に読み、backupとupgradeを同一変更票にまとめないでください。
ヒント：openclaw devices listの出力にUTC時刻を付けて保管すると、あとから「Serveを変えたせいか承認漏れか」の切り分けが速くなります。
六ステップRunbook：入口からバックアップ復元スモークまで
バージョンと移行票を凍結する：OpenClawパッケージ版、Tailscaleクライアント版、対象リージョン、接続予定Node一覧を文書化し、口頭の「ついでに最新へ」を禁止します。
Gatewayと18789をローカルで確認する：gateway statusとループバックprobeを取り、daemon名と状態ディレクトリパスを記録します。
Tailscale Serveを立てる：tailnet内からHTTPSでGatewayに届くことを確認し、Serve設定のスクリーンショットまたはCLI出力を保存します。
devicesを承認する：devices listでpendingを確認し、devices approve後にクライアントNodeを再接続して1008が消えることを検証します。
バックアップと復元を試す：移行先でopenclaw backupのスナップショットを復元し、doctorで差分を一項目ずつ解消します。
チャネルとリモートの最小スモーク：channels probeとリモートNodeからの制御操作を一通ずつ実行し、ログ時刻を突き合わせます。
当番手帳に書ける三本の閾値と六リージョン状態移行
ペアリング試行の上限：同一Nodeに対するapproveと再接続の往復は移行ウィンドウあたりおよそ六回を超えないようにし、毎回devices一覧の差分を固定保存します。
バックアップサイズとディスク：状態ディレクトリとログで入門ディスクのおよそ三成を確保し、バックアップ展開後もおよそ一成の空きを下回ったら重いブラウザ自動化を足しません。
移行ウィンドウのタイムボックス：Serveとdevices承認が合わせて約四十五分を超えても1008が消えない場合、入口方式を変えず、ヘッドレス初時間チェックリストのdaemonとポート層に戻ります。
注意：上記の分・割合はエンジニアリング会話用の閾値であり、特定事業者のSLAを約束するものではありません。跨リージョンRTTは自前計測を正とします。
家庭回線や単一VPSだけにNodeを置き、クラウドMac上のGatewayを六地域で回すと、Appleツールチェーンと制御面が分断され、バックアップのたびにscpと手動pemが増えます。一方で監査しやすいヘッドレス裸金属クラウドMacにGatewayと状態を置き、日次または週次レンタルでServeとdevices承認を検証してから月次固定するほうが、リモートNodeとiOS納品が同居するチームのリズムに合います。実機Apple Siliconと安定出口の上でペアリングと移行を完走したい場合、MESHLAUNCHのMac miniクラウドレンタルは現実的な第一選択になります。本番一台への賭けではなく、六リージョンで再現可能な受け入れ表を作るための下請けとして使えます。
Gatewayホストでopenclaw devices listとopenclaw devices approveを実行し、クライアントNodeを再接続します。入口の層別検証はヘッドレスSSH初時間チェックリスト、複数インスタンス時のポートはホットリロード記事を参照してください。発注は料金ページからどうぞ。
devices承認とチャネル方針は別層です。接続済みでも返信しないの手順でchannels probeを取り、ヘルプはヘルプセンターをご覧ください。
まずopenclaw backupでスナップショットを取り、バージョン方針は本番アップグレードRunbookに沿ってdry-run後に実施します。復元後は同じ六ステップでServeとdevicesを再検証してください。