モバイルで詰まりやすい三点：購読・TUN・DNS
Android 向けの Clash ファミリー（代表例：Clash for Android／Meta 対応フォーク群）は、同じ構成ファイルでも権限許可や省電池最適化、端末機能の競合ひとつで挙動が変わります。 とくに屋外回線でも再現したいときは、「購読の同期」「仮想インタフェースでのキャプチャ」「名前解決の経路」をまとめて設計しないと、アプリ画面上はオンなのに一部アプリだけ直結していたり、上流DNSだけ別ドアに逃げてしまったりというパターンに遭遇しがちです。
記事前半では UI 側の名前に依存しない概念整理を置きました。 メーカーにより「VPN」「ネットワーク拡張」「常時許可」の位置が異なりますが、考え方は共通で、公式ビルドの入手確認と権限セットを先に済ませ、つぎに購読を取って最後に DNS とルートの整合を読む順番が読み間違いにくいです。
構成の一例として tun.enable や Dns 関連のフラグがありますが、この記事では特定の開発版番号への固定ではなく、その時点の機能トグルと YAML の対応関係に焦点を絞って説明しています。
サービス運用側の許諾がある購読URLだけで試し、開発者向けの検証環境にもそのまま持ち込める書きぶりです。
環境準備と入手元・ABI の確認
署名の異なる複数ビルドが流通しているとき、OS の「ソース不明アプリ」を許す以外にも、Chrome 側の許可リストやワークプロファイルでの制限があるとサイドロードだけで止まることがあります。 arm64-v8a／従世代向け ABIの取り違えにも注意し、アーキ不一致のときはサイレントクラッシュだけが残って原因が読みにくいです。
端末の時刻が自動同期から外れると証明書の検証だけでタイムエラーになり、購読の HTTPS フェッチにも届きません。 開発者によるデバイス監査機能は必要に応じてオフへ戻してください。 競合となる VPN が常駐していたり、複数ユーザーで端末共有しているときは、アクティブなプロファイル側で別の強制経路が生きているかも頭に置きます。
サブスクリプション：取込・更新エラーへの切り分け
購読の典型的な流れは、URL と表示名を与え、アプリ側でフェッチさせ、返ってきた一覧からプロファイルを選ぶ、という三手順です。 問題はここだけで済むこともありますが、エラーになると画面は短い英語だったり抽象的なログだったりすることが多く、体感ではひとつの「timeout」と捉えられがちです。
まず確認したい順番は、(1) 端末単体ブラウザで同じHTTPSがタイムスタンプ誤りなしで開けるか、(2) 端末側の広告フィルタやローカルブロッカーがドメインを落としていないか、(3) アプリのみでしかプロキシを貼っておらず、更新自体にも影響が出ていないか、です。
ログに MIME やサイズ異常がある場合は、アクセス制御側でリストがページ化されただけのケースや、CDN のリダイレクトが端末機能で挟まれたパターンを疑ってください。
頻繁に更新する構成なら自動更新までいかず手動だけでもよい設計にしておき、失敗時は通知で気づけるようアプリの通知権限を残しておくと運用が楽です。 自動更新だけに頼るとサイレント劣化しか残らなくなり、「昨日まで動いたのに」の原因がログから消えることがあります。
プロファイルの選択と競合状態の読み替え
リストに並んでいるうちの複数構成を順に試すほど、アクティブな実体だけが頭に残りにくくなります。 メインで使いたい名前をひとつに限定し、アプリ画面上のチェック状態とタイトルを揃える習慣が安全です。
ルートの並び順とプロキシグループ名は GUI の日本語タグとは微妙に異なることがあり、Rule 評価の末尾にだけ MATCH が張られているときに想定どおりではないグループへ落ちやすくなります。
画面上の自動選択グループが指している名前と、構成ファイル側の名前が完全一致しているかを一度だけでも見に行くことで、このあとの TUN と DNS が噛み合いやすくなります。
TUN モード（VPN 表示）を安定させる
Android 側ではユーザーに見える表現として「VPN 接続」のトグルになりますが、アプリ側の実装詳細としてはレイヤキャプチャの強さが増すイメージで捉えると読み間違いにくいです。 アプリのみがプロキシを見ればよい時代に比べれば重くなりがちですが、ゲーム・リッチクライアント・ワークスペース統合チャットまで含めるなら、ここまで踏み込んだほうが一貫しやすい場面があります。
オンにすると端末側の状態バーや設定画面に別アイコンが出るだけで済むこともありますが、まれに許可リストを忘れていたり競合サービス側で「常時オンVPN」を要求されていて競合することがあります。 競合していた場合は両方オンにしない、もしくは片方のみを「常駐しない」側にします。 ワークプロファイル入り機では管理者ポリシーが先にあるため、画面上の機能がロックされているだけのケースにも注意してください。
tun:
enable: true
stack: gvisor
上記は構成例で、環境により推奨の stack 系の値や追加パラメタが変わります。
メーカー側の電池最適化が強いモデルほど、アプリ許可リストに入れずに開始するとサービス側が二度と復帰しないことがあるため、セットアップ手順だけは端末モデル共通に書ける範囲を超えると覚えておくと安全です。
DNS セクションと「見えない」ホスト名解決経路
名前解決をアプリ側で握れるかどうかは、上流の指定と強化モード（例：fake-ip）の組み合わせに強く依存します。
体感で「サイトは開けるのにRuleが効いてない」のに見えるとき、よく読み間違いになるのがここです。
画面上はグローバルにオンでも、クエリ処理だけ上流が端末機能へ抜けると、評価のタイミングと実接続側の経路だけが別語で説明されていて混乱します。
一般的なテンプレは nameserver と fallback の二段に分ける書きぶりになりがちです。
上流がフィルタ寄りになりすぎると名前自体が別名へ誘導され、広告ブロック済みリストと二重になります。
逆に速すぎるだけで信頼根が薄い上流へだけ寄せると、短期間だけ別リージョンのキャッシュだけが効いて挙動がブレやすくなります。
dns:
enable: true
ipv6: true
enhanced-mode: fake-ip
nameserver:
- tls://dns.example.com
- https://1.1.1.1/dns-query
fallback:
- tls://fallback.example.net
構成例のFQDNへは適宜読み替えてください。ipv6 をオンにするとデュアルスタック側のクエリ処理も増えますが、この場合は前述のIpv6側ルートも合わせて見ないと結果だけ読んでも読み間違います。
Private DNS が端末機能でオンなら、アプリ上流と二つの意思決定になり得るので、検証環境だけでも一度オフ側へ寄せて比較ログを並べてみると切り分けが早くなります。
確認のしかたと典型的な読み間違い
オンライン診断の文言はサイトごとに表現が違うため、その場のスナップだけで恒久判断しないことが重要です。 クエリ側と出口側を別ウィンドウで見せるサイトもありますから、両方のアラートを同じ時刻のアクティブプロファイルとして読んでください。
体感で「ひとつの警告だからリーク」の短絡だけは避け、Ruleのどの行へ当てた結果かログで一度確かめると運用側の判断力が安定します。 開発者機能の多言語環境だけで警告文言が増えるモデルがあるため、評価条件は端末機能とセットで読んでください。
IPv6 と分割トラフィックのすれ違い
アプリ側がIpv4のみをレイヤ側で整えていたとしても、ワイヤレススタック側でIpv6のみ早い経路が残っていると、体感では「サイトによってだけ速い」のように見えることがあります。 アクセス先がAAAAレコードのみを返すときに顕著です。 構成側で両系統を許容する設定があればオンにしますが、その場合でも出口が二系統だけ読み続けると疲弊するので、長期運用では一度だけ安定ルートを決め切るのがおすすめです。
トラブル早見表
よくある症状と、まず触るトグルを短くまとめました。
| 症状 | 最初に疑うもの | 試す順番 |
|---|---|---|
| 購読更新だけ失敗する | 時刻ずれ／TLS／ブロックリスト | 外部ブラウザでURL到達確認→許可リスト再確認 |
| TUNオンだがブラウザ外だけ迂回 | 許可リストと省電池最適化 | 常駐許可→バッテリー例外→再試行 |
| 画面はRuleなのに挙動がGlobalのよう | アクティブプロファイル／MATCH行 | 実際の名前と自動選択グループ整合 |
| DNSテストだけ別出口 | Private DNS と fake-ip上流 | 端末機能を一回オフ側へ→ログ比較 |
よくある質問
質問項目はページ先頭の構造化データと対応しています。
購読URLを追加したら「timeout」または空のリストになります
端末側の許可済みネットワーク、プロバイダURLの期限、TLS差し替え証明書、DNSの参照失敗などを疑います。 外部ブラウザで同じURLへ到達できるか、時間を自動に合わせたか、アプリ側のプロキシのみで更新していないかを確認してください。
TUN をオンにしてもゲームだけ直結しているように見えます
省電池最適化でバックグラウンドが止まっていたり、アプリ側の許可リストで除外されていないか、別の競合キャプチャが先に張られていないかを見ます。 デュアルSIMや分割データ通信と相性が悪い事例もあり、ルール評価は動いているのに特定UDPだけ迂回する場合はログで切り分けます。
Private DNS と Clash の DNS はどちらが優先ですか
端末機能はOS全体への既定を変え、アプリ側の設定はキャプチャ内のクエリ処理を担当します。 意図が二重になりやすいので、運用単位ではどちらかを主として揃えるのが安全です。
fake-ip をオンにすべきですか
ルールがホスト名中心で並んでいるテンプレと相性が良い構成ですが、上流 DNS の並びや例外ルールとの整合が必要です。 体感で問題が起きたらログを読み、アップストリームを購読元の例に寄せつつ試します。
IPv6 だけ意図しない経路になります
デュアルスタック環境では、IPv4のみを管轄している一方でIPv6 はISP直のままになることがあります。 ルール側の説明だけでなく、端末側の無線設定やAPNのIpv6フラグ、アプリ側の対応可否をセットで確認するのが早いです。
Clash Meta for Android と従来表示の CFA はどちらを選ぶべきですか
利用する構成ファイルの機能集合と、必要な転送プロトコルによります。 Mihomo 互換機能を広く試すならMeta系、アプリ側の成熟度や端末適合だけを優先するなら従来表示のcfa派生を選ぶ、という粒度で比較するのが実務的です。
まとめ：モバイル前提の「見える設計」に寄せる
Android では画面の奥に省電池と端末機能の優先度が隠れているため、PC版と同じYAMLを写しただけでは再現性が出にくいです。 購読取得の信頼性、TUNでどこまで握るか、DNSをいくつの意思決定に分けるかを三要素として一度設計図に落とすと、あとからの切り分けが速くなります。
単体の「常駐だけで完結する軽量ラッパー」は手軽さは魅力ですが、ルールと名前解決と実際の出口を同じ画面で追いづらい製品もあります。 更新が止まった派生アプリに固定すると、OSのバージョンアップのたびに証明書やVPN権限の挙動差だけで時間を溶かすことになります。
Clash／Mihomo は購読とルール評価、プロキシグループ、キャプチャ方式、DNS上流をひとつの設定空間へ載せられるため、アプリ画面上で状態が読めるクライアントを選ぶと復旧までの試行錯誤コストが下がります。 構成をまとめるなら購読取込だけで済まず、ログでRule行と上流DNSをセットで読む運用まで含めて揃える価値があります。 アプリ一式を公式経路へ寄せておけば、アーキ変更や機能追加にも振られにくいです。 インストーラと署名付きパッケージを揃えるには当サイトの 公式ダウンロード一覧 が参照しやすいです。 競合機能と二重にしない構成へ寄せられたら、体感の安定だけでなく証明書判断の読み間違いも少なくなるはずです。