つまずき：クラウドでは動くのにノートでは不安定
二つの 127.0.0.1。ドキュメント通りループバックにバインドしても、スマートフォンから webhook が届きません。WSL2 内のループバックは軽量 VM 側であり、Windows 側やルーターから見たインタフェースと同一ではありません。
unit が動かない。systemd が PID 1 になる前にコピーした unit は飾りです。常駐の記事 で述べる運用と矛盾します。
スリープと VPN。長時間接続が無言で切れます。チャネル記事 のとおり doctor とログを対応づけてください。
TLS 終端。Windows で TLS を切って WSL に流すと WebSocket や allowedOrigins で齟齬が出ます。プロキシ記事 と突き合わせます。
複数の Node。ExecStart が古いプレフィックスを指していることがあります。インストールとロールバック で絶対パスを確認します。
WSL2 の名前空間
ディストリビューションは独自のルーティングを持ちます。ミラーモード等で一部が楽になっても、コールバック URL・証明書・ファイアウォールの図は依然として必要です。
外向き NAT は通りやすいため、「出は行くが入が不安定」は入方向の経路が閉じていないかを疑います。
LAN から届けるには WSL の 0.0.0.0 だけでは足りず、Windows の portproxy と FW が要ります。より安全なのはループバック＋リバースプロキシ、または SFTPMAC ホスト型リモート Mac にエッジを置くことです。
DNS の split horizon は OAuth を断続的に壊します。Windows と WSL の両方で解決結果を見てください。時刻ずれも短期トークンに影響します。
systemd を現実にする
wsl.conf で systemd=true にしたら wsl --shutdown 後に再起動し、PID 1 を確認します。
その後はサーバと同様に unit を整え、status → gateway → doctor → logs の階段で証拠を取ります。
ユーザーと秘密のパスを文書化し、/mnt/c の環境ファイルは権限と CRLF に注意します。
ポリシーで systemd が使えない場合は、バックオフ付きの監督が必要です。
journal の永続化とディスク上限を確認し、アップグレード前後に doctor 出力を残します。
判断表
| パターン | 利点 | リスク | 向く場面 |
|---|---|---|---|
| WSL ループバックのみ | 露出最小 | 外部から直テスト不可 | ローカル CLI |
| 全インタフェース＋portproxy | LAN 経路が明確 | 過剰露出しやすい | 自宅検証 |
| Windows で TLS 終端 | 証明書集約 | WebSocket ミス | 擬似本番デスク |
| SSH トンネル | 家庭に公網リスナー不要 | 不安定 | 個人実験 |
| ホスト型リモート Mac | 電源とネットが単純 | ベンダ評価 | 稼働率重視 |
| Docker Desktop | 再現性 | NAT が増える | Compose 標準化済み |
環境ごとに主経路は一つにし、半分ループバック半分 LAN は避けます。
コマンドの階段
# 1) systemd（例；ディストリの手順に従う）
# sudo tee /etc/wsl.conf <<'EOF'
# [boot]
# systemd=true
# EOF
# Windows: wsl --shutdown
# 2) init と unit
# ps -p 1 -o comm=
# systemctl status openclaw-gateway.service
# 3) WSL の待受
# ss -lntp | head
# 4) portproxy 例（管理者 PowerShell）
# netsh interface portproxy add v4tov4 listenport=8443 listenaddress=0.0.0.0 connectport=8443 connectaddress=<WSL-IP>
# 5) 診断（サブコマンドは版に合わせる）
# openclaw status
# openclaw gateway status
# openclaw doctor
# openclaw logs --follow
チケットには五つの出力をまとめて添付してください。スクリーンショットだけでは足りません。
読む順番
インストール → 常駐 → チャネル → プロキシ。更新は ロールバック と併読します。
層別 doctor：systemd・転送・証明書・VPN を変えるたびに再実行し、doctor が通っても沈黙ならチャネルログへ進みます。
Slack が会社プロキシ経由なら、WSL に渡す変数を明文化します。
ステージングと本番でオリジンを揃え、allowedOrigins の本番初出しを防ぎます。
FAQ と SFTPMAC ホスト型リモート Mac
ミラーネットワークで全部解決ですか
いいえ。待受・FW・コールバック URL を明示し、外部クライアントで検証してください。
doctor は通るがスリープ後に静か
スリープ時刻とログを照合し、必要ならゲートウェイを再起動します。
生産ゲートウェイをノートに置くべきか
通常は避けます。常時電源の機器かホスト型へ移します。
WSL で開発しているが Mac も要るか
役割分担が可能です。開発は WSL、ゲートウェイは SFTPMAC ホスト型リモート Mac に置き、Windows 側転送とスリープリスクを下げ、SSH／SFTP 運用と整合させます。
まとめ：WSL2 は名前空間と任意の systemd の組み合わせです。localhost・転送・TLS 終端を命名し、doctor を層別に実行してチャネルログと突き合わせてください。
限界：Windows ビルドや企業 VPN の組み合わせは網羅できません。統合コストが高ければゲートウェイをホスト型 macOS に移し、デスクは WSL のままにできます。
WSL のポートとスリープ負荷を減らしたい場合は、SFTPMAC の安定したリモート Mac を検討してください。