1. 典型症状：クライアントは止まったのに「プロキシ」だけ生きている
Clash for Windows、Clash Verge、GUI for Clash など、多くの派生は「起動中に システムプロキシを有効化し、127.0.0.1 や ミックスドポート の番号を Windows に登録する」動きを取ります。正常終了時に元へ戻せばよいのですが、強制終了、クラッシュ、旧バージョンの不具合、手動でタスクを落とした直後、などのタイミングで オフ用の API が呼ばれないと、プロキシのスイッチだけ ON のまま、という状態が残ります。
その結果、ブラウザは毎回まずローカルのアドレス（例：127.0.0.1:7890）に接続しにいき、Clash のプロセスがいなければ接続拒否やタイムアウト、エラーページの「プロキシの問題である可能性」といった表示になります。逆に、Windows ターミナルの curl や、プロキシを見ない 別アプリでは「普通に繋がる」という分かれ方も起こり、利用者を混乱させます。ここでいう不調の中心は、ルール付き中継コアではなく、OS が参照する「HTTP/HTTPS 用の手先アドレス」です。
| 見え方 | まず疑う層 | 本稿の該当節 |
|---|---|---|
| Edge／Chrome だけ不調、設定でプロキシ ON | ユーザー系 WinINET／手動スイッチ | §3～4 |
| ストア外アプリ・一部サービスだけ | WinHTTP（別ストア） | §5 |
| 再ログオン後も戻る | レジストリの固定値、GPO | §6 |
| git／npm だけ不調 | 環境変数 HTTP_PROXY 等 |
§7 |
2. Windows には「ユーザ向けプロキシ」と「WinHTTP」が別にある
用語を混同しないことが重要です。多くの デスクトップ ブラウザは、ユーザープロファイルの下の WinINET 設定、あるいは独自の上書きと組み合わせて、OS が提示する システム代理に従います。一方、.NET 系の一部バックグラウンド処理や、Windows Update、一部のコマンドラインツールは、別の WinHTTP ストアを見ます。だから 設定アプリの「プロキシ」をオフにしても、まだどこかで古い 代理が残る、と感じることがあります。どちらも最終的には「外部へ出る前の次ホップの指定」ですが、書き込み元と消し方が違います。
また、従来の コントロール パネルにあった インターネット オプション（内部では旧 IE 設定系と同一ストア）も、同じ層の別UIです。「見た目が古いから無関係」と捨てると、GUI のトグルと実ストアのズレに気づきにくくなります。本稿では、まず誰にでも分かる Windows の設定から入り、必要な人だけ 管理者権限の netsh と レジストリ エディタへ進む段階にします。編集作業の前に、重要な分岐の バックアップを取る習慣をおすすめします。
3. 設定：ネットワークとインターネット → プロキシ
Windows 11 では 設定 → ネットワークとインターネット → プロキシ、Windows 10 でもほぼ同階層に「手動でプロキシをセットアップ」があります。ここで 使用するにチェックが入り、アドレスに 127.0.0.1、ポートに 7890 や 1080 が残っていないかを確認し、オフにします。社内 WPAD や 構成スクリプト（PAC）を使っている環境では、ここを安易に消すと本業用の定義まで消えます。自宅 PC か、自分で Clash のために書いた行だけを対象にしてください。
下の方にある「ローカル（イントラネット）のドメインをプロキシ サーバーを使わない」などの例外リストに、<local> や 127.0.0.1 が入っている例もあります。これは通常、直接アクセス用の抜け道で、代理が残る主因ではありません。先に大きいトグル（手動 プロキシの有効／無効）を確実に切ることが優先です。変更直後、ブラウザを完全終了（バックグラウンドも含め可能なら）してから同じ URL を開き直してみてください。
4. インターネット オプション：LAN 設定（レガシー互換の束）
Win + R で inetcpl.cpl を開き、接続タブの LAN の設定を押します。ここで「自分の LAN にプロキシ サーバーを使う」にチェックが入り、アドレスにローカルが残っていないかを確認します。多くの Clash 系 GUIはこのストアに同時に触れるため、設定アプリと見かけが二重化していることがあります。片方を直しても、もう片方のチェックが残ると、再ログイン後に同じ 代理の残留が戻る、という挙動になりがちです。
「自動的に設定を検出」や「構成スクリプトを使う」に依存している職場ネットでは、この画面を空にしすぎると イントラネット へ出られなくなります。自宅用の クライアントで試す場合は、書き換え前の画面をスクリーンショットに残し、直接接続に戻して動作を見てから、不要な行だけ削る、と段階を踏むと安全です。
5. WinHTTP：管理者コマンドで表示とリセット
PowerShell または コマンド プロンプトを 管理者として開き、次を実行して現在値を覚えておきます。netsh winhttp show proxy の出力に、Proxy Server の行で 127.0.0.1 などが出ていれば、WinHTTP 層に残っています。多くの場合、Clash 本体の「システム プロキシ モード」がここまで波及させたか、旧ツールのインポートが混ざったかのどちらかです。不要であれば netsh winhttp reset proxy で、直接接続用の初期状態に戻せます。
# Show current WinHTTP proxy (admin)
netsh winhttp show proxy
# Reset WinHTTP to direct (admin) — use when no corporate proxy
netsh winhttp reset proxy企業 PC では、IT 部門の プロキシを netsh でも固定している例があり、リセットは職場ポリシー違反になることがあります。所属組織のルールに従ってください。自宅で Clash だけのために書いた行が残っている文脈では、上記 reset は有効な最終手段の一つです。
reset は WinHTTP 側の指定を消します。会社の明示プロキシを上書きしていると、Windows Update 等が止まる可能性があります。迷ったら、表示結果を控えたうえで担当窓口に相談してください。
6. レジストリ：Internet Settings の ProxyEnable など
上記の GUI を一通り直しても再発する場合、HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings 付近の ProxyEnable、ProxyServer、AutoConfigURL 等が、別プロセスに再書き込みされているか、手元の作業で矛盾したまま、という疑いが出てきます。レジストリ エディタは誤操作で OS に影響が出るため、触る前に当該キーのエクスポート、または システムの復元点の作成を推奨します。値の意味は、ProxyEnable が 1 なら有効、0 なら無効、ProxyServer が 127.0.0.1:ポート 形式、などが典型です。
また、グループ ポリシー や、セキュリティ製品の「常にこのプロキシを強制」機能が併用されていると、ユーザーが上書きしても起動直後に戻る、という挙動になります。家庭向け 掃除の記事の範囲を越えるため、そういった兆候（ドメイン参加端末、会社支給品）のときは、自己判断での直結改変を避け、管理者向け文書に依頼してください。逆に、個人所有の Windows マシンで、古い Clash 用の行だけを消したい場合は、設定とレジストリの両方を同じ方針（直接アクセス）に揃えれば、多くの場合ここで代理の残留のループは止まります。
7. ブラウザは直ったが git／npm だけ古い「代理」を見る
システム プロキシの話を終えたあと、ターミナル だけ不調が残る場合は、ユーザー／システムの環境変数 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY を確認します。Clash のドキュメントや、シェル用の導入記事（当サイト ターミナルと環境変数は主に macOS／Linux 向けですが、概念は共通）で一度設定した値が、クライアントの停止と無関係に残る、というのは珍しくありません。
PowerShell で Get-ChildItem Env: | Select-String -Pattern 'PROXY' のように一覧するか、システムのプロパティから該当変数を空に戻します。混同しがちなのは NO_PROXY の例外だけ直して、本体の HTTPS_PROXY が 127.0.0.1 のまま、という欠け方です。ここは Windows 固有の IE 設定ではなく、シェル起動毎の上書きなので、本稿のタイトルにある「システム 代理の掃除」とは別枠の掃除として捉えてください。
8. これは別件：TUN モード、DNS、fake-ip
症状が「プロキシ サーバーに接続できない」系の文面であれば本稿の層の可能性が高い一方、Clash 稼働中にだけ発生し、終了後は普通に戻るなら、TUN や仮想アダプタ、ルート周りの影響を疑います。当サイトの TUN モードと Windows の切り分けは、そのための専用稿です。名前解けない・特定ドメインだけ、という分かれ方なら、fake-ip と DNS フィルタの記事を先に当てる価値があります。
要するに、代理の残留は「クライアントはいないのに、OS かアプリの設定だけが、まだ中継に向いている」問題であり、コアの YAML や、ノード遅延そのものは別の話です。層を切り分けたうえで、必要なら再び 公式の入手経路から Clash を導入し、正常系の システムプロキシ 連携（終了時に戻ること）を試す、という流れにすると安心です。オープンソースの参照は GitHub でも可能ですが、インストール用パッケージの第一入手先として当サイトの ダウンロード ページを第一に使う、という整理で十分です。
9. まとめ
Clash を閉じた直後の「ブラウザだけ不調」は、Windows の システム代理が 127.0.0.1 のまま、という代理の残留にかなりの確率で当たります。設定アプリと従来の LAN 設定で手動 プロキシを切り、必要なら netsh winhttp、それでも戻る場合は レジストリ or ポリシー領域、ターミナルだけ残るなら環境変数、と階層をずらして掃除すれば、多くの場合は 直接接続に復帰できます。誤解しがちな macOS の システム プロキシや Network Extension の話題とは対象 OS が違い、fake-ip／DNS の不調とも層が違います。トラブルで消耗したら、同じ枠組みのまま、メンテの行き届いたクライアントに揃えておくのが再発防止の近道です。
→ Clash を無料でダウンロードし、落ち着いた システムプロキシ連携を試す