FlClashのよくある質問

Clashは通常、プロキシのコアとその設定エコシステムを指し、同種のクライアント全般を表す言葉として使われることもあります。mihomoはClash Metaから発展したコアプロジェクトで、プロトコル接続、ルール照合、DNS処理を担います。FlClashは設定の管理、プロキシポリシーの選択、ネットワークの制御方法の調整に使うグラフィカルインターフェースを提供します。画面上で利用できる機能は実際のコアのバージョンによって異なります。項目が使えない場合は、ソフトウェア名だけを比較せず、クライアントの説明とコアの対応範囲をあわせて確認してください。

サブスクリプションURLは、利用中のサービスのアカウントページ、組織のネットワーク管理者、または自分で構築したサービスの管理画面から取得してください。このサイトではクライアントのダウンロードと設定方法を案内しており、Clashの無料ノードやサブスクリプションアカウントは提供していません。URLには認証情報が含まれることがあり、知った人が設定を読み取ったり、アカウントの通信量を消費したりするおそれがあります。スクリーンショットの公開、グループチャットへの転送、公開の変換サイトへの入力は避けてください。出所不明の無料設定には、追加のルールやDNS、外部リソースのURLが含まれる場合もあります。インポート前に提供元と用途を確認しましょう。

FlClashは主にWindows、macOS、Android、Linux向けに配布されています。iPhoneでは、iOS対応が明記されたクライアントを選んでください。このサイトのダウンロードページでは、iOS向けにClash Plusを案内しており、App Storeへのリンクと公式サイト clashplus.io を掲載しています。既存のサブスクリプションを引き続き使えるかどうかは、クライアントが対応するサブスクリプション形式とプロトコルによります。乗り換える前に、サービス提供元が対応形式を提供しているか確認し、インポート後にポリシーグループを確認してください。デスクトップ版のシステムプロキシやTUNの手順は、そのままiOSには適用できません。

サービス提供元がノードのURI一覧だけを提供し、クライアントが完全なClash設定を必要とする場合に、形式変換が必要になることがあります。まずは提供元のClashまたはmihomo専用サブスクリプションを利用してください。こうしたURLには通常、対応するポリシーグループやルールが含まれています。変換で整理できるのは対応済みの項目に限られ、コアが本来対応していないプロトコルを使えるようにはできません。第三者の変換サービスにサブスクリプションを送信すると、URLの内容を読み取られることになります。必要な場合は信頼できる自前のツールを使い、出力されたDNS、ルール、外部リソースを確認してください。

まずサブスクリプションURLをすべてコピーし、FlClashの設定ページで「設定を追加」またはインポートを選び、URLからインポートして保存します。ダウンロードが完了したら、作成した設定を選択し、プロキシページにポリシーグループが表示されることを確認してください。URLをリストに保存しただけでは、その設定に切り替わっていません。次にルールモードと利用可能な出力ポリシーを選び、OSに応じてシステムプロキシまたはTUNを有効にして、実際の接続をテストします。バージョンによってボタン名に多少の違いはありますが、インポート、設定の選択、ポリシーの選択、通信の制御という順序は同じです。

Windowsでは「設定」の「システム情報」でシステムの種類を確認できます。一般的なIntelまたはAMD搭載PCにはx64を選び、ARM端末では配布パッケージが対応しているか先に確認してください。macOSでは「このMacについて」でチップを確認し、Apple Silicon用とIntel用のパッケージを使い分けます。Androidでは端末のプロセッサとOSが対応するABIに合わせて選んでください。比較的新しいスマートフォンではarm64が一般的ですが、古い端末や特殊なOSでは個別の確認が必要です。インストール時の解析エラーは、ダウンロードの不完全さやOSのバージョン要件が原因の場合もあります。アーキテクチャを何度も変えるだけでは解決しないことがあります。

TUNは仮想ネットワークインターフェースの作成とルートの変更を伴うため、通常はシステムプロキシより高い権限が必要です。Windowsではクライアントの案内に従って必要なサービスをインストールまたは起動し、必要に応じて管理者として実行してください。macOSとLinuxでは、それぞれのOSに合った権限の許可やサービス設定を行い、他のOS向けのコマンドを流用しないでください。Androidで初めて有効にするときは、システムのVPN接続要求を許可します。別のVPNが動作中だと競合することがあります。権限を許可したら、関連サービスまたはクライアントを再起動し、ログに記録された具体的なエラーを確認してください。トラブル対処のためにすべてのセキュリティ機能を無効にするのは避けましょう。

まず、インストーラーが信頼できる配布元から入手したもので、チップのアーキテクチャとOSのバージョンに合っていることを確認してください。アプリを「アプリケーション」フォルダに移動してから、もう一度開いてみます。開発元の検証に関する警告が明示された場合は、使用中のmacOSのバージョンに応じて「システム設定」の「プライバシーとセキュリティ」に「このまま開く」などの選択肢があるか確認してください。アプリの破損、アーキテクチャの不一致、セキュリティ検証は別の問題です。表示されたメッセージ全体に基づいて個別に対処してください。出所不明のターミナルコマンドを実行したり、システムのセキュリティ機能を恒久的に無効にしたりしないでください。解決しない場合はOSのバージョンとエラーメッセージを記録して調べましょう。

