なぜ「海外にいるのに本国アプリだけ不調」になりやすいのか

旅行中のスマホは、見た目は一つの端末でも、背後ではDNS名・CDN・認証サーバ・決済ゲートウェイがバラバラのドメインに分散しています。地図アプリはタイル画像やルート計算APIがグローバルに最適化されたホストに乗りやすく、遠い出口経由でも体感が悪化しにくい一方、銀行や決済、一部の行政・保険アプリは本国IPからの到達や低遅延を暗黙に期待する実装が残っていることがあります。

ここでClashの分流ルールを雑に扱うと、購読プロファイル同梱の巨大なRULE-SETが先にヒットし、金融ドメインまでまとめて海外ノードへ送られる、あるいは逆にすべてDIRECTに寄せて現地でブロックされているサービスだけが開かない、という二極化が起きます。ユーザーから見ると「OTPが遅い」「3DSが回らない」「地図の読み込みインジケータだけが回る」など、症状はバラバラに見えますが、多くはルールの優先順位とポリシーグループの割当の整理でかなり見通しが良くなります。

分流の骨格はYAMLルール分流の解説で詳しく扱っています。旅行用プロファイルを作るときは、まず「どのホスト名を、どの出口に揃えたいか」を紙に書き出すと迷いが減ります。特にrulesは上から順に評価され、最初の一行だけが採用されるため、例外は必ず購読の広いRULEより上に置く、という原則を頭に入れてください。

ステップ0：旅行プロファイルの「3つの出口」を決める

実装に入る前に、ポリシーグループの役割を三つに分けると運用が楽です。名前は任意ですが、本稿では次のイメージで説明します。

  • 現地・グローバル向け：地図、翻訳、海外で使うSNS、現地予約サイトなど。遅延の少ないノードや、現地に近い出口を選びたいグループ。
  • 本国・帰国後も触るサービス：銀行、クレジット、電子マネー、本国キャリアのマイページ、行政ポータルなど。意図的に本国に近いノードや、契約上許される経路に寄せたいグループ。
  • 直結（DIRECT）：キャリアの認証、Captive Portal、プライベートIP、明らかにプロキシを挟むべきでないホスト。

実際のYAMLでは、proxy-groupsに上記に対応するselectやurl-testを用意し、rules側でDOMAIN-SUFFIX,example.jp,POLICY_JPのように振り分けます。ポイントは「アプリ単位」ではなく「ドメイン単位」で考えることです。アプリは内部で数十のホスト名を叩くため、ログに出た名前を少しずつルールへ足す方が現実的です。

モバイル回線特有の切り分け（購読更新失敗、全ノードタイムアウトなど）はiOS 18とセルラー周りの記事とも補完的です。出国前に購読リンク（サブスクリプションURL）が取得できる状態にしておき、現地で壊れたときの復旧手順まで紙またはメモアプリに残しておくと安心です。

ステップ1：DOMAIN-SUFFIXで地図・決済の「束」を先に作る

旅行中に頻出するのが地図・ナビです。Google系、Appleのマップ関連、現地で主流の地図サービスは、それぞれDOMAIN-SUFFIXで束ねやすいです。例として構造だけ示します（実際のサフィックスは利用サービスに合わせて増減してください）。

# Example: map / global-ish block above subscription RULE-SET
rules:
  - DOMAIN-SUFFIX,googleapis.com,POLICY_GLOBAL
  - DOMAIN-SUFFIX,gstatic.com,POLICY_GLOBAL
  - DOMAIN-SUFFIX,apple-mapkit.com,POLICY_GLOBAL
  # ... your bank / e-money DOMAIN-SUFFIX lines to POLICY_HOME ...

銀行・決済・ポイントアプリは、公開されているAPIドメイン一覧があればそれに従うのが確実です。無い場合は、クライアントの接続ログや、一時的にGLOBAL相当へ流したときの挙動差からホスト名を拾い、本国グループへ移すという作業を繰り返します。最初から完璧を狙わず、失敗したアプリのドメインだけを足す方が早いです。

このときよくある落とし穴が、購読側のRULE-SETが先にマッチしてしまうことです。GUIによってはカスタムルールが自動的に先頭へ来ますが、来ない場合はエクスポートしたYAMLで物理的な並びを必ず確認してください。並びの考え方は学内Captive Portal稿と同様で、狭い例外ほど上です。

ステップ2：GEOIPは補助線として置く

GEOIP,JP,DIRECTやGEOIP,JP,POLICY_HOMEのような行は、ルールを短く保てる魅力があります。ただし旅行シナリオでは次の理由でGEOIPだけに依存しない方が安全です。

  • CDNの実IPが、見た目の国コードと一致しないことがある。
  • 複数国をまたぐ旅行では、「今どの国をHOMEとみなすか」が日ごとに変わる。
  • eSIMとローミングの切り替えで、同一アプリでも最適出口が変わる。

実務的には、金融・OTP・決済はDOMAIN行で固める→そのうえでGEOIPを広いフォールバックに置く、という階層が扱いやすいです。ルール設計の詳細は使い方ガイドのルールモード説明とも整合的です。

ステップ3：OTP・3DS・プッシュ通知の「見え方」を切り分ける

