01 · クライアントをインストールしたのに接続できないのはなぜ?
クライアントは設定を管理してプロキシコアを起動するソフトウェアで、ノードはリモート側の出口を提供します。インストールが完了しても、端末で実行できる状態になっただけで、利用可能なノードが手に入ったわけではありません。初回利用時は、設定の読み込み、設定の有効化、出口の選択、アプリの通信をプロキシに通す作業が必要です。
Clashは、ルールベースのプロキシコアや関連クライアントを指す一般的な呼び方です。Clash Metaは後にmihomoとして開発が続けられています。mihomoを採用したGUIクライアントは、より多くのプロトコルや設定項目に対応していることが一般的です。クライアントのバージョンとコアのバージョンは別々の情報です。トラブル時は両方を記録し、「最新版をインストールした」とだけ伝えないようにしましょう。
- クライアントの「バージョン情報」またはコア情報の画面で、クライアント名、バージョン、コア名を確認します。
- サブスクリプションの提供元がClashまたはmihomo形式に対応しているか、特に必要なノードのプロトコルを確認します。
- まずルールモードとシステムプロキシを使ってブラウザーの接続を確認し、その後にTUNを有効にするか判断します。
02 · サブスクリプションURLはどこで入手する?共有しても大丈夫?
サブスクリプションURLは通常、ノードサービスのアカウントページから取得します。自分でサービスを運用している場合は、そこから発行することもできます。クライアントがリモートノードを自動で提供するわけではありません。取得時はClashまたはmihomo形式を選び、サービスのログインURLや購入ページ、ブラウザーのアドレス欄に表示されたアカウントページをコピーしないでください。
サブスクリプションURLには、アカウントを識別するトークンが含まれていることがよくあります。URLを知っている人は、ノード情報を取得したり、通信量を消費したり、レスポンスに含まれるアカウント関連情報を閲覧したりする可能性があります。認証情報として扱い、公開チケット、スクリーンショット、チャットグループ、コードリポジトリに載せないでください。
- 読み込む前にドメインが提供元のアカウントページと一致するか確認し、正式に案内されたHTTPSのURLを使用します。
- 問い合わせ時はユーザー名だけでなく、クエリパラメーター全体と機密情報を含むパスを隠してください。
- 漏えいした場合は、提供元のアカウントページでサブスクリプションURLを再発行し、クライアントに保存したURLも差し替えます。
- オンラインのサブスクリプション変換サービスを使うと、元のURLをそのサービスに送信することになります。利用前に、どこまで信頼できるか検討してください。
この記事では、公開ノードやサブスクリプションURLを提供していません。自分で環境を構築している場合は、YAML設定を管理できます。ss://またはvmess://のリンクしかない場合は、クライアントが単一ノードの読み込みに対応しているか確認してください。そのリンクを完全なClash設定としてそのまま使うことはできません。
03 · Clashのサブスクリプションを読み込むには?失敗したらどこを確認する?
クライアントによってメニュー名は異なります。一般的には、「サブスクリプション」または「設定」画面でリモート設定を追加し、URLを貼り付けてダウンロードします。その後、設定を選択して現在の設定として有効にします。設定カードが表示されても、有効になったとは限りません。現在の設定を示す表示とコアのログを確認しましょう。
応答内容からエラーを特定する
| 症状 | まず確認する項目 | 次の手順 |
|---|---|---|
| HTTP 401または403 | トークン、アカウント権限、アクセス元の制限 | アカウントページからサブスクリプションURLをコピーし直す |
| HTTP 404 | パスが完全か、古いURLが無効になっていないか | 提供元が現在案内しているURLと照合する |
| HTMLページが返される | ログインページをコピーしていないか、Web認証が表示されていないか | サブスクリプション専用のエクスポートページを使う |
| YAMLの解析に失敗 | インデント、内容の形式、項目の構造 | エラー行番号を控え、応答がYAML形式か確認する |
| 未対応のプロキシタイプ | コアの対応機能とサブスクリプションのプロトコル | mihomoの対応状況を確認するか、互換性のある設定に切り替える |
完全な設定には通常、proxies、proxy-groups、rulesが含まれます。proxy-providersを使ってノードを読み込む場合もあります。Base64でエンコードされたノード一覧だけのサブスクリプションは、YAML設定としてそのまま読み込めるとは限りません。拡張子を変えても形式の不一致は解決しません。
ログに接続タイムアウトが記録されている場合は、まずPCの時刻が正しいか、ネットワークからサブスクリプションのドメインに接続できるか確認します。プロキシ経由でサブスクリプションを更新するには、すでに利用可能なプロキシ経路が必要です。空の設定からその経路を作ることはできません。
04 · ルールモード・グローバルモード・直結モードの違いは?
プロキシモードは、コアに届いた接続の出口を選択します。すべてのアプリの通信を自動的にコアへ送る機能ではありません。グローバルモードに切り替えても、システムプロキシを無視し、TUNでも制御されていないアプリは、クライアントを完全に迂回する可能性があります。
- ルールモード:
rulesを上から順に照合し、該当したルールのポリシーに接続を渡します。通常はこのモードから使い始めるとよいでしょう。 - グローバルモード:接続をグローバルポリシーに渡します。グローバルポリシー内で、実際に使うノードまたはグループを選ぶ必要があります。振り分けの問題を一時的に切り分ける際に便利です。
- 直結モード:接続は直接の出口を使います。クライアントやシステムプロキシが無効になるわけではありません。
最小限のルール例
mode: rule
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,PROXY
これはルールの例であり、そのまま読み込める完全な設定ではありません。PROXY は、設定内に実在するノード名またはプロキシグループ名にする必要があります。DOMAIN-SUFFIX,example.com,DIRECT は、そのドメインとサブドメインに一致します。MATCH は最後のフォールバックルールです。MATCH を先頭に置くと、後続のルールは評価されません。
特定のWebサイトを調べる場合は、いったんグローバルモードに切り替えて同じノードを選びます。グローバルモードでは接続できるのにルールモードではできない場合は、適用されたルールとポリシーを重点的に確認しましょう。すぐにノードの障害と決めつけないでください。
05 · ノードの選び方は?レイテンシが最小なら最適?
クライアントに表示されるレイテンシは、指定されたテストURLへの応答時間であることがほとんどです。テスト先、タイムアウト時間、ネットワークの混雑状況、コアの測定方法によって結果は変わります。すべてのWebサイトでの表示速度や動画のダウンロード速度を示すものではありません。レイテンシの測定成功が示すのは、そのテストが完了したということだけです。
- テストボタンを押すだけでなく、現在使用中のポリシーグループでノードを選択します。
- 実際の接続先にアクセスし、接続時間、ページのリソースがすべて読み込まれるか、エラーが続かないかを確認します。
- 条件の違いを抑えるため、同じネットワーク、同じテストURLで候補のノードを比較します。
- 接続ログで最終的な出口を確認し、通信が別のポリシーグループに振り分けられていないか調べます。
selectグループはユーザーが手動で選択します。url-testグループは測定結果に基づいて自動選択します。fallbackグループは、優先順に利用可能な出口を選ぶ方式です。グループ内に別のグループを指定できるため、表示されているグループ名が最終ノードの名前とは限りません。
たとえば、手動選択グループで「自動選択」グループを選んだ場合、実際の出口は測定結果によって変わることがあります。問題を安定して再現したい場合は、特定のノードを一時的に選び、テスト時刻、対象ドメイン、エラー内容を記録します。ノード、DNS、ルールを同時に変更すると、どの変更が影響したのか判断しにくくなります。
06 · システムプロキシを有効にしたのに、ブラウザーが使えないのはなぜ?
システムプロキシは、この仕組みに対応したアプリにローカルのプロキシアドレスを通知するもので、通信を強制的に取り込む機能ではありません。まずクライアントが実際に待ち受けているポートを確認し、次にOS側に設定されたアドレスと一致しているか調べます。以下では確認例として127.0.0.1:7890を使います。実際の値は使用中のクライアントに合わせてください。
Windowsでの確認手順
- 「設定」→「ネットワークとインターネット」→「プロキシ」を開き、クライアントが管理するプロキシのアドレスとポートを確認します。
- クライアントの設定でHTTPまたはmixedの待ち受けポートを確認します。コントロールインターフェースのポートを誤って使わないようにしてください。
- ほかのプロキシツールを一時停止し、複数のプログラムがシステムプロキシ設定を繰り返し変更しないようにします。
- ブラウザー拡張機能が独自にプロキシを指定していないか確認します。必要に応じて該当する拡張機能を無効にしてから再試行します。
Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
curl.exe -I --proxy http://127.0.0.1:7890 https://example.com/
1つ目のコマンドはPowerShellでローカルポートに接続できるか確認します。TcpTestSucceeded : Trueは、待ち受けポートに接続できることを示すだけです。2つ目はHTTPプロキシを明示して、アプリがシステムプロキシ設定を参照しているかどうかを切り分けます。HTTP応答が返れば、そのリクエストに対する応答は得られています。ステータスコードが想定どおりかどうかは、対象サイトに応じて判断してください。
プロキシを明示したリクエストは成功するのにブラウザーで失敗する場合は、ブラウザーの設定、拡張機能、セキュアDNSを確認します。明示したプロキシでも失敗する場合は、ローカルポート、ノード、認証情報、ログを確認してください。コントロールインターフェースはクライアントとコアの通信に使われることが多く、ポートが開いているからといってブラウザーのプロキシ欄に設定してはいけません。
07 · TUNモードとは?初心者も有効にする必要がある?
TUNは仮想ネットワークインターフェースとルーティング設定を使ってIP通信を取り込み、システムプロキシに従わないアプリにも対応します。システムプロキシとは別の通信経路であり、「より上位のプロキシモード」ではありません。コアに入った後の出口は、引き続きルール、グローバル、直結の各モードで決まります。
まずシステムプロキシで基本動作を確認すると、トラブル時に調べる項目を絞れます。ブラウザーが正常に動作し、システムプロキシを使わないアプリだけが問題になる場合は、TUNの利用を検討してください。有効にする前に、管理者権限、サービスモード、追加のネットワーク権限が必要か確認します。必要な条件はOSとクライアントの実装によって異なります。
- Windows:クライアントが要求するサービスや権限が利用可能か確認し、仮想ネットワークアダプターやルートの作成に失敗していないかログを調べます。
- Android:通常はシステムのVPN権限を使って通信を取り込みます。別のVPNアプリを有効にすると、現在の接続が置き換わることがあります。
- 複数のVPNを使うデスクトップ環境:企業VPN、仮想マシンのネットワーク、ほかのトンネルがルートの優先順位を変えることがあります。ひとつずつ切り分けてください。
「TUNを有効にすれば、すべてのUDP、IPv6、DNSが必ず想定どおり処理される」と考えないでください。コアの機能、ノードが対応する通信方式、ルートの適用範囲、DNSの取り込み方も確認が必要です。初めて有効にした後は、ブラウザーと、これまでプロキシを使えなかったアプリをそれぞれテストしましょう。
08 · fake-ipとDNSは同時に変更すべき?
DNSはドメイン名をIPアドレスに変換します。mihomoのfake-ipモードでは、対象の問い合わせに対応付け用の仮想アドレスを返し、コアが元のドメインを復元して接続を処理します。仮想アドレスが表示されても、必ずしも名前解決の失敗ではありません。通信が引き続きコアに正しく取り込まれているかが重要です。
初心者は、利用できているサブスクリプションとクライアントの初期DNS設定をまず維持し、OS、ブラウザー、クライアントの3か所を同時に変更しないようにしましょう。ブラウザーの暗号化DNSを有効にすると、問い合わせ経路が変わる場合があります。TUNのdns-hijackも、あらゆる暗号化DNSリクエストを汎用的に遮断する機能ではありません。
まず状況を記録し、その後で設定項目を変更する
- ドメイン1つだけで失敗する:適用されたルール、サイトの状態、DNSログを確認します。
- 複数のドメインで名前解決できない:DNSの上流サーバーに接続できるか、問い合わせが想定した経路に入っているか確認します。
- LAN内のデバイス名や特定のアプリで問題が起きる:DNS機能全体を無効にするのではなく、必要なfake-ip除外設定を正しく指定しているか確認します。
- TUNの有効・無効で動作が変わる:ノードを変えるだけでなく、両方の状態でルートとDNSの取り込み方を比較します。
OSのnslookupの結果で分かるのは、そのコマンドが使用した問い合わせ経路だけです。ブラウザーやすべてのアプリが同じDNSを使っている証明にはなりません。各項目の詳しい説明は、設定リファレンスのDNSおよびTUNの項目を参照してください。
09 · 自動起動を設定するには?再起動後にプロキシが使えないのはなぜ?
自動起動、コアの起動、システムプロキシの復元、TUNの権限は、それぞれ別の機能です。スタートアップ設定で保証されるのは、プログラムの起動が試みられることだけです。設定の有効性、ネットワークへの接続、ポリシーグループの選択までは保証されません。デスクトップ版GUIクライアントは通常、ユーザーのログイン後に起動するため、ログイン前からプロキシ接続を使えるとは限りません。
再起動後の確認リスト
- クライアントの設定で「スタートアップ時に起動」などの項目を有効にします。
- Windowsでは、「設定」→「アプリ」→「スタートアップ」で、該当アプリがシステムによって無効にされていないか確認します。
- 再度ログインしたら、ウィンドウが表示されたかだけでなく、通知領域のアイコン、現在の設定、コアのログも確認します。
- システムプロキシが復元されているか確認します。TUNを使う場合は、サービスの状態と権限も別途確認してください。
- ネットワーク接続が確立してから、対象へのリクエストをもう一度テストします。起動直後はネットワークの準備ができていない場合があります。
クライアントによっては、「ウィンドウを閉じる」と通知領域に最小化され、別の設定ではプログラムが終了します。自動起動を確認する際は、最小化、終了、コアの停止を区別してください。クライアントが終了しているのにシステムプロキシが127.0.0.1を指していると、ローカルポートで待ち受けるプロセスがなくなり、システムプロキシに対応したアプリが接続できなくなることがあります。
その場合はクライアントを再起動するか、システム設定で手動プロキシを無効にします。スタートアップタスクやサービスを複数手動で作成しないでください。重複して起動するとポートが競合し、正常な設定を読み込めなくなる可能性があります。
サブスクリプションの更新で設定は上書きされる?トラブル時に伝える情報は?
リモートサブスクリプションを更新すると、通常はそのリモート設定の内容が置き換わります。ダウンロードしたYAMLを直接編集すると、次の更新時に変更が失われる可能性があります。クライアントの上書き、マージ、スクリプト機能を使えば個人設定とサブスクリプションを分けられますが、マージの順序や対応機能は実装によって異なります。
ルールを追加する場合は、上書きによってrules配列全体が置き換わるのか、先頭または末尾に追加されるのかを確認します。ポリシーグループを指定する場合は、更新後もグループ名が存在するか確認してください。グループ名が変わると、古い名前を参照するルールが原因で設定の読み込みに失敗することがあります。
役立つトラブル記録
- 環境:OSとバージョン、クライアント名とバージョン、コア名とバージョン。
- 接続経路:システムプロキシまたはTUN、実際のローカルポート、ほかのVPNを同時に起動しているか。
- ポリシー:ルールモードまたはグローバルモード、適用されたルール、最終的なポリシーグループとノード名。
- 症状:発生時刻、対象ドメイン、HTTPステータスコードまたはエラーの原文、安定して再現できるか。
- 比較結果:プロキシを無効にした場合、プロキシを明示した場合、動作確認済みの別ノードに切り替えた場合の違い。
ログを共有する前に、サブスクリプションURL、トークン、ノードのパスワード、コントロールインターフェースのキーを削除してください。通常必要なのは、問題の前後に関係するログだけです。設定全体をアップロードする必要はありません。複数の項目を変更した場合は、まず動作していたバックアップに戻し、一度に1項目だけ変更して再テストします。