ルールモードは、設定内のルール照合順に従ってリクエストのポリシーを選択するため、普段使いの基本として適しています。グローバルモードは、コアが制御しているリクエストをグローバルポリシーに渡します。短時間の比較テストに便利ですが、すべてのアプリの通信が自動的にコアを通るわけではありません。ダイレクトモードでは、制御対象のリクエストを直接接続させるため、問題がプロキシ経由の接続に関係するかを判断できます。モードを切り替えた後は、該当するポリシーグループでどのノードが選ばれているかも確認してください。既存の接続は元の経路を使い続けることがあります。テスト時は対象アプリの接続を切ってから再試行し、以前の接続を新しいモードの結果と取り違えないようにしましょう。

システムプロキシの影響を受けるのは、主にOSのプロキシ設定に従うアプリです。端末全体の通信を制御する機能ではありません。まず、ブラウザー拡張機能、アプリ内のプロキシ設定、他のクライアントがシステム設定を上書きしていないか確認し、FlClashが起動中で、待ち受けポートが設定と一致していることを確かめてください。コマンドラインツール、一部のゲーム、独自のネットワークスタックを使うソフトウェアは、システムプロキシを無視することがあります。必要に応じてアプリごとにプロキシを設定するか、TUNを使ってください。制御状況を確認するには、ウェブページが開けるかだけで判断せず、クライアントの接続履歴で対象プロセスとドメインを確認します。企業管理下の端末では、管理ポリシーによる制限も考えられます。

AppContainerで動作する一部のWindowsアプリはローカルループバックの制限を受け、クライアントが待ち受けるローカルプロキシポートに接続できないことがあります。通常のブラウザーでは動作するのに特定のストアアプリだけ失敗する場合は、まずそのアプリがローカルプロキシを使っているか確認し、必要ならループバックの除外設定を検討してください。クライアントにUWPループバックツールがある場合は、許可を得たうえで対象アプリだけを除外します。使用中のバージョンに該当機能がない場合は、MicrosoftのドキュメントでアプリのパッケージIDと手順を確認してください。ループバックの除外ではサブスクリプションやノードの問題は解決しません。すべてのアプリをまとめて許可することも推奨しません。

まず、ドメインの名前解決失敗と接続タイムアウトを区別してください。ログに名前解決エラーがあるか確認し、同じノードで他のドメインにアクセスできるか比較します。設定のDNSモード、リゾルバーのアドレス、DNSリクエストの送信経路を確認してください。特に、リゾルバー自体がプロキシを必要とし、まだ確立していないプロキシ接続に依存する構成は避けましょう。fake-ipを使っている場合、一部のアプリには個別のフィルタールールが必要なことがあります。変更は一度に一項目にとどめ、元の設定を残したまま対象への接続を作り直してください。DNSの一括変更、IPv6の無効化、ルート変更を同時に行うと、原因の特定が難しくなります。

まずローカルネットワークが正常か確認し、次にサブスクリプション提供元のアカウントページで、URLがリセットされていないか、契約が有効か、専用のサブスクリプションURLが必要かを確認してください。401は通常、認証に関係します。403はアクセス制限やサーバー側のポリシーが原因の場合がありますが、詳細は提供元の案内を確認してください。HTMLのログインページが返っても、有効な設定を取得できたとは限りません。自動更新の間隔で変わるのはリクエストを送るタイミングだけで、無効なURLは直りません。URLを変更したら手動で一度更新し、提供元に問い合わせるためステータスコードと時刻を記録してください。ログを共有する前に、サブスクリプションURL全体と認証情報を削除しましょう。

まずクライアントの通信制御を一時停止し、ローカルネットワークで通常のサイトにアクセスできることを確認します。次にサブスクリプションが有効か、使用する設定が選択されているかを確認してください。通信制御を再開したら、ポリシーグループの選択、システムプロキシまたはTUNの状態を確認し、同じテスト先で複数のノードを比較します。ノードテストのタイムアウトは、テスト先に到達できないことが原因の場合もあり、すべての通信が失敗しているとは限りません。実際のリクエストとログをあわせて判断してください。すべてのノードで問題がある場合は、ローカルDNS、ルート、他のVPNとの競合を優先して確認します。特定のノードだけ失敗する場合は、そのノードの状態を提供元に問い合わせ、複数の設定を同時に変更しないようにしましょう。

まずブラウザーに表示されたエラーの種類、対象ドメイン、証明書の発行者を記録し、システムの日付、時刻、タイムゾーンが正しいか確認してください。次に、直接接続とプロキシ経由を比較し、ログインが必要な公衆Wi-Fi、異常なDNS応答、セキュリティソフトのHTTPS検査、ノードの出口側の問題を切り分けます。通常のプロキシ転送で、ブラウザーに追加のルート証明書を信頼させる必要はありません。ページを開くために見知らぬ証明書を安易にインストールしたり、検証を無効にしたりしないでください。特定のサイトだけでエラーが出る場合は、サイト自体の証明書が期限切れの可能性もあります。信頼できる別のネットワークでも確認し、具体的なエラーに基づいて原因を調べましょう。

まず、使用中の設定がGEOIP、GEOSITE、または関連するルールセットを実際に参照していることを確認してください。更新したデータがそのルールに必要なものであり、名前が似た別のファイルではないことも確認します。ルールは上から順に照合され、先に一致するルールがあると、後続のルールは判定に使われません。データベースを更新しても、この順序は変わりません。GEOIPは対象のIPアドレスを基にし、GEOSITEはドメインの分類を基にするため、役割が異なります。更新後はクライアントの案内に従って設定を再読み込みし、新しい接続でルールの照合記録を確認してください。分類が想定と異なる場合は、何度も更新するのではなく、ルールの内容とデータベースの提供元を調べましょう。