1. 設定とコアの起動を確認する

Clashクライアントのウィンドウが開いていても、プロキシコアが動作しているとは限りません。初回設定では、設定の読み込み、ローカルポートの待ち受け、出站ポリシーの動作、対象アプリからプロキシへの接続を、それぞれ確認しましょう。この順で調べれば、ポートの問題をサブスクリプションの不具合と誤認しにくくなります。

この記事では、デスクトップ版でよく使われるHTTP/SOCKS混合ポート 7890 を例に説明します。すべてのクライアントで固定の初期値というわけではありません。ClashX、Clash Verge Revなどmihomoコアを使うクライアントでは、設定画面や上書きの仕組みが異なる場合があります。実際に有効な設定と起動ログを確認してください。

  1. クライアントの「設定」または「Profiles」を開き、サブスクリプションをダウンロードしただけでなく、設定が選択されていることを確認します。
  2. 「プロキシ」または「Proxies」を開き、選択できるプロキシノードとプロキシグループがあることを確認します。DIRECT だけでは、プロキシ設定が反映されたとは判断できません。
  3. 「ログ」または「Logs」を開き、設定の解析結果、待ち受けアドレス、起動やポートのバインドに失敗した記録がないか確認します。
  4. 現在のコアの種類、混合ポート、動作モード、システムプロキシの状態を記録します。以降の変更は一度に一項目ずつ行ってください。

2. 混合ポート：待ち受けアドレスと使用中のプロセスを確認

mixed-port を使うと、HTTPプロキシとSOCKSプロキシで同じローカルポートを共有できます。ブラウザーの手動HTTPプロキシや、SOCKS5対応アプリの接続先に指定できます。ここでいう「混合」は、すべてのシステム通信を自動的に取り込む意味ではなく、PC上のすべてのアプリがプロキシを使うという意味でもありません。

以下は各項目の意味を確認するための最小限の設定例であり、そのまま接続できる完全なサブスクリプションではありません。既存の設定に同じトップレベルキーを重複して追加しないでください。クライアントが設定の上書きを生成する場合は、サブスクリプション更新で置き換わるキャッシュファイルではなく、指定の上書き設定画面で編集します。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

PC内だけで使う場合は、まず allow-lan: false のままにします。ログに表示される待ち受けアドレスが、たとえば 127.0.0.1:7890 のようなループバックアドレスであることを確認してください。実際のバインド先はクライアントとコアの設定にも左右されるため、単一のスイッチだけで待ち受け範囲を判断しないでください。

Windows：プロセスIDでポートの使用元を特定

PowerShellで次のコマンドを実行します。1つ目でTCP 7890を待ち受けているプロセスIDを確認し、2つ目でそのIDからプロセス名を調べられます。例のプロセスID 1234 を置き換えてから実行してください。

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 1234

別のプロキシツールがポートを使用している場合は、そのツールを正規の手順で終了するか、現在のクライアントに空いているポートを割り当てます。正体のわからないシステムプロセスを強制終了しないでください。ポートを 7891 に変更した場合は、システムプロキシ、ブラウザーの個別設定、コマンドラインのテストも同じ値に変更します。

macOS・Linux：ウィンドウではなく待ち受け状態を確認

# macOS：TCP 7890の待ち受けプロセスを表示
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：TCP 7890の待ち受けソケットを表示
ss -ltnp 'sport = :7890'

プロセス情報の表示に適切な権限が必要な場合があります。待ち受けプロセスが見つからず、ログに address already in use と表示される場合は、実際に競合しているポートを確認します。設定の解析エラーが出ている場合は、先に設定ファイルの該当箇所を修正してください。ウェブページが開けないときにノードを切り替えても、コアが待ち受けていない問題は解決しません。

3. 出站モード：ルール・グローバル・直接接続を個別に確認

モードは「コアに届いた接続をどの出站先へ送るか」を制御し、システムプロキシは「アプリが接続をコアへ送るか」を制御します。この2つは別々の設定です。グローバルモードを選んでも、システムプロキシに従わずTUNにも取り込まれないアプリは、プロキシを経由せず直接通信することがあります。

モード動作初回トラブルシューティングでの使い方
ルール / ruleルールを上から順に照合し、最初に一致したポリシーを適用普段の利用に適しています。対象ドメインに一致したルールを確認
グローバル / globalコアに届いた接続を、グローバルポリシーで選択した出站先へ送信ルールによる振り分けの影響を一時的に除外できます。グローバルグループの選択も確認してください
直接接続 / directコアに届いた接続を直接接続で送信ローカルネットワーク経由の通信との比較に使います。プロキシノードの動作確認には使いません
  1. まずルールモードを使い、実際に適用されるプロキシグループで特定のノードを選択します。自動選択による変数を一時的に減らせます。
  2. 対象のウェブサイトを開き、「接続」でドメイン、適用されたルール、出站経路を確認します。DIRECT と表示された場合は、ルールの設計どおりかをまず確認してください。
  3. ルールの影響を切り分ける必要がある場合は、一時的にグローバルモードへ切り替え、グローバルグループで直接接続が選ばれていないことを確認します。テスト後はルールモードに戻してください。

