Clashのよくある質問
設定・接続のトラブル対処

クライアントはサブスクリプション管理、プロキシグループの選択、システムプロキシの切り替えを担当します。mihomoコアはポートの待ち受け、DNSの解決、ルールに基づく通信の振り分けを担当します。LinuxデスクトップではClash Verge Revを、サーバーではコアを直接実行する方法から始められます。設定の保存先は両者で異なる場合があり、GUIクライアントが実行用設定を生成することもあります。トラブル対処の前に、実際に起動しているバイナリと設定ディレクトリを確認し、使われていない別の config.yaml を編集しないようにしてください。コマンドラインで導入した場合、通常は ~/.config/mihomo/ を使用しますが、最終的には起動引数の -d または -f で指定されたパスを確認してください。

普段はルールモード（mode: rule）を選び、リクエストに適用されたルールとプロキシグループを確認します。グローバルモードでは通常の接続を GLOBAL グループに渡しますが、グループ内で DIRECT が選ばれる場合もあります。また、コアを経由していないアプリの通信まで自動的に制御するわけではありません。DIRECTモードは、コアに入った接続を宛先へ直接送るため、比較テストに適しています。モードを切り替えたら新しい接続で試してください。既存の長時間接続は、切り替え前の経路を使い続けることがあります。アプリの動作が変わらない場合は、まずシステムプロキシを使っているか、TUNで通信を取り込めているかを確認してから、モード設定を見直しましょう。

クライアントとコアは接続や通信の振り分けを行いますが、利用可能なリモートプロキシが最初から含まれているわけではありません。サブスクリプションには通常、ノードやプロキシグループ、ルールが含まれますが、ノード一覧だけの場合もあります。インポート前に、サービス提供元の形式がClashまたはmihomoに対応していることを確認してください。ノードだけを含むProviderファイルは、完全な設定の代わりにはなりません。インポート後は設定を有効にし、プロキシグループで利用可能な出口を選び、サービスの有効期限と通信量も確認してください。サブスクリプションURLには認証情報が含まれることが多いため、公開ログやスクリーンショット、オンライン変換サービスに貼り付けないでください。

同時に有効にする必要はありません。システムプロキシはデスクトップのプロキシ設定に従うブラウザーやアプリに適しています。一方、TUNは仮想ネットワークデバイスとルーティングを使って、より多くの接続を取り込みます。初めて設定する場合は、まずTUNを無効にして明示的なプロキシでノードとポートを確認し、その後TUNを個別にテストすると、設定の問題とシステム権限の問題を切り分けやすくなります。両方を有効にする場合は、経路の除外設定とDNS設定も確認し、二重に通信を取り込んだりループが発生したりしないようにしてください。TUNを有効にしても、すべての通信が必ずプロキシ経由になるわけではありません。最終的な出口はルール、プロキシグループ、バイパス設定によって変わります。

インポートした設定が現在の使用対象になっているか確認してください。設定一覧に保存されているだけでは利用されません。次にサブスクリプションの更新ログを確認し、取得した内容がログインページやエラーページ、空ファイルではないかを調べます。設定で proxy-providers を使っている場合、メイン設定の読み込みが成功してもノード一覧の取得に成功したとは限りません。該当Providerの状態、パス、リモートサーバーの応答も確認してください。コマンドライン環境では mihomo -t -d ~/.config/mihomo で設定を検証し、実行ログにダウンロードエラーがないか確認します。認証情報を含むサブスクリプションURLを公開の質問掲示板に投稿しないでください。

401は認証情報がない、または無効になっている可能性があります。サービス提供元からURLを再取得してください。403はアクセス制限、リクエストヘッダー、利用量制限などが原因の場合もあるため、レスポンス本文も確認します。タイムアウトの場合は、サブスクリプションURLにネットワークからアクセスできるかを確認してください。必要に応じて、取得に使うプロキシが、まだ読み込まれていないノードに依存していないかも調べます。証明書エラーが出たら、まず timedatectl でシステム時刻を確認し、次にディストリビューションのCA証明書を確認してください。証明書検証を無効にして、エラーを恒久的に回避する方法は避けましょう。URLを更新した場合は古いものを置き換えて手動更新し、HTTPステータスとログの詳細を確認してください。

