ブラウザは使えるのに Claude Code が接続できない理由
ブラウザで Claude を開けるのに、ターミナルの Claude Code だけがタイムアウトする場合、最初に疑いたいのはアカウントではなく通信経路です。ブラウザは OS のシステムプロキシ設定を参照することが多い一方、ターミナルで起動した CLI はシェルの環境変数や実行環境の設定に従います。そのため、Clash Verge でシステムプロキシを有効にしただけでは、Claude Code の通信までプロキシ経由になるとは限りません。
とくに「ログイン画面は開くが認証後に戻らない」「プロンプトを送ると応答待ちのまま止まる」「別のターミナルでは動くのに IDE 内蔵ターミナルでは失敗する」といった症状は、ブラウザと CLI の出口が一致していないときに起きやすいものです。Claude Code は認証、API リクエスト、利用状況の確認など複数の通信を行うため、一部の接続だけが失敗しても、画面上では単に接続エラーや長い待ち時間として見えることがあります。
まずは問題の起きているターミナルを特定してください。通常のターミナル、VS Code などの IDE 内蔵ターミナル、SSH 接続先、WSL、コンテナは、それぞれ別の環境変数やネットワーク経路を持つ場合があります。どこで失敗しているかを分けて確認すれば、Clash Verge の設定をむやみに変更せず、原因の範囲を絞れます。
Clash Verge のポートと接続状態を確認する
Clash Verge を開き、現在有効なプロファイル、コアの稼働状態、モード、mixed-port を順に確認します。画面の名称や配置はバージョンによって異なりますが、重要なのは「いま選択されている設定が実際に読み込まれているか」と「ターミナルから到達させるプロキシポートがどれか」です。設定ファイルを編集した場合は、保存しただけで反映済みと思い込まず、再読み込み後にエラー表示がないことも確かめてください。
次に、Claude Code を実行するのと同じ端末から、mixed-port に TCP 接続できるか試します。以下の例ではポートを 7897 としています。自分の Clash Verge に表示されている値が異なる場合は、その数値へ置き換えてください。接続できないときは、ポートの誤り、コアの停止、ローカルのファイアウォール、別のアプリによるポート競合などを確認します。
curl -I --proxy http://127.0.0.1:7897 https://api.anthropic.comこの確認では、HTTP の成功応答が返ることだけを目的にしていません。API の認証情報なしでアクセスした場合、エラー応答や認証を要求する応答が返ることがありますが、プロキシを通して TLS 接続まで進めたかどうかを判断する材料になります。反対に、接続拒否や名前解決エラー、長時間のハングが出る場合は、Claude Code の設定へ進む前にポートと Clash の接続ログを見直しましょう。
接続ログでは、テストした時刻に新しい通信が現れるか、接続先のホスト名と選択されたルール・プロキシグループが意図どおりかを確認します。ログに何も出ないなら、curl が指定したプロキシを使えていない可能性があります。通信は表示されるものの失敗する場合は、該当行の接続先、ルール名、エラーの種類を記録しておくと、後から設定変更の前後を比較しやすくなります。
ターミナルにプロキシ環境変数を設定する
mixed-port への接続が確認できたら、Claude Code を起動するシェルにプロキシ環境変数を設定します。環境変数は、通常ターミナルで設定しても、すでに起動している IDE や別の SSH セッションへ自動で伝わるとは限りません。まずは一時設定で短く試し、動作が確認できてから必要なシェル設定ファイルへ追加する方法が安全です。
macOS や Linux の zsh、bash では、次のように設定できます。ポート番号は自分の Clash Verge の値に合わせてください。HTTP と HTTPS の両方を設定しておくと、ツールや依存ライブラリによる変数の参照差を減らせます。
export HTTP_PROXY="http://127.0.0.1:7897"
export HTTPS_PROXY="http://127.0.0.1:7897"
export ALL_PROXY="socks5h://127.0.0.1:7897"
ALL_PROXY に指定する方式は、Clash Verge 側のポートが SOCKS5 接続を受け付ける場合に限って利用してください。mixed-port は HTTP と SOCKS の両方を受け付ける構成が一般的ですが、ポートの種類や設定は環境によって異なります。迷った場合は、まず HTTP_PROXY と HTTPS_PROXY の二つだけを設定し、接続ログと実際の挙動を見てから追加する方が切り分けやすくなります。
Windows の PowerShell では、同じターミナルセッションに対して次のように設定します。Claude Code を起動する前に実行し、そのウィンドウを閉じると一時設定も終了します。
$env:HTTP_PROXY = "http://127.0.0.1:7897"
$env:HTTPS_PROXY = "http://127.0.0.1:7897"
$env:ALL_PROXY = "socks5h://127.0.0.1:7897"
設定後は、同じシェルで claude を起動して、短いプロンプトを送ります。以前から開いていたターミナルでは、新しい環境変数が反映されないことがあります。IDE 内蔵ターミナルで試す場合は、IDE 自体を環境変数の設定後に起動し直すか、IDE のターミナル内で改めて値を設定してください。シェル設定ファイルへ恒久的に書き込む場合も、誤ったポート番号が残らないよう、変更箇所を記録しておくと戻しやすくなります。
接続ログとルールで原因を絞り込む
環境変数を設定してもつながらない場合は、設定を一度に何か所も変えず、失敗の種類を分けて調べます。Clash Verge のログで、認証を試した時刻やプロンプト送信時刻に通信が発生したかを見てください。通信が出ていない場合は、ターミナルが環境変数を読んでいるか、CLI を起動した場所が想定したシェルかを確認します。接続先が表示される場合は、選択されたルールと出口が意図したものかを追います。
| 見えている症状 | 優先して確認する点 | 次の確認方法 |
|---|---|---|
| ログに通信が出ない | 環境変数、実行したターミナル、ポート番号 | 同じシェルで変数を表示し、curl のプロキシ接続を再試行する |
| 接続先は出るがタイムアウトする | ルールの一致先、選択中のプロキシグループ、ノード状態 | 接続ログのエラーとルール名を確認し、別の安定した出口で比較する |
| 認証後に CLI へ戻らない | ブラウザとターミナルの経路、ローカルのコールバック処理 | 認証の直前からログを確認し、ブラウザだけでなく CLI 側の接続も追う |
| 一部のネットワークでのみ失敗する | VPN、企業プロキシ、WSL・コンテナのネットワーク境界 | 構成を一つずつ切り替え、成功する条件との差分を記録する |
ルールを調整するときは、ログで実際に確認できた接続先をもとに判断してください。Claude Code の通信先を一つの固定リストだけで決めつけると、認証方式やサービス側の変更、利用環境の違いを取りこぼすことがあります。ホスト名を追加する場合は、既存ルールの順序を確認し、広い条件のルールより前に置く必要があるかを検討します。Clash のルールは上から評価されるため、後ろに追加した項目が先行ルールに先取りされていれば、期待したポリシーには到達しません。
さらに、システムプロキシ、TUN、環境変数を同時に有効化すると、通信経路が重なり、何が接続を成立させたのか分かりにくくなることがあります。最初はターミナルの環境変数と mixed-port の組み合わせで動作を確認し、それでも必要な場合に限って TUN を検討してください。WSL やコンテナ内から実行する場合、127.0.0.1 がホスト側の Clash Verge を指さない構成もあります。その場合は、環境のネットワーク方式に合った到達先を確認し、ホスト側のポートを不用意に外部公開しないよう注意してください。
安全に運用するための確認手順
動作が安定した後も、環境変数が意図せず別の作業へ影響しないように管理しましょう。とくに NO_PROXY に広い範囲を指定すると、対象サービスへの通信がプロキシを経由しなくなることがあります。逆に、社内ホストやローカルサービスまで外部プロキシへ送ってしまうと、認証や開発サーバーへの接続に支障が出る場合があります。適用範囲を理解したうえで、必要な例外だけを明示してください。
認証トークン、API キー、購読 URL、環境変数の値をログやスクリーンショットと一緒に公開しないことも重要です。トラブルを相談するときは、秘密情報を伏せたうえで、OS、使用しているターミナル、Clash Verge のポート種別、発生時刻、エラーの種類を共有すると再現条件が伝わりやすくなります。ログを採取する際も、アカウント識別子や社内ドメインなど、公開すべきでない情報が含まれていないか確認してください。
うまくいかないときは、まず Clash Verge のコアと mixed-port、次に curl などでの経路確認、その後にターミナルの環境変数、最後にルール順という順番で調べると、変更の影響を追いやすくなります。ブラウザのシステムプロキシだけに頼る方法は CLI への適用範囲が分かりにくく、手作業で複雑なルールを増やす方法は保守が難しくなりがちです。Clash V.CORE なら接続状態やルールを一元的に確認しながら、今回のようなターミナル通信の切り分けにも取り組めます。自分の環境に合ったクライアントを試したい方は、ダウンロードへ進んでください。