ノードの遅延テストに成功しても、その測定条件で応答があったことしかわかりません。すべてのウェブサイト、UDP、アプリのプロトコルが使えるとは限りません。特定のサイトだけ開けない場合は、その接続のログを確認してください。遅延の数値だけでサブスクリプション全体の不具合と判断しないようにしましょう。

4. デスクトップのシステムプロキシ：スイッチと接続先を確認

システムプロキシは、対応アプリにHTTPプロキシのアドレスを通知する機能であり、ネットワーク全体を通すトンネルではありません。初回テストではTUNをいったん無効にし、システムプロキシの経路だけを確認できます。ブラウザーのプロキシ拡張、別のVPN、TUNを同時に使うと、接続経路の切り分けが難しくなります。

Windows 11

「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「プロキシサーバーを使う」を確認します。クライアントでシステムプロキシを有効にしたら、アドレスとポートが待ち受け中の値（例：127.0.0.1 と 7890）に一致しているか確認してください。「セットアップスクリプトを使う」も有効な場合は、PACスクリプトがプロキシ選択に関与していないか確認します。スクリプトの結果を手動プロキシの結果と混同しないようにしてください。

アプリによっては個別のプロキシ設定やWinHTTP設定を使うため、ここでの設定に従うとは限りません。netsh winhttp show proxy で確認できるのはWinHTTPプロキシであり、Windowsの設定画面にある現在のユーザープロキシを完全に反映したものではありません。両者が異なっていても、確認せずにリセットしないでください。

macOS

新しいmacOSでは、「システム設定」→「ネットワーク」→現在接続中のサービス→「詳細」→「プロキシ」を開きます。Webプロキシ（HTTP）、セキュアWebプロキシ（HTTPS）、必要に応じてSOCKSプロキシのアドレスとポートが正しいか確認してください。ClashXのメニューバーにあるシステムプロキシの設定と、現在のネットワークサービスの状態を照らし合わせます。

scutil --proxy で現在のプロキシ情報を確認できます。HTTPとHTTPSの両方を混合ポートに向けるのは一般的な設定です。HTTPSプロキシの設定でも、通常はHTTP CONNECTでトンネルを確立します。ローカルプロキシのアドレスを https://127.0.0.1:7890 と記述する必要はありません。

Linuxデスクトップ

GNOMEの場合は、「設定」→「ネットワーク」→「ネットワークプロキシ」を開き、手動モードを選択してHTTP、HTTPS、SOCKSのアドレスとポートを確認します。他のデスクトップ環境では設定場所が異なり、すべてのアプリがデスクトップのプロキシ設定を参照するわけではありません。ターミナルの HTTP_PROXY、HTTPS_PROXY、ALL_PROXY がコマンドラインアプリに個別に影響する場合もあります。

5. Android・iOS・TUN：通信の取り込み範囲を確認

モバイル端末では通常、システムのVPNインターフェースを使って通信を取り込みます。デスクトップの「システムHTTPプロキシを有効にする」という確認方法をそのまま適用できません。Androidクライアントは初回接続時にVPN接続の許可を求めるのが一般的です。iOSクライアントではVPN構成の追加を求められる場合があります。インストールしたばかりで操作中のクライアントからの要求だと確認できた場合にのみ許可してください。

  • Android：VPNサービスが起動していることを確認し、アプリごとのプロキシ設定、アプリの除外、または選択したアプリのみを対象にする設定を確認します。アプリが除外されていると、クライアントが接続済みでも想定したプロキシ経路を通りません。
  • iOS：「設定」→「一般」→「VPNとデバイス管理」→「VPN」で、現在の接続を確認します。具体的なプロキシグループ、ルール、ログはクライアント側で確認してください。
  • デスクトップのTUN：通常、サービスモード、管理者権限、またはOSごとの許可が必要です。スイッチの色だけで判断せず、仮想インターフェースの作成やルート設定が成功したかをクライアントのログで確認します。
  • 他のVPN：モバイルOSでは、通常のVPNサービスを同時に複数実行できない場合があります。仕事用の構成、企業管理、アプリごとのVPNには別のルールがあるため、切り替える前に端末の管理ポリシーを確認してください。

TUNでIP通信を取り込む場合も、ルーティング、DNS、アプリの除外設定を考慮する必要があります。Fake-IPを使う場合、DNSリクエストは適切な名前解決経路に入り、仮想アドレス宛ての通信もコアに戻る必要があります。1つのアプリの問題を直すために、システムDNS、Fake-IP、ルール、MTUをまとめて変更しないでください。