まず ls -l /dev/net/tun を実行し、デバイスが存在するか確認します。見つからない場合はtunモジュールを確認し、必要なら sudo modprobe tun を実行してください。次に、実行中のコアに仮想ネットワークインターフェースの作成とルート変更の権限があるか確認します。可能であれば、GUIクライアントが提供するサービスのインストール方法を利用してください。直接導入する場合、一部の環境では sudo setcap cap_net_admin,cap_net_bind_service=+ep /usr/local/bin/mihomo で権限を付与できますが、実際のバイナリパスに合わせる必要があります。バイナリを更新した後は、権限の再設定が必要になる場合があります。コンテナではデバイスとネットワーク権限の許可も必要です。systemdのCapability制限によって、権限付与が反映されないこともあります。

まず systemctl --user cat mihomo を実行して ExecStart を確認し、バイナリと設定ディレクトリが存在することを確かめます。サービスには明示的なパスを指定し、設定ディレクトリには %h/.config/mihomo を使用できます。シェルによる ~ の展開や、対話型端末の環境変数に依存しないようにしてください。次に mihomo -t -d ~/.config/mihomo で同じディレクトリの設定を検証し、journalctl --user -u mihomo -b -n 80 --no-pager で終了理由を確認します。サービスファイルを変更したら systemctl --user daemon-reload を実行してからサービスを再起動してください。ユーザーサービスとシステムサービスのコマンドを混同しないようにしましょう。

デスクトップのシステムプロキシは、すべての通信を一括して取り込む仕組みではありません。環境変数だけを参照するコマンドラインプログラムもあれば、独自のプロキシ設定を使うアプリもあります。まず curl -I -x http://127.0.0.1:7890 https://example.com で明示的なプロキシ接続を確認し、各プログラムのドキュメントに従って http_proxy、https_proxy、または ALL_PROXY を設定してください。環境変数の大文字・小文字の扱いはプログラムによって異なります。また、NO_PROXY によって対象がプロキシを迂回する場合もあります。プロキシ設定に対応していないプログラムの通信を取り込みたい場合は、明示的なプロキシ接続を確認した後でTUNを検討してください。デスクトップのスイッチだけを見て、端末もプロキシ経由になっていると判断しないでください。

まず、通常のデスクトップブラウザーが同じポートに接続できることを確認し、アプリコンテナーのループバック制限かどうかを切り分けます。一部のUWPアプリでは、127.0.0.1 上のプロキシに接続するためにループバックの除外設定が必要です。クライアントにUWPループバック設定がある場合は、それを使い、必要なアプリだけを選択してください。管理者の端末で CheckNetIsolation LoopbackExempt -s を実行すると、現在の除外リストを確認できます。手動で変更する場合は、正確なパッケージファミリー名を確認してください。必要なアプリだけに許可し、アプリをまとめて変更しないようにしましょう。TUNが有効な場合は、そのアプリの通信が実際にコアへ取り込まれているかも確認し、すべての問題をループバック制限のせいにしないでください。

待ち受けアドレス、allow-lan、ファイアウォールの3点を設定する必要があります。allow-lan: trueを有効にしたら、bind-addressがLAN内のアドレスを許可しているか確認し、ss -lntpで実際の待ち受け状態を確認します。他の端末には、このPCのLAN内IPアドレスとmixed-portを指定します。127.0.0.1は指定しません。ファイアウォールでは信頼できるネットワークに限ってプロキシポートを開放し、必要に応じてプロキシ認証を設定してください。external-controllerの管理インターフェースは、アクセス制御を明示的に設定していない限り、ローカルホストからのみ接続できるようにします。HTTPプロキシの共有と、PCを透過型ゲートウェイとして使う構成は別物です。プロキシポートを設定しただけでゲートウェイとして使えるわけではありません。

