この記事で分かること
2026 年前半、OpenClaw(自ホスト型 AI Agent / Gateway)の導入事例が GitHub や技術ブログで目立つようになりました。検索では「OpenClaw」「Gateway」「API が届かない」「Clash」「OpenClash」が並び、多くの人がすでに Gateway を LAN 内の NAS やミニ PC に置いたあと、Claude・OpenAI・Google などの上流モデル API だけがタイムアウトする段階でたどり着きます。
本稿は、単一 PC に Clash Verge Rev を入れてターミナルだけ救う路線(Claude Code 向けの分流ガイドなど)とは補完関係にあります。ここでは OpenWrt + OpenClash をルーター/旁路由に据え、LAN 全体の端末が同じドメイン分流ポリシーを共有する前提で、OpenClaw Gateway からマルチベンダ API へ HTTPS が安定するまでを整理します。OpenClash の基本操作は購読インポートの実用手順もあわせて参照してください。
OpenClaw Gateway の役割と、詰まりやすいポイント
OpenClaw は、デフォルトで ポート 18789 に Gateway を立て、WebSocket 制御面と OpenAI 互換 HTTP(/v1/chat/completions、/v1/responses など)を同一ポートに多重化します。LAN 内のクライアント(Open WebUI、LobeChat、自前スクリプト)はローカルの Gatewayへ接続し、Gateway が設定に従ってAnthropic / OpenAI / Google 等のクラウド APIへ上流リクエストを送ります。
重要なのは、Gateway の待ち受けは loopback または LAN 向けである一方、上流 API への出口は Gateway を動かしているホスト OS のルーティングに依存する点です。つまり「ブラウザから OpenClaw の管理 UI は開けるのに、エージェント実行だけ失敗する」場合、問題は Gateway 設定よりそのホストから api.anthropic.com 等へ DIRECT で出ようとして詰まっていることが多いです。
公式ドキュメントでは openclaw gateway status で Runtime: running と Connectivity probe: ok を確認し、openclaw logs --follow で上流 TLS エラーを追う流れが推奨されています。ネットワーク層の切り分けは、ここから OpenClash 側のログと突き合わせます。
PC クライアントだけでは足りないケース
開発用ノート PC に Clash Verge Rev を入れ、HTTPS_PROXY で CLI を救う構成は手軽です。しかし OpenClaw を次のように運用すると、PC 限定の代理ではカバーしきれません。
- NAS や常時稼働サーバー上で Gateway を systemd / launchd 管理している(PC はスリープする)。
- スマホ・タブレット・ゲーム機から同一 LAN 内の Gateway にアクセスしたい。
- 家族やチームの端末も同じ AI API 分流ポリシーを共有したい。
- OpenClaw に加え、他の自ホストサービスも同じ出口ポリシーで運用したい。
このときルーター上の OpenClash は、透明プロキシ・TPROXY・DNS ハイジャックなどと組み合わせて「端末ごとにプロキシ設定を書かなくてもルールが効く」経路を作れます。OpenClaw ホストが Windows でも Linux でも、デフォルトゲートウェイを旁路由に向けるだけで挙動を揃えやすいのが実務的な利点です。
構成の型:メインルーターと旁路由(サイドルーター)
日本の家庭 LAN では、ISP 一体型ルーターをメインにし、OpenWrt 搭載のミニルーターを「旁路由」として追加する構成がよく見られます。OpenClaw Gateway ホストのデフォルトゲートウェイを旁路由の LAN IP(例:192.168.1.2)へ向けると、そのホストのすべての外向き TCPが OpenClash のルールを通ります。
メインルーター側で DHCP のゲートウェイを旁路由へ配る全端末一括運用も可能ですが、国内サービスまで迂回すると遅くなるため、OpenClaw ホストだけゲートウェイを差し替える段階的導入が安全です。二重 NAT や IPv6 の扱いは機種依存なので、変更前に現在の経路(ip route / route print)をメモしておいてください。
マルチプロバイダ向け:ルールに載せたいドメインの型
エンドポイントはアップデートで変わりうるため、固定リストの暗記よりログで実際に SYN が張られたホストを追う前提にします。OpenClaw が複数プロバイダを使う場合、検索・ログで繰り返し見かける型は次のとおりです。
- Anthropic:
api.anthropic.com、claude.ai関連 CDN。 - OpenAI:
api.openai.com、auth.openai.com、oaiusercontent.comなど。 - Google AI(Gemini 等):
generativelanguage.googleapis.com、aiplatform.googleapis.com、oauth2.googleapis.com。 - 共通:モデル利用に伴う
github.comやパッケージレジストリは別経路になり、API だけ成功して依存取得だけ失敗という分裂症状が起きます。
購読に GEOSITE や AI 向け rule-provider が含まれていても、MATCH より上の優先度や fake-ip との組み合わせで api.* が DIRECT に落ちる例は珍しくありません。OpenClash の接続ログで DIRECT 行を grep し、不足分をカスタムルールで足すのが確実です。
OpenClash 向けルール記述例(ポリシー名は読み替え)
以下は Mihomo / Clash Meta 互換の想像上のスニペットです。PROXY はご自身のポリシーグループ名(例:🔰 プロキシ選択)に置き換え、既存の MATCH より上へ配置してください。
# OpenClaw upstream — replace PROXY with your selector group
rules:
- DOMAIN-SUFFIX,anthropic.com,PROXY
- DOMAIN-SUFFIX,openai.com,PROXY
- DOMAIN-SUFFIX,oaiusercontent.com,PROXY
- DOMAIN-SUFFIX,googleapis.com,PROXY
- DOMAIN-SUFFIX,google.com,PROXY
- DOMAIN-KEYWORD,generativelanguage,PROXY
OpenClash では LuCI の「設定ファイル編集」や「ルール追加」タブから追記するほか、rule-providers で外部リストを定期取得する方法もあります。国内 CDN は DIRECT のまま、AI API だけ PROXY へ送る二段構成が帯域と安定性のバランスが取りやすいです。
ステップ・バイ・ステップ:OpenClaw × OpenClash の安定化
- OpenClaw Gateway の健康状態を確認:
openclaw gateway statusで running を確認し、失敗時はopenclaw logs --followで上流ホスト名と TLS エラーをメモする。 - OpenClash に購読を反映:LuCI で購読更新・プロファイル適用・コア再起動まで完了させる(詳細はOpenClash 実用手順)。
- AI 向けドメインルールを追加:上記スニペットまたはログベースの個別
DOMAIN行を MATCH より上へ。rule-providers を使う場合も最終的な優先順位を確認する。 - Gateway ホストの経路を旁路由へ:デフォルト GW を OpenClash ルーターの LAN IP に設定。必要なら DNS も旁路由へ向ける(Split DNS に注意)。
- OpenClash で LAN 透明代理を有効化:環境に応じ redir / TPROXY / 混合ポートを選び、ファイアウォールで LAN → ルーター自身への転送が通ることを確認する。
- curl で上流 API を検証:Gateway ホストから
curl -vI https://api.anthropic.com等を実行し、OpenClash ログで PROXY チェーンになっているか見る。 - OpenClaw を再試行:
openclaw channels status --probeや実際のチャット/エージェント実行で Connectivity probe が ok になるか確認する。
Gateway 自体は LAN 内:クライアントと上流を分けて考える
LAN 内の Open WebUI 等は http://192.168.x.x:18789 のようにローカル Gatewayへ接続します。この通信は通常プロキシ不要(NO_PROXY に LAN レンジを入れる)です。一方、Gateway プロセスが Anthropic 等へ出る HTTPS はホスト OS の出口が OpenClash を通る必要があります。
混同しやすいのは「Gateway の gateway.bind を LAN に広げた」場合です。LAN 公開時は gateway.auth.token 等の認証が必須であり、ポート 18789 をインターネットへ晒す事例(Shodan 上の未認証 Gateway)も報告されています。分流の話とセキュリティの話は別ですが、ルーター分流を整えたうえで Gateway は loopback または VPN 内に留める運用が無難です。
検証のコツ
- 二地点比較:OpenClaw ホストと、ゲートウェイ未変更の別端末で同時に
curlし、片方だけ DIRECT 落ちしていないか見る。 - DNS と fake-ip:OpenClash の fake-ip モードではドメインルールのマッチ順がずれることがある。ログで IP ではなくドメイン行がマッチしているか確認する。
- IPv6 経路:IPv6 だけ別出口になる場合、一時的に IPv4 限定で試すと差が出ることがある。
- ノード品質:ルールは正しくてもノード輻輳でタイムアウトする。OpenClash ダッシュボードでレイテンシ一括テストし、別リージョンへ切り替える。
うまくいかないとき
症状:Gateway は running だが Connectivity probe が失敗
想定原因: 上流 API が DIRECT、DNS 汚染、ノード TLS インタセプト、API キー期限切れ。
対処: OpenClash ログで api.* が PROXY に載っているか確認。curl で TLS を張り、キーは openclaw secrets reload 後に再試行。
症状:Anthropic だけ成功し OpenAI だけ失敗(またはその逆)
想定原因: プロバイダごとにルール漏れ、別ポリシーグループへ振り分け、地域制限。
対処: 失敗側のホスト名をログから拾い、個別 DOMAIN-SUFFIX を追加。必要ならプロバイダ専用のセレクターグループを用意する。
症状:OpenClaw ホストだけ遅いがスマホブラウザは快適
想定原因: ホストの GW が旁路由を向いていない、別 DNS、古い接続の Keep-Alive。
対処: ルーティング表と DNS 設定を再確認。Gateway プロセスを再起動し、OpenClash 側もコア再起動する。
よくある質問
OpenClaw Gateway 自体にプロキシ設定はありますか?
Gateway は主にローカル待ち受けと上流転送を担い、OS レベルの出口経路に依存します。コンテナで動かしている場合は、コンテナの network mode とホストの iptables / ルーティングもあわせて確認してください。
PC だけ Clash Verge Rev を入れれば足りませんか?
開発 PC のみなら Verge Rev で十分な場面も多いです。NAS 常時稼働・多端末共有・OpenClaw 専用ホストがあるなら、ルーター OpenClash のほうが再設定の手間が少ないことがあります。
ルールは購読に任せれば自動で AI ドメインが PROXY になりますか?
購読次第ではカバーされますが、OpenClaw が使う api.* が DIRECT に落ちる例は珍しくありません。ログベースで足す運用を推奨します。
単一 PC 代理と比べた Clash / OpenClash の強み
端末ごとに VPN アプリや PC クライアントを入れる方法は、初期は楽ですが、NAS 上の OpenClaw や IoT 端末には設定を配りにくく、「どのドメインがどの出口を使ったか」をログで説明しづらいです。結果として API タイムアウンのたびにアプリの再接続頼みになりがちです。
一方、OpenClash のような Clash 系スタックは、ルーター上でもポリシーグループ・ドメインルール・接続ログをユーザー側から俯瞰できます。OpenClaw が叩く Anthropic / OpenAI / Google AI を同じ YAML ポリシーで説明可能にし、LAN 全体へ配れる点が、PC 限定の Clash Verge Rev 記事群との決定的な違いです。外出先ノート PC では従来どおり Verge Rev をバックアップ経路にすれば、自宅 Gateway と思想を揃えた運用ができます。
環境に合わせたクライアントはサイトのダウンロード一覧から選べるので、ルーター固定だけでなく端末側の予備経路もあわせて用意しておくと、OpenClaw の可用性が上がります。