1. PC の Steam／Discord 記事との違い：プロセスが取れない
本サイトでは既に、Windows 上の Steam と Clash のプロセス分流や、Discord のボイス通信と UDPを扱った記事があります。いずれも実行ファイル名やPC クライアントのログが手掛かりになるのが大きな特徴です。
一方、Nintendo Switch／Switch 2 では、一般ユーザーが OS 深部のプロセス一覧を眺めながらルールを書く、という運用が現実的ではありません。また本体はモバイル／据え置きハイブリッドのファームウェア上で動いており、パケットを見る場所は家庭内ルータやゲートウェイ側の Clashに寄せがちです。そのため本稿の主役は PROCESS-NAME よりドメイン／IP 集合と、L4（UDP）が意図した経路を通っているかという観点になります。
2. eShop とオンラインが使う通信のイメージ
eShop（コンテンツ販売・ニュース・ダウンロード）は、HTTPS／TLS を中心に公式サイトや CDNへ向かう通信が多く見えます。Nintendo Switch Online を含むオンライン対戦や協力プレイでは、マッチメイクやセッション維持にUDPが絡むことがあり、ここはレイテンシやポート開放の話題がネット上で頻出します。タイトルごとにNAT タイプの表示がある場合もありますが、それはあくまで目安であり、表示より実際の切断頻度とルータ／プロキシ側のログを優先してください。
任天堂のサービスは時期とリージョンによりホスト名や CDNが変わり得るため、ここでは固定のルール表を列挙せず、自分の環境のログに現れた名前を正にする方針を推奨します。クローズドな環境の具体的な内部ホスト名まで掘る行為は、サービス利用規約やセキュリティ運用に抵触しうるため避けてください。
3. ドメイン分流で手を付ける場所
Clash の rules: は上から評価です。DOMAIN-SUFFIX,nintendo.com,PROXY のような書き方は一例で、実際には広い GEOIP やルールセットが先にヒットしてしまうと、任天堂向けの細かい指定が無視されます。まず既存の MATCH より前に小さなドメイン／サフィックスを置けるかを確認します。
ログを取る順序
ゲートウェイ側で接続ログが取れる構成なら、eShop を開いている最中とオンライン対戦を試している最中で、出てくる宛先のホスト名または IPの傾向が変わることがあります。前者は CDN／静的配信寄り、後者はUDP の宛先が目立つことがあります。この差をメモしてからルールを足すと、思い込みでの大量追記を避けられます。
# Illustrative — replace domains/policies with entries from your logs
rules:
- DOMAIN-SUFFIX,nintendo.com,NINTENDO
- DOMAIN-SUFFIX,nintendo.co.jp,NINTENDO
- DOMAIN-SUFFIX,nintendo.net,NINTENDO
# Add CDN hostnames seen in your gateway logs (Akamai, Cloudflare, etc.)
- MATCH,DIRECTNINTENDO は「低遅延優先のノードへ固定したい策略グループ」のような専用ポリシー名として置いています。url-test で常に遠いノードへ振られる場合は、interval と tolerance の調整記事も併読すると、切り分けが早くなることがあります。
クライアントの配布物・インストール手順は 当サイトのダウンロードページから、設定全体の考え方は ドキュメントで補完してください。
4. UDP と NAT：Clash が効くレイヤ
オンライン対戦のP2P的な通信では、UDP がトンネルの外に落ちていると、マッチ自体は成立しても中盤で切断することがあります。HTTP プロキシのみの環境では UDP が乗りにくく、Mihomo／Meta 系でもUDP を中継できるノード種別やTUN ほかの取り込み口との組み合わせが絡みます。ここはPC でゲーム exe を TUN に載せる話とは勝手が違うため、Switch で「全部を PC と同じ設定ファイルに」押し込むより、ゲートウェイ側でどの IP／ポートが外へ出ているかを先に見ます。
Nintendo Switch Online のランクマッチや協力プレイでは任天堂のサーバ経由になるケースもあり、タイトルによりピア接続の比重が変わります。そのため「UDP をまとめてプロキシへ」が常に正解とも限りません。迂回が長くなると逆に遅くなることもあるので、ノードの地理と ISP の混雑をセットで見ます。
5. 旁ルータ・ゲートウェイで動かすとき
Switch／Switch 2 を旁ルート（サイドルータ／サブルータ）配下の LAN に置き、そのルータ上で Clash を透過的に運用する構成は、ゲーム機の設定を極力いじらずに出口を揃えられる一方、nftables／iptablesとゲートウェイ設定が絡みます。nftables の順序やマーク回りを誤るとループや部分不通が出やすいので、旁ルータとnftables の記事でネットワークスタックのレイヤを整理してから、ドメイン分流に進むのが安全です。
クラウドゲートウェイではなく自宅出口で Clash を動かす前提において、ゲーム機は静的 DHCP 割り当てで旁ルート側に固定し、問題の切り分け対象を一台に絞るとログが読みやすくなります。このとき二重 NATになりやすい構成では、先に親ルータ側の DMZ／ポート転送の扱いと矛盾がないかも確認します。
ゲーム以外の家庭内デバイスまで同じポリシーに巻き込むと、ブラウジング用途と遅延敏感な UDPが衝突することがあります。別 SSID／別 VLANで Switch だけをゲートウェイのポリシーに載せる運用も検討余地があります。
6. DNS と IPv6 のあわせ確認
eShop が「ずっと読み込み」の場合、実体はCDN の名前解決と TLS側に原因があることも多いです。fake-ip と実アドレスの組み合わせが噛み合わないと、画面上はストアだけ不思議に遅くなることがあります。また IPv6 と IPv4 のデュアルスタックで、意図しない経路に出口が分かれると、Nintendo Switch Online の安定性に影響が出る話題がフォーラムで散見されます。
IPv6 とインタフェース・ルールを切り分ける記事は中国向けサイトが主題ですが、AAAA レコード優先やGEOIP の対象族という観点は、そのまま「IPv6 だけ挙動が変」なトラブルの調査に転用できます。IPv6 を一旦オフにしたときだけ改善するなら、IPv4 限定のルールとの整合を疑う価値があります。
7. 症状と切り分け対照表
| 症状 | 見やすい原因 | 先に試すこと |
|---|---|---|
| eShop の一覧や価格だけ遅い／更新が進まない | DNS／CDN 出口の不一致、TLS 失敗 | ドメインログ、ノードの地域固定、DNS を一段シンプルに |
| オンラインは頻繁に切断・NAT 表示が厳しい | UDP の迂回、二重 NAT、親ルータとのポート | 旁ルート構成の見直し、ゲートウェイのUDPログ |
| 本体アップデートだけ失敗する | CDN ドメインが別ポリシー／直結 | アップデート時ログのホスト名をルールセットへ |
| Wi‑Fi は動くがドックの有線だけ不安定 | レイヤ2／ケーブル／別 DNS | 有線と無線でゲートウェイ設定が同一か確認 |
| 特定ゲームだけマルチ不可 | タイトルのサーバ／P2P の差 | 共通ルールよりログの差分を取る |
9. まとめ
Switch 2／従来機を Clash のルール分流とUDP／NATの視点で見るとき、決定的な違いはPC でプロセス名を取れるかどうかです。Nintendo Switch Online と eShop はログに現れるホスト名や CDNを正としてルールを育て、旁ルートやゲートウェイで運用するならnftables とゲートウェイの一体設計を先に安定させると手戻りが減ります。2025〜2026 年のハード世代交代で話題が増えても、この軸は変わりません。
Mihomo／Meta 系コアはログとルールの対応が追いやすい強みがあり、試行のたびに変更は一つだけという鉄則と相性がよく、家庭内のゲーム向け出口設計でも再現性が出やすいことがあります。