HTTPタイプの proxy-providers では interval で更新間隔を指定できます。単位は秒で、たとえば interval: 3600 なら1時間ごとに確認します。Providerごとに別のキャッシュパスを使い、実行ユーザーにディレクトリへの書き込み権限があることを確認してください。health-check.interval はノードのヘルスチェック間隔であり、サブスクリプションの更新間隔ではありません。短くしても新しいノードを早く取得できるわけではなく、リクエストや消費電力が増える可能性があります。GUIクライアントの設定更新スケジュールは、コアのProvider更新とは別に動作する場合があります。設定全体とノード一覧のどちらを更新するのか、まず確認しましょう。変更前に設定をバックアップし、ログで実際の取得結果を確認してください。

まずサブスクリプションが有効で、プロキシグループがリモートノードを選択していることを確認します。次にノードサーバーのアドレスを名前解決できるか、システム時刻が正確かを調べます。特定のノードだけ失敗し、他のノードが使える場合は、そのノードまたはテスト先を優先して確認してください。すべて失敗する場合は、ローカルネットワーク、防火壁、サブスクリプションの状態、コアのログを調べます。遅延テストで分かるのは指定されたテスト先への接続結果であり、すべてのWebサイトにアクセスできないことを示すものではありません。明示的なプロキシ経由で実際に利用したいHTTPSサイトへ接続し、どの段階でエラーになるか記録すると切り分けに役立ちます。DNS、ポート、モードを一度に変更せず、毎回1項目ずつ変更して、どの対処で復旧したか確認してください。

まず mixed-port が待ち受けているか確認し、明示的なHTTPプロキシ経由の結果とブラウザーの結果を比較します。curl -I -x http://127.0.0.1:7890 https://example.com を実行してください。リクエストが成功してブラウザーだけ失敗する場合は、ブラウザーのプロキシ設定、拡張機能、セキュアDNSを重点的に確認します。ログに名前解決エラーがある場合は、dns.enable、上流DNSへの接続、TUNによるDNSの取り込みを確認してください。fake-ip モードでマッピングされたアドレスが返るのは通常の動作です。アドレスだけで障害と判断しないでください。アプリに古い名前解決結果がキャッシュされている場合は、アプリを再起動して接続し直します。必要に応じて、システムとブラウザーそれぞれのキャッシュも確認してください。

ss -lntp を実行してTCPの待ち受けポートを確認し、特に mixed-port と external-controller に設定したポートを調べます。他のユーザーのプロセスを確認する場合はsudoを使ってください。GUIクライアントと手動起動したコアが同時に動いている場合や、ユーザーサービスとシステムサービスが重複して起動している場合によく発生します。まずプロセスの起動元を特定し、不要なインスタンスだけを停止してください。同じ名前のプロセスをすべて終了するのは避けましょう。競合しているポートを変更する方法もありますが、その場合はシステムプロキシ、環境変数、管理画面の接続先も合わせて変更する必要があります。UDPの待ち受けに関するエラーなら ss -lnup も確認し、TCPだけを調べてポートが空いていると誤認しないようにしてください。

まず systemctl --user is-enabled mihomo と systemctl --user status mihomo を実行し、サービスが有効になっていないのか、起動に失敗しているのかを確認します。ログイン後にユーザーマネージャーとともに起動するには、systemctl --user enable --now mihomo を実行します。ログアウト後もユーザーサービスを実行し続けるかどうかはlingerの設定にも左右されます。loginctl show-user "$USER" -p Linger で状態を確認してください。ログインしていない間も実行し続ける必要がある場合は、loginctl enable-linger の影響を確認したうえで設定します。TUNに追加権限が必要な場合は、アップデート後に権限が失われていないか個別に調べてください。最後に、デスクトップのプロキシ設定や端末の環境変数が、サービスの状態だけでなく、実際に待ち受けているポートを指していることを確認します。