1 話題の向きとネットワーク設計の向きは別物
SNS で RedNote/小紅書が話題になるとき、議論の中心はしばしばアプリの入手経路やコンテンツの見え方に寄ります。一方でローカルのプロキシ設定は、その話題とは独立に、「どのホストをどのアウトバウンドへ送るか」を決めるレイヤです。グローバルモードや粗い FINAL がすべてプロキシになっていると、国内の画像 CDN・認証 API・計測ドメインまで長い RTT のサーバへ迂回し、フィードの読み込みがモッサリしたり、携帯番号やワンタイムコードまわりで期待している経路とズレたレスポンスになったりします。
本稿が狙うのは規約違反の回避ではなく、利用規約と法令を踏まえたうえで、あなたのネットワーク環境において国内向けトラフィックはローカル ISP/直行経路へ残す構成です。海外ストリーミングや越境 EC にフォーカスした記事(例:越境ショッピングと Clash の記事)とはシナリオが逆向きになるので、購読ルールをコピーするときは目的が一致しているかを必ず確認してください。
GEOIP,CN と書いたり GEOIP,china と書いたり表記が分かれるので、手元の Mihomo バージョンのドキュメントと突き合わせてください。
2 プロキシが国内まで巻き込むときの典型的な症状
アプリが単体でネットワークスタックを持っている場合もありますが、PC でTUNやシステムプロキシを広く効かせているときは、次のような切り分けが役に立ちます。プロキシをオフにすると改善するが、オンだとカクつく場合は、ルールより経路の迂回が疑わしいです。逆にDNS だけが別系統になっていると、ブラウザでは正常でもネイティブアプリだけ名前解決がずれる、という組み合わせも起こります。
- 動画や画像の初回バッファが異様に長い: 国内 CDN を海外ノード経由で取りにいっている可能性があります。
- ログインや SMS コードが不安定: ワンタイムパスワードやリスク判定が出口 IP の地理位置を見ている場合、プロキシ出口が国外しか用意されていないと期待とズレます。
- HTTPS は張れるが体感だけ悪い: レイテンシや輻輳による体感劣化で、ルールログではエラーにならないことがあります。
これらはすべて断定診断ではなく、接続ログとタイムスタンプを見ながらの話です。アプリが特定ホストにのみバインドしているときは、OS のプロキシを無視する場合もあるため、TUN モードとログをセットで確認すると整理が早いです。
3 ルールモードと「国内直行」をどこに置くか
Mihomo/Clash Meta 系では mode: rule が前提になりやすく、そのなかで評価順がパフォーマンスと挙動を決めます。一般的なパターンは、確実に直行させたい宛先(LAN、国内クラウド、プライベート IP)を上に置き、広い MATCH や/geoip を下に置くことです。「購読ファイルがもともと海外解禁向け」だと、GEOSITE/geolocation-!cn 系のあとにすべてプロキシへ落ちるような並びになっていることがあります。その場合、GEOIP,CN や国内ドメインの RULE-SET を、その FINAL の手前に差し込むイメージになります。
「どこまでを国内とみなすか」はリスト次第です。中国香港・台湾などを含めるかなど、購読している Rule Provider の説明を読み、自分の利用ドメインがどのバケットに入るかを確認してください。誤って広いサフィックスを DIRECT にすると、意図しないホストまで直行する——という逆リスクもあるので、まずはログに出たホストを基点に徐々に足すのが安全です。
4 GEOIP と RULE-SET(国内ドメイン集合)の役割分担
GEOIP は、宛先 IP がデータベース上どの国/地域に属するかを見てルーティングします。名前解決が終わったあとの IPに対して効くため、DNS の結果が変わると振る舞いも変わります。RULE-SET は、購読しているリストに含まれるドメインや IP セットにマッチさせます。GEOSITE に相当するリモートリストを behavior: classical や domain など適切な型で読み込む運用もよく見られます。
「国内アプリのFQDNがすべてリストに載っている」わけではないので、実務ではGEOIP とドメインセットの併用が現実的です。リストの更新タイミングや信頼元については、GEOIP/GEOSITE を手で更新する記事の観点も参照してください。漏れたドメインだけプロキシへ落ちるのか、すべてプロキシへ落ちるのかで体感は大きく変わります。
RULE-SET を足すときの注意
リモート URL をそのまま信頼する場合は、取得元の説明と更新間隔を確認し、冗長なルールが増えすぎないようprofile のサイズと評価コストにも目を向けます。ローカルにミラーしたファイルへ差し替える運用もよく行われます。
5 DNS・FakeIP と「国内直行」の相性
FakeIP を使う構成では、ブラウザとアプリで名前解決の経路が分岐しやすくなります。国内宛てを FakeIP で握りつぶした結果、GEOIP の判定が期待とズレる——という話もあるため、国内ドメインだけ名前解決ポリシーを変える(例:nameserver-policy で特定サフィックスを通常 DNS へ)といった二段構えがプロファイルに入っていることがあります。
詳細なパターンはMihomo の DNS/FakeIP の実務記事に譲りますが、「ルールは DIRECT にしているのにログでは別アウトバウンド」というときは、DNS が別経路になっていないかを疑ってください。モバイル OS のプライベート DNSやブラウザのセキュア DNSも同時に確認するとよいです(Chrome/Edge とセキュア DNS の記事)。
6 YAML に書くときのイメージ(例)
実際のプロファイルではプロキシグループ名やリスト URL が環境依存です。ここでは思考実験用のスケッチとして、コメントは英語のみとします。
# Sketch: put CN-bound traffic on DIRECT before broad proxy FINAL
# Proxy group names are placeholders — align with your profile.
rules:
# Higher priority: explicit CN / domestic buckets if your provider ships them
# - GEOSITE,cn,DIRECT
# - RULE-SET,cn-domains,DIRECT
- GEOIP,CN,DIRECT
# Your overseas / catch-all rules below:
# - GEOSITE,geolocation-!cn,PROXY
# - MATCH,PROXY
# rule-providers example (remote lists — verify URLs and behavior types yourself):
# rule-providers:
# cn-domains:
# type: http
# behavior: classical
# url: "https://example.com/rules/cn.yaml"
# path: ./rules/cn.yaml
# interval: 86400
実環境では GEOIP,CN の一行だけでは足りず、事前にドメインルールで拾うほうが安定するケースもあります。また、アプリが QUIC を使う場合はログの見え方が変わることがあります。細部はクライアントのバージョンとドキュメントを正としてください。
7 「出国解禁」記事との棲み分け
Netflix や各地の動画配信のように、サービス側が視聴地域を制限するジャンルでは、出口を意図した地域のノードへ寄せる説明が中心になります。一方、RedNote/小紅書のような中国本土のフィードや CDN を読むユースケースでは、逆にプロキシで海外へ出しすぎないほうが速くなることがあります。混同しやすいので、プロファイルを複数に分け(仕事用/開発用/家族用など)、目的ごとに購読ルールを切り替える運用も検討の価値があります。
URL-Test や Fallback でどのノードが選ばれるかは別論点ですが、国内直行を挟むとレイテンシの支配因子が変わるため、速度テストの見え方だけで判断しないことが大切です。URL-Test/Fallback の記事とあわせて、計測対象のホストがどのアウトバウンドを通ったかをログで確認してください。
8 確認のしかたと運用メモ
変更後は、① アプリを一度終了してキャッシュの影響を減らす、② クライアントの接続ログで対象ホストが期待のアウトバウンドかを見る、③ それでも迷う場合は一時的にルールを狭くして再現を絞る、の順が無難です。OS の VPN/別製品の TUN と競合していないかも、Tailscale などと同様に経路の優先順位の話として切り出せます(Tailscale と Clash の記事)。
アプリのアップデートでドメインが増えることは珍しくないので、ルールは一度書いて終わりではなく、ログを見ながら追記とリスト更新のサイクルが続きます。その前提で、Git やプロファイルのバックアップ運用を決めておくと安心です。
9 まとめ
RedNote/小紅書のような話題と、その背後にある国内 CDN・認証・計測ホストへの経路はイコールではありません。海外から利用する海外ユーザーほど、すべてをプロキシへ送るプリセットが体感とログインまわりに副作用を生みやすい場合があります。GEOIP と RULE-SET を使って回国分流(国内直行)をFINAL の手前に置き、DNS と FakeIP のチェーンをホームユースの前提に合わせる——この三本柱を押さえると、設定が「机上の空論」ではなくログで検証できる作業になります。
Clash 互換クライアントはルールと DNS を一体で扱えるため、この手の直行と迂回の切り分けに向いています。クライアントの入手とインストール手順は本站のダウンロードページからどうぞ。ソースコードや Issue は GitHub でも参照できますが、パッケージの第一入手先として本站を推奨します。