目次
ChatGPT や Claude のホームページは開くのに、ログインやメッセージ送信で失敗する場合、ホームページを開き直しても原因は分かりません。失敗した操作のステータスコードと Clash の記録を照合し、プロキシに届いていないのか、接続経路が違うのか、サービスには届いたものの拒否されたのかを区別します。テスト中はノードを固定して、ログインのセッションと回答の継続をそれぞれ確認し、経路の変化で判断が曖昧にならないようにしましょう。
タイムアウト、403、回答の中断が意味すること
エラーの原文、発生時刻、直前の操作を記録し、ログインの失敗、ページ内の要素が表示されない問題、回答の中断を区別します。すべてを「つながらない」とまとめないでください。それぞれ異なるリクエストで起きている可能性があります。
エラーメッセージと調査する場所
| 確認された現象 | 最初に判断する内容 |
|---|---|
| ページの枠は表示されるが、アイコン、ボタン、サインイン部品が空白 | 静的リソースのドメインが別のルールまたは送信経路を使っている可能性がある |
| ERR_CONNECTION_TIMED_OUT / リクエストのタイムアウト | ネットワーク経路、ノード、または持続接続の失敗 |
| 401 / Unauthorized | サインイン状態、token、または API 認証情報 |
| 403 / Access Denied | サービスのポリシー、アカウント状態、またはリクエストの拒否 |
| 429 / Too Many Requests | 頻度または使用量の制限であり、ノード遅延ではない |
| 500 / 502 / 503 | サービス側または上流の一時的な異常。まず公式ステータスを確認する |
| 応答が途中で止まる | ストリーミング接続、ノード切り替え、またはネットワークの揺らぎ |
ページの枠は表示されるのに内容が読み込まれない場合は、スクリプト、画像、ログイン用の要素のリクエストを確認します。これらは異なる静的リソース用ドメインから取得されることがあります。ログインのリダイレクト、ファイルのアップロード、モデルのストリーミング回答も別のリクエストを送ります。Connections でリソースとモデルへのリクエストを一つずつ確認し、同じ安定した経路を使っているか確かめてください。別のページを開くことでこのテストを代用しないようにします。
ノードを固定して失敗した要求の出口を確認する
再現可能なテストを作る
Proxies でノードを固定する
テスト中に送信経路が変わらないよう、url-test または fallback は一時的に使わないでください。
Rule モードを維持する
Connections を開き、失敗する操作に対応するドメインとルールを確認できるようにします。
操作を一つだけ繰り返す
たとえば、サインインをクリックする、同じ短いメッセージを送る、または同じ小さなファイルをアップロードします。
ページの状態と Clash の結果を保存する
HTTP ステータス、接続の送信経路、所要時間、ログエラーを記録します。
失敗した操作が Connections にまったく表示されない場合、ブラウザまたはデスクトップアプリは現在の Clash を経由していない可能性があります。記録はあるものの DIRECT に一致する場合は、ルールを確認してください。固定ノードまで到達しても timeout になる場合に限り、別のノードやネットワークと比較する意味があります。
ログインの繰り返し：ブラウザーのセッションと認証要求を確認する
サインインループでは、アカウント情報を入力してもサインインページへ戻る、または確認コードの入力後もチャット画面へ進まないことがよくあります。まず同じブラウザのプライベートウィンドウで再試行し、期限切れのセッションや拡張機能の干渉を除外してください。最初からすべてのサイトデータを消すと、ほかのアカウントからも同時にサインアウトしてしまいます。
サインインをクリックした後のリクエストを確認します。認証リダイレクトが Clash に入らない場合は、ブラウザ側のプロキシ設定を確認してください。入った後に 401 または 403 が返るなら、通信はサービスへ到達しています。アカウント、サインイン方法、サービスの表示内容を続けて確認してください。地域や送信経路を頻繁に変えると、一度のサインインが複数のセッション環境にまたがることもあるため、テスト中はノードを固定します。
403 Access Denied：アカウント、地域、サービスの制限
明確な 403 や Access Denied は通常、リクエストがサイトに届いたものの拒否されたことを示します。ページに書かれた理由、アカウントの状態、地域制限、サービスの対応範囲、現在の出口が利用規約に合っているかを確認してください。この拒否は DNS のタイムアウトやポートが開いていない問題とは原因が異なります。
Global モードで確認できるのは、ルールがリクエストを誤った送信経路へ送ったかどうかまでです。サーバー側の拒否を通信成功に変えることはできません。Rule と Global の両方で、同じ固定ノードから同じ 403 が返る場合は、Clash の調整をやめ、アカウントまたはサービスのポリシーに対処してください。
長い回答が途切れる場合はノードと接続ネットワークを比較する
モデルの回答はデータを継続して返すため、遅延測定に成功しても数十秒の接続を安定して保てるとは限りません。テストではポリシーグループを select（手動選択）にし、ノードを固定して同じ長い質問を使い、中断時の Connections の終了理由を確認します。
同じ固定ノードを、自宅回線とモバイルホットスポットで一度ずつ試します。一方のネットワークだけで中断するなら、そのネットワークと DNS を重点的に確認してください。両方が近い位置で中断するなら、別のプロトコルまたはノードと比較します。一度の成功だけで結論を出さず、同じリクエストを少なくとも二、三回繰り返してください。
Web は正常でもデスクトップアプリや API が接続できない
ブラウザーは通常 Windows または macOS のシステムプロキシを使いますが、ターミナルの curl、SDK、一部のデスクトップアプリは独自のネットワーク設定を使う場合があります。同じ API リクエストの新しい記録が Connections にない場合は、すぐノードを変えず、アプリが現在のプロキシを使っているか確認してください。
コマンドラインツールでは、それぞれのドキュメントに従って HTTP_PROXY と HTTPS_PROXY を設定できます。システムプロキシを参照しない複数のアプリをまとめて取り込む必要がある場合に限り、TUN を検討してください。API が 401 を返した場合、リクエストはサーバーへ到達しています。プロキシ範囲を広げるのではなく、API key とリクエスト形式を確認します。
CLASH_PORT=7890
export HTTP_PROXY="http://127.0.0.1:${CLASH_PORT}"
export HTTPS_PROXY="http://127.0.0.1:${CLASH_PORT}"
export NO_PROXY="localhost,127.0.0.1,::1"
curl -I https://example.com$CLASH_PORT = 7890
$env:HTTP_PROXY = "http://127.0.0.1:$CLASH_PORT"
$env:HTTPS_PROXY = "http://127.0.0.1:$CLASH_PORT"
$env:NO_PROXY = "localhost,127.0.0.1,::1"
curl.exe -I https://example.com回答を最後まで受け取ってからノードの自動選択に戻す
ノードを固定して Rule モードに戻し、一度ログインして短いメッセージを一件送ります。元の問題が長い回答の中断だった場合は、同じ長いリクエストも繰り返してください。Connections に関連するリクエストが表示され、ページが元のエラーを返さず、回答も最後まで完了することを確認します。
短いメッセージと、元々失敗していたリクエストの両方が最後まで完了してから、url-test または fallback を戻します。自動グループを戻した後に問題が再発すれば、比較条件は明確です。アカウントとルールは変わらず、出口の選択が変わっています。