システムプロキシは使えるのにTUNが動かない場合は、権限、仮想インターフェース、ルートの競合、DNSを優先して確認します。TUNは使えるのにブラウザーの手動プロキシが失敗する場合は、ローカルの待ち受けとブラウザー設定を確認してください。すべてのコンポーネントを同時に再インストールするより、経路ごとに比較するほうが効果的です。

6. ファイアウォール：ローカル接続とLAN共有を区別

PC上のブラウザーから 127.0.0.1:7890 に接続する場合と、スマートフォンからLAN経由でPCのプロキシを使う場合は、別のシナリオです。前者では通常、「プロキシを直す」ためにインターネット向けの受信ポートを追加で開放する必要はありません。後者では、クライアントでLAN接続を許可し、適切なアドレスで待ち受け、信頼できるネットワークからのアクセスをファイアウォールで許可する必要があります。

  1. まずPC上だけでテストし、LAN共有は無効のままにして、ネットワークの分離や受信ルールの影響を除外します。
  2. 共有が必要な場合は、スマートフォンとPCが相互に通信できる同じネットワークに接続されていることを確認し、PCのLANアドレスを使います。スマートフォン上の 127.0.0.1 はスマートフォン自身を指し、PCではありません。
  3. Windowsの「Windows セキュリティ」→「ファイアウォールとネットワーク保護」→「ファイアウォールによるアプリケーションの許可」で対象アプリを確認します。必要な信頼できるネットワークだけを許可し、パブリックネットワークまで一括で許可しないでください。
  4. LinuxでUFWなどのファイアウォールを有効にしている場合は、信頼できる送信元アドレスと必要なポートに限定してルールを設定します。ファイアウォール全体を無効にしたまま使わないでください。

セキュリティソフトがコアの外向き通信やTUNドライバーの操作をブロックすることもあります。ブロック履歴にある実行ファイルのパスと時刻を確認してから、許可するか判断してください。ポートを開放してもノードが使えるとは限らず、ドメインの名前解決が正常になるわけでもありません。接続ログで引き続き確認してください。

7. 明確なリクエストを1回実行して動作を確認

ブラウザーは接続の再利用やキャッシュ、拡張機能のプロキシを使うことがあります。ローカルHTTPプロキシの入口をまず確認するには、ターミナルで次のコマンドを実行します。公開されているドキュメント用の例示ドメインへのアクセスであり、特定のプロキシノードの実測結果を示すものではありません。

# Windows PowerShell：curl.exeを明示して実行
curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

# macOS / Linux
curl --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

--noproxy "" は、既存の除外リストによって今回のリクエストがプロキシを迂回するのを防ぎます。接続タイムアウトは10秒、全体のタイムアウトは20秒に設定し、テスト条件をそろえています。レスポンスヘッダーを受信できれば、このリクエスト経路から応答があったことを確認できます。クライアント側でも、プロキシノードと直接接続のどちらが選ばれたか確認してください。200 Connection established だけでは、その後のTLS接続や対象サーバーからのHTTPレスポンスが完了したとは限りません。

症状まず確認する項目次の手順
ローカルポートへの接続が拒否されるコアが起動していない、アドレスまたはポートが違う待ち受けプロセスと起動ログを確認
クライアントは接続を受け付けるが、外向き接続がタイムアウトする選択中のノード、ノードサーバーの名前解決、ネットワーク経路ノードを固定して同じ接続先に再試行
コマンドラインは成功するが、ブラウザーでは失敗するブラウザー独自のプロキシ設定、拡張機能、キャッシュ、システムプロキシブラウザーで実際に使われているプロキシの設定元を確認
ブラウザーでは成功するが、一部のアプリでは失敗するアプリがシステムプロキシに従わない、UDP、アプリごとの設定アプリの設定を確認し、次にTUNを個別にテスト

再現できる確認記録を残す

最後にクライアントとコアのバージョン、OSのバージョン、ポート、モード、プロキシグループの選択、テストした時刻を記録します。相談時にはログ全体ではなく、該当時刻の前後にあるエラー行を共有すると原因を特定しやすくなります。スクリーンショットを公開する前に、サブスクリプションURL、トークン、ノードの認証情報、個人のネットワーク情報を隠してください。

  • 設定の読み込みが完了し、ローカルの混合ポートを待ち受けるプロセスを確認できた。
  • ルールモードで、対象の接続に適用されたルールと出站ポリシーを説明できる。
  • システムプロキシまたはVPN/TUNによる通信の取り込みを確認し、別々の設定として把握している。
  • ファイアウォールの許可範囲が用途に合っており、クライアント終了後に無効なプロキシ設定が残らない。

この4項目を確認してから、自動選択、LAN共有、より複雑なTUN設定を順に有効にします。インストールやサブスクリプションの設定方法は初期設定ガイド、用語は用語集で確認できます。