目次
以前、Clash を終了すると接続できなくなり、開き直すと復旧したのであれば、Windows が古いプロキシポートにリクエストを送り続けている可能性があります。ブラウザー、システムのダウンロード、ターミナルのプロキシ設定は独立しているため、一か所を消してもほかが復旧するとは限りません。失敗するアプリの設定場所を調べ、会社が指定するプロキシ情報は残してください。プロキシエラーがないのに端末全体が接続できない場合は、仮想アダプターとルートを確認します。
古い手動プロキシと PAC を無効にしてブラウザーの直接接続を戻す
Windows 11 で確認する場所
プロキシ設定を開く
「設定 → ネットワークと Internet → プロキシ」を開き、まず「プロキシサーバーを使う」が有効なままか確認します。
古い手動アドレスを無効にする
アドレスが 127.0.0.1 で、ポートが Clash の mixed-port と一致する場合は、「プロキシサーバーを使う」を無効にして保存します。
設定スクリプトを確認する
「セットアップスクリプトを使う」に古い PAC アドレスが入っている場合も無効にし、「設定を自動的に検出する」はいったん残します。
ブラウザを完全に終了してから再テストする
すべてのブラウザウィンドウを閉じ、バックグラウンドプロセスが終了したことを確認してから、シークレットウィンドウを一つ開き、通常の HTTP サイトと HTTPS サイトへアクセスします。
Windows のページですでに無効に見える場合は、Win + R から inetcpl.cpl を実行し、「接続 → LAN の設定」でもう一度確認します。古いプログラムの中には、この Internet オプションからユーザープロキシを読み込むものがあります。有効スイッチを残してアドレスだけを変更しないでください。
この手順で復旧したら、まず Clash を終了した状態のままにします。ルーター管理画面と普段使うサイトを直接開ければ、残っていたユーザープロキシを特定できています。この段階で winsock reset を実行したり、ネットワークアダプターを削除したりする必要はありません。
終了後にプロキシ接続エラーが出るときに残りうる設定
Clash の動作中は正常で、終了直後に ERR_PROXY_CONNECTION_FAILED が出て、再起動すると戻る場合は、システムがまだ 127.0.0.1 の古いポートに要求を送っていることが多いです。待ち受けが停止すると connection refused になります。
スマートフォンを同じ Wi-Fi に接続するか、パソコンからルーターの管理アドレスに ping を送ります。ほかの端末はインターネットを使え、パソコンからもルーターに届くなら、先にアダプターをリセットしないでください。Windows のユーザープロキシ、自動設定スクリプト、WinHTTP、環境変数、個々のアプリのプロキシは別々の設定です。どれに古いアドレスが残っているか確認します。
各エラー症状が通常示す箇所
| 症状 | 優先して確認すること | よくあるメッセージ |
|---|---|---|
| Chrome、Edge、システムアプリがすべて接続できない | Windows の手動プロキシまたは設定スクリプト | ERR_PROXY_CONNECTION_FAILED |
| ブラウザは正常だが、インストーラーまたはシステムサービスが失敗する | WinHTTP | 接続を拒否される、またはダウンロードできない |
| ターミナル内の Git、npm が失敗する | 環境変数とツール独自のプロキシ | Failed to connect to 127.0.0.1 |
| 一つのブラウザだけに問題がある | 拡張機能、ブラウザポリシー、セキュア DNS | 他のアプリからは引き続きアクセスできる |
| TUN を一度でも使うと、終了後にすべて切断される | 仮想ネットワークアダプター、サービス、ルート | 明確なプロキシエラーがない |
ブラウザは復旧したのにシステムのダウンロードが失敗する場合は、WinHTTP を確認する
WinHTTP は主にシステムサービス、インストーラー、一部の企業向けプログラムで使われ、Windows の「プロキシ」ページとは別のスイッチです。ブラウザでは直接接続できるのに、winget、特定のインストーラー、サービスが古いプロキシへ接続しようとする場合に限り、ここを確認します。
netsh winhttp show proxy
# 只有输出仍显示旧代理时才执行
netsh winhttp reset proxyターミナルだけ接続できない場合は、多くの場合、Clash の終了後も変数またはツールの設定が残っている
多くの開発チュートリアルでは HTTP_PROXY、HTTPS_PROXY、ALL_PROXY を一時的に設定し、Git や npm の設定へプロキシを保存する場合もあります。これらは Clash のウィンドウを閉じても自動では消えません。新しく開いた PowerShell で現在のプロセスレベルとユーザーレベルの変数を確認し、その後、失敗するツール独自の設定元を調べます。
Get-ChildItem Env: | Where-Object Name -match '^(HTTP|HTTPS|ALL|NO)_PROXY$'
[Environment]::GetEnvironmentVariable('HTTP_PROXY', 'User')
[Environment]::GetEnvironmentVariable('HTTPS_PROXY', 'User')
git config --show-origin --get-regexp "http.*proxy"
npm config get proxy
npm config get https-proxyGit に Failed to connect to 127.0.0.1 port 7890 と表示される
主な原因：Git の設定または環境変数が古いポートを参照している
対処方法：--show-origin が返したファイルにある該当 proxy 項目だけを削除し、他の Git 設定まで無差別に消去しません。
npm は失敗するが curl は正常
主な原因：npm のユーザー設定に proxy/https-proxy が残っている
対処方法：取得元を確認してから npm config delete proxy と npm config delete https-proxy を実行します。
新しいターミナルは正常だが、古いターミナルでは失敗する
主な原因：古いウィンドウが起動時のプロキシ変数を引き継いでいる
対処方法：古いターミナルを閉じて開き直します。システムのネットワーク設定を変更する必要はありません。
ブラウザーだけ失敗する場合の拡張機能、ポリシー、セキュア DNS
まずシークレットウィンドウを開き、すべてのプロキシ拡張機能を無効にします。拡張機能が独自の PAC へ切り替えたり、システムプロキシの無効化後もリクエストを取り込んだりする場合があります。企業向けブラウザではポリシーからプロキシが設定されることもあり、chrome://policy または edge://policy で取得元を確認できます。管理ポリシーがある場合は、レジストリの変更で強制的に上書きしないでください。
ERR_NAME_NOT_RESOLVED は名前解決失敗を示す可能性が高く、ERR_PROXY_CONNECTION_FAILED は明確にプロキシ接続を示します。前者では、比較のためブラウザの「セキュア DNS を使う」を一時的に無効にできます。403 または 404 を受信できれば、ネットワークリクエストはサーバーへ到達しているため、キャッシュ消去やネットワークアダプターのリセットを続けないでください。
プロキシエラーがないのにコンピューター全体がオフラインなら、TUN サービスとデフォルトルートを確認する
TUN は仮想アダプターを作成してルートを変更します。クライアントが正常に動作中なら、そのクライアントで TUN を無効にしてトレイから終了します。route print で既定ルートが実際の Wi-Fi または有線のゲートウェイに戻ったか確認します。別の VPN も使う場合があるため、仮想アダプターがあるだけでドライバーを削除しないでください。
影響を受けるサービス、版が不明なサービス、安全性確認で拒否されたサービスは停止したままにします。Windows のサービス管理画面または管理者を通じて対象サービスを停止し、残存設定の除去のために再起動しないでください。
Get-NetAdapter | Sort-Object Status, Name
route print- デフォルトルートが停止済みの仮想インターフェースを参照したまま
- まず該当する VPN/TUN サービスを通常の手順で無効にしてコンピューターを再起動します。インターフェース名を記録した後で、クライアントコンポーネントをアンインストールするか判断してください。
- 物理ネットワークアダプターにゲートウェイがない、または 169.254 アドレスになっている
- これはすでに DHCP またはローカルネットワークの問題です。プロキシ設定を変更し続けず、Wi-Fi へ再接続するかアドレスを更新してください。
- ルートとアドレスは正常だが、DNS だけが失敗する
- ネットワークアダプターの DNS とブラウザのセキュア DNS を確認します。コンピューター全体のネットワークリセットは、バックアップ後の最後の手段にしてください。
「Clash を終了した後も直接接続できる」ことを修正完了の基準にする
Clash 終了後に一項目ずつ確認する
- Windows の「プロキシサーバーを使う」と古い PAC がどちらも無効
- 直接接続が必要なコンピューターで netsh winhttp show proxy に Direct access と表示される
- 新しいターミナルに古いポートを指すプロキシ変数がない
- ブラウザ、システム更新の確認、少なくとも一つのターミナルツールからアクセスできる
- コンピューターを再起動しても結果が元へ戻らない
Clash を再び有効にするときは、取り込み方式を一つずつ試します。まずシステムプロキシを使い、有効化時と終了時に設定が正しく戻るか確認してください。システムプロキシを使わないアプリが実際にある場合に、TUN を個別にテストします。Windows では、実際にインストールされているサービスにセキュリティ修正が適用済みである根拠を先に確認し、影響を受ける版や版が不明なサービスは停止したままにします。クライアント、ブラウザー拡張機能、スクリプトに同時にシステムプロキシを変更させると、次に設定が残った際に原因を特定しにくくなります。