はじめに
OpenClaw から AI モデルの API を呼び出したとき、タイムアウト、名前解決エラー、認証エラーが発生することがあります。原因はひとつとは限りません。ネットワーク経路や DNS のほか、API キー、利用プラン、プロバイダー側の障害、モデル名の指定なども確認が必要です。Clash を使えば、通信を確認しながら、OpenClaw が接続する API の通信だけをプロキシへ振り分ける構成を検討できます。
この記事では、Clash Verge Rev と Mihomo を例に、プロファイル、ノード、ルールを順に確認する方法を紹介します。画面名や項目の配置はクライアントのバージョンによって異なるため、見つからない場合は使用中のクライアントの説明も参照してください。Clash は接続経路を制御するツールであり、API キーの発行や、プロバイダーの地域・利用条件を変更するものではありません。
この記事の目標
OpenClaw の API 接続で、アプリ側の設定、Clash の動作、ノード、分流ルールのどこに問題があるかを段階的に切り分けます。
1プロキシ設定の前に確認すること
まず、エラーの内容を記録します。「接続できない」という表示だけで判断せず、OpenClaw のログにある HTTP ステータス、エラーコード、発生時刻を確認してください。短時間に何度も再試行すると、利用制限に達する場合があります。調査中は連続したリクエストを避け、同じモデルへの単発のテストで結果を比べましょう。
- 401 / 403： API キーの誤り、無効化、権限不足、アカウントや地域に関する条件などが考えられます。キーをプロバイダーの管理画面で確認し、Clash の変更だけで解決しようとしないでください。
- 404： API エンドポイントやモデル ID の指定が正しいかを確認します。プロバイダーが指定する API の形式と、OpenClaw 側の設定が一致している必要があります。
- 429： リクエスト上限や利用枠に達していないか確認します。ノードを切り替えても、アカウント側の制限は通常解消されません。
- タイムアウト、DNS、TLS のエラー： ネットワーク経路、名前解決、システム時刻、ファイアウォール、プロキシ設定を確認します。
次に、OpenClaw が利用しているプロバイダーの API ホスト名と接続方式を確認します。複数のプロバイダーや互換 API を使っている場合は、実際に選択したモデルがどのエンドポイントへ接続するかを特定してください。サービスの仕様は変更されることがあるため、必要なドメインを推測で固定せず、プロバイダーの公式ドキュメントを基準にします。
API キーの取り扱い
API キーやサブスクリプション URL は秘密情報です。ログ、スクリーンショット、共有用の YAML に含めないでください。診断のためにログを共有する場合は、キー、アカウント情報、個人情報を必ず伏せてください。
2Clash Verge Rev で接続経路を整える
ここからは実際に設定を確認します。最初に Clash Verge Rev を起動し、利用可能なプロファイルを読み込んで更新します。プロファイルが古い、または更新に失敗している場合、表示されるノードやルールが現在の状態と異なることがあります。更新後、プロキシグループに利用可能なノードが表示されることを確認してください。
- Clash Verge Rev の設定で、使用中のコアが Mihomo など、現在のプロファイルに対応するものか確認します。コアや設定形式が合わない場合は、起動エラーやルールの読み込み失敗につながります。
- プロファイル画面で設定を更新し、エラーがないことを確認します。提供元が配布した設定を直接書き換えると、次の更新で変更が失われることがあるため、クライアントのルール設定やオーバーライド機能があればそちらを優先します。
- プロキシ画面で、目的の通信に使用するグループを選びます。複数のノードがある場合は、遅延だけでなく、安定性とプロバイダーの利用条件も考慮してください。
- システムプロキシを有効にして、ブラウザーなどの対応アプリで接続をテストします。OpenClaw がシステムプロキシを利用するとは限らないため、ブラウザーで成功したことだけで OpenClaw の経路まで確認できたとは判断しません。
API ドメインだけを特定のプロキシグループへ送る場合は、ルールの追加を検討できます。次の例では、AI-Proxy は実際のプロファイルに存在するプロキシグループ名へ置き換えてください。api.example.com も例示用の値です。プロバイダーが公開している正しいホスト名に置き換え、既存のプロファイルに合った位置へ追加します。
既存の設定に MATCH ルールがある場合、新しいルールは通常、そのルールより前に置く必要があります。ルールは上から順に評価されるため、先に広い条件で一致すると、後ろに追加した API ドメインのルールが使われないことがあります。また、例の MATCH 行をそのまま追加するのではなく、プロファイルが指定する既存の最終ルールを維持してください。
設定のポイント
ホスト名はプロバイダーの公式情報や実際の接続ログで確認します。必要以上に広いキーワードルールを追加すると、関係のない通信までプロキシへ送る可能性があります。
3OpenClaw から接続をテストする
ルールを追加したら、変更を保存してプロファイルを適用します。Clash の接続画面やログで、OpenClaw のテスト時刻に対象 API の通信が記録されるか確認してください。ログに表示されるドメインとルール、選択されたグループ、接続結果を照合します。API キーを含むリクエスト内容や認証ヘッダーを外部へ共有しないよう注意してください。
- Clash の接続を有効にし、対象 API ドメインの通信が接続ログに出るか確認します。記録がない場合は、OpenClaw が別のエンドポイントを使っている、または Clash を経由していない可能性があります。
- ログに通信がある場合は、適用されたルールと選択ノードを確認します。意図しない
DIRECTになっていれば、ルールの順序、ドメイン、グループ名を見直します。 - 同じ設定で別のノードを一つずつ試し、結果を比較します。一度に複数の設定を変更せず、変更した項目と時刻をメモすると原因を追いやすくなります。
- OpenClaw のログで応答コードを再確認します。通信がプロキシを通っても 401、403、404、429 が続く場合は、API キー、エンドポイント、モデル名、利用枠などアプリやアカウント側を確認します。
OpenClaw がシステムプロキシを認識しない場合、アプリや実行環境にプロキシを指定する方法が用意されているか、公式ドキュメントで確認します。環境変数を利用する実装では HTTP_PROXY や HTTPS_PROXY が使われることがありますが、対応状況や指定形式はアプリ、ランタイム、OS によって異なります。設定を追加する前に、その OpenClaw の実行方法でサポートされるかを確認し、不要になった設定は戻せるよう記録してください。
なお、TUN モードはシステムプロキシに対応しないアプリの通信も扱う選択肢ですが、管理者権限の承認やルーティング設定が必要な場合があります。まず通常のプロキシ設定とログで状況を調べ、それでも対象アプリの通信が見つからない場合に限り、TUN モードを検討すると切り分けやすくなります。DNS モードを変更する際も、既存のプロファイルとの相性を確認し、一度に複数の項目を変更しないでください。
| 確認結果 | 考えられる原因 | 次の確認 |
|---|---|---|
| Clash のログに通信がない | アプリがプロキシを使っていない、または別のホストへ接続している | OpenClaw の接続先とプロキシ対応状況を確認 |
| 意図しないルールやノードが選ばれる | ルールの順序、グループ名、プロファイルが不一致 | 既存ルールとプロファイル更新状況を確認 |
| 通信は通るが API エラーが返る | 認証、モデル名、利用枠、プロバイダー側の応答 | OpenClaw とプロバイダーの設定を確認 |
安定した構成を保つには、最小限のルールから始め、動作を確認した後で必要な設定だけを追加します。問題が解決したら、使用したノード、ルール、OpenClaw のエラーコードを記録しておくと、プロファイル更新後の再発にも対応しやすくなります。ネットワークの経路変更はプロバイダーの利用規約や地域の法令に従って行い、API キーの漏えい防止にも配慮してください。