SMSベースのワンタイムパスワードは、厳密にはClashのHTTPプロキシの外側にいることが多いです。それでもユーザー体験として「アプリ内の確認画面が海外出口経由で遅い」「プッシュの遅延に見える」といった報告はあります。ここではアプリが参照するHTTPSホストをログで追い、本国ポリシーへ寄せるのが現実的です。

3DセキュアやWebView内の決済は、ブラウザコンポーネントと共有のプロキシ設定を読むため、OSのシステムプロキシとClash TUNのどちらで捕まえているかも変数になります。WindowsやmacOSで挙動が変わる場合はTUNとシステムプロキシの比較記事でモード差を整理してから再試行してください。

ステップ4：DNS（fake-ip／redir-host）で「地図は開くのに決済だけ失敗」を潰す

ルールが正しくても、名前解決の段階で別IPに着地すると、アプリは別リージョンのエッジへ接続してしまいます。旅行中はキャリアDNSと公共Wi‑FiのDNSが切り替わり、症状が場所依存に見えがちです。

Clashのdns.enhanced-modeがfake-ipのとき、特定ドメインだけ実解決へ寄せるnameserver-policyを検討してください。手順の型はDNS fake-ipとredir-hostの記事に任せると早いです。「地図だけおかしい」「本国アプリだけ証明書警告が増える」といったときは、DNSとルールをセットで疑うのがコツです。

ステップ5：ホテルWi‑FiとCaptive Portalに遭遇したら

空港・ホテル・カフェのWi‑Fiは、ログイン前にHTTPSが介入されるCaptive Portalが挟まることがあります。このとき全トラフィックをプロキシへ送る設定だと、認証ページが開かない症状に見えます。対策の基本は、いったんClashのシステムプロキシ／TUNを外してポータルを完走し、その後に旅行プロファイルを有効化する、という順序です。

ルール面では、認証ドメインやプライベートレンジをDIRECTへ置く考え方が有効です。具体例とチェックリストは学内Wi‑FiとCaptive Portalの記事が近いので、旅行用プロファイルの先頭ブロックとして再利用しやすいです。セルラーとWi‑Fiを行き来する旅では、SSIDが変わるたびにログで最初の数パケットを見る習慣があるとトラブルが早く終わります。

ステップ6：現地での実測順（ログの見方）

おすすめの確認順は次のとおりです。

  1. 接続直後：ブラウザで軽いHTTPSが開くか（Captive Portalの有無）。
  2. 地図アプリ：タイル読み込みと現在地更新。ログに出るドメインが想定のポリシーへ流れているか。
  3. 本国銀行／決済：ログイン〜送金〜3DSまで。失敗したホスト名をメモしDOMAIN行を追加。
  4. 帰国後に使うサービス：予約確認、キャリアマイページなど、旅行中も触るドメインを本国側に残す。

ログにmatched ruleやポリシー名が出るクライアントなら、期待と違う行に当たっていないかを最優先で確認します。旅行中にYAMLを大きくいじるのはリスクが高いので、出国前にベースを固め、現地では小さなDOMAIN追加に留める運用が安全です。

ストリーミング特化の分流（ワールドカップやディズニーなど）とはドメイン集合が異なりますが、「必要なホストをログで特定してポリシーへ束ねる」という作業姿勢は共通です。季節ネタに引っ張られず、自分の端末で実際に叩かれた名前を信じるのが近道です。

よくある質問

海外ローミング中に「地図は速いのに銀行アプリだけ遅い」のはなぜですか？

地図CDNやグローバルAPIは遠隔ノード経由でも実用的な一方、本国金融はIPや遅延に敏感な実装が残る場合があります。一括プロキシをやめ、金融ドメインを本国ポリシーへ分離すると改善することが多いです。

GEOIP,JP,DIRECTの一行だけでは足りませんか？

補助にはなりますが、CDNやフロントの実IP判定ズレ、複数拠点利用、Captive Portal下の例外で破綻しやすいです。重要ドメインはDOMAIN-SUFFIXで明示してください。

ホテルや空港のWi‑Fiでも同じ設定でよいですか？

基本は同じですが、認証前はプロキシを一時停止してポータルを完走させるのが安全です。学内Wi‑Fi稿の「直結を先頭に」の発想がそのまま使えます。

購読プロファイルを更新すると手書きルールが消えますか？

クライアント次第です。消える場合はローカルRule ProviderやバックアップYAMLで再注入してください。旅行前にエクスポートを残しておくのが確実です。

まとめ

2026年GWの海外旅行では、地図・決済・本国アプリが同一端末に共存し、セルラーとWi‑Fiを切り替えるたびに最適経路が変わる状況が起きやすいです。Clashの強みは、そうした混在をルールの優先順位とポリシーグループで整理し、ログに基づいて少しずつ調整できる点にあります。購読の巨大RULE-SETに丸投げせず、自分用の短い例外ブロックを上に積む習慣を身につけると、OTP遅延や地図の不整合に振り回されにくくなります。

クライアントの見た目は製品ごとに違っても、YAMLの考え方は共通です。安定したコアと分かりやすいGUIを選び、旅行用と日常用でプロファイルを分けておくと、次の連休にも同じ資産を使い回せます。

→ Clashを無料ダウンロード — Metaコア対応クライアントを一覧から選び、出国前に旅行用プロファイルのエクスポートと購読リンクの疎通を済ませておけます。

ほかのチュートリアルや最新記事は 技術コラム からどうぞ。