Switch 2オンライン不安定？Clashで任天堂ネットワークとeShopを分流

症状を「更新取得」「オンライン」「eShop」の三層に分ける

まず現象を言語化すると対処が早くなります。第一に、システム更新 やゲームの パッチダウンロード は進むのに、オンラインプレイ だけが頻繁に切断される、ロビーに入れない——これは 任天堂ネットワーク のセッション系や NAT、UDP の経路、ピア接続の安定性が絡みやすい領域です。第二に、eShop のトップは開けるのに価格や決済、残高表示だけが意図しないリージョンになる、あるいはカタログ取得だけタイムアウトする——こちらは Nintendo eShop やアカウント系のホストが、更新用 CDN とは別集合になっていることが多く、同じ PROXY に載せると片方だけ遅い出口に落ちる、といったミスマッチが起きやすいです。第三に、ブラウザやスマホでは問題ないのに本体だけ挙動がおかしい——ゲートウェイや DNS、本体が参照する名前解決経路が PC とは別、といったケースも含め、観測ポイントを分けます。

ここでの目的は「とにかく全部同じ国のノード」ではなく、用途ごとに最適な出口 を選べるようにルールを並べることです。帯域の大きい取得はスループット優先のノード、レイテンシが効くオンラインは遅延とパケットロスが少ない経路、eShop のリージョン整合は「カタログと決済が同じ出口に揃う」ことを優先、といった住み分けがしやすくなります。なお、Nintendo eShop の利用規約、コンテンツの取り扱い、お住まいの地域の法令、および任天堂の利用条件は遵守してください。本稿は家庭内ネットワークと Clash 分流 の一般的な説明にとどまります。

なぜ「任天堂＝一つのポリシー」では足りないか

Clash のルールは 上から最初の一致 だけが採用されます。購読プロファイルに入っている広い GEOIP や MATCH が先に当たると、その下に書いた任天堂向けの行は評価されません。逆に、DOMAIN-SUFFIX を雑に増やすと、更新用 CDN と オンラインのシグナリング まで同じ出口に吸い込み、結果として「パッチは速いがマルチだけ不安定」という形に見えやすくなります。

任天堂系では、本体が参照するホストが システム・ゲームの大容量取得、eShop のカタログ・購入フロー、任天堂ネットワークのオンライン機能 に跨がるのが普通です。2026 年の Switch 2 を含め、ホスト名やエッジはアップデートで変わりうるため、本稿に示すドメインは 設定時点での一般的なパターン として扱い、必ず 接続ログと実ホスト名 で確認してください。したがって「任天堂用に一本化」より、用途別のポリシー名（例：NN-UPDATE と NN-ONLINE と ESHOP）を切っておき、ログでホストごとにどちらに落ちたかを追える形が運用では扱いやすいです。

ルールの位置 任天堂向けの DOMAIN-SUFFIX 行は、広い GEOIP や最終 MATCH より上に置きます。購読の RULE-SET が先にマッチしている場合は、競合する行の前後関係を入れ替えるか、自前の追記ブロックを最適な位置へ移動してください。

ポリシーグループと DOMAIN-SUFFIX のたたき台

実際のホスト名はクライアントの更新で変わりうるため、以下は例示です。nintendo.net や nintendo.com 系、eShop 周辺のホストをログで拾い、重なりが広すぎないかを確認しながら追記します。更新 CDN だけを別グループに分けると、「パッチは PROXY、オンラインは DIRECT」といった切り分けがしやすくなりますが、ご家庭の回線品質やノードの UDP 対応次第で最適解は変わります。

proxy-groups:
  - name: "NN-UPDATE"
    type: select
    proxies:
      - "high-throughput-node"
      - "DIRECT"
  - name: "NN-ONLINE"
    type: select
    proxies:
      - "low-latency-node"
      - "DIRECT"
  - name: "ESHOP"
    type: select
    proxies:
      - "region-aligned-node"
      - "DIRECT"

rules:
  # Observe real hostnames in logs; examples only
  - DOMAIN-SUFFIX,nintendo.com,ESHOP
  - DOMAIN-SUFFIX,nintendo.net,NN-ONLINE
  # Add CDN hostnames seen during system/game updates to NN-UPDATE
  # Place GEOIP / MATCH below your Nintendo rules

上記は たたき台 です。実際の購読名・ノード名・観測されたホストに合わせて置き換えてください。分流の基礎手順は Clash YAML ルール分流ガイドに揃えています。コアの挙動差を抑えたい場合は Clash Meta（mihomo）の更新も検討するとよいです。

NAT とプロキシ：よくある誤解

NAT タイプ が厳しすぎると オンライン のマッチングやボイスチャットに支障が出ることはありますが、Clash を有効にしただけで NAT が自動的に「開く」わけではありません。家庭内ルーターの UPnP やポート開放、IPv6、二重 NAT、そして プロキシ経由で UDP が期待どおり通るか は別問題です。更新ファイルの取得が速くても、セッション確立に使う UDP が別経路に逃げていると、画面では「切断が多い」ように見えます。

そのため、症状の切り分けでは「まず ログに出たホスト がどの policy に乗ったか」を確定し、続いてルーター側の NAT 表示や本体の接続テストと突き合わせます。プロキシを挟む構成では、ベンダー任せの「NAT タイプ A を目指す」だけより、どのトラフィックが DIRECT でどれが PROXY か を YAML で明示した方が再現性が高いです。

よくある誤設定：更新 CDN とオンラインを同一ポリシーに載せる

運用で多いのが、任天堂の更新 CDN（大容量のバイナリ取得）と 任天堂ネットワークのセッション系 を同じ SELECT にまとめてしまうパターンです。CDN は帯域の大きいノード向け、オンラインは遅延とジッタが小さい経路向け、と分けたいのに、広い DOMAIN-SUFFIX 一発で両方が同じ出口に流れ、オンラインだけ不安定になることがあります。

第二に、eShop の リージョン跨ぎ を意図しているのに、DNS の出口と HTTP の出口がずれて カタログと決済画面の国表示 が矛盾する——これは分流だけでなく 名前解決 の経路も揃える必要があるサインです。第三に、ルールは正しいのに本体がプロキシを知らない——PC では TUN が効いていても、LAN 上の別デバイスはゲートウェイ設定が別、という構成では Clash が関与しません。対象が PC エミュレータ なのか実機なのかを先に固定してください。

DNS・fake-ip・TUN：eShop だけおかしいとき

ルール以前に、名前解決やデバイスのプロキシ認識でつまずくことがあります。Clash の fake-ip モードでは、表示上の IP と実接続の対応が直感とずれるため、「どのドメインがどのルールに当たったか」をログで追う習慣が重要です。nameserver-policy で特定ドメインだけ別 DNS へ送っている場合、ポリシーが広すぎると意図しないホストまで別 DNS に流れ、リージョン判定が乱れることがあります。詳細は DNS fake-ip と redir-host の切り分けを参照してください。

また、エミュレータや PC クライアントが システムプロキシを無視 していると、ブラウザはプロキシ経由なのに本体プロセスだけ直結し、ルールを変えても効かないように見えます。Windows では TUN モードの利用が有効なことがあります。UWP 系が絡む場合は UWP とループバックの記事も参照ください。

利用規約と法令 任天堂の各サービス利用条件、お住まいの地域の法令、および eShop の利用規約を遵守してください。本稿はネットワーク設定の一般的な説明にとどまります。

再現できる切り分けチェックリスト

設定を変えたあとは、短時間でよいので ログを開いたまま 更新取得・eShop 表示・オンライン接続を試し、対象ホストにどの policy が付いたかを確認します。

更新・パッチだけ遅い：CDN 向けホストが NN-UPDATE（または同等のグループ）に乗っているか、帯域制限と別ホストへのフォールバックを疑います。
オンラインだけ切断が多い：nintendo.net 系が NN-ONLINE に向いているか、UDP と NAT、ノードの混雑をログとルーター表示で比較します。
eShop の表示だけリージョンがずれる：ESHOP に揃えた出口と DNS の出口が一致しているか、fake-ip と実ホストの対応を追います。
ルールを変えても変わらない：より上の RULE-SET が先に一致していないか、対象プロセスがプロキシを迂回していないかを疑います。

サブスクリプションの更新失敗と混同しないよう、通信エラーが出ているときは購読更新の切り分けも参照してください。

運用のコツ：ログを単一の真実にする

長期運用では、購読 YAML に任せきらず、自分の環境で実際に出たホスト名に合わせて数行追記する姿勢が効きます。複数台の Switch や家族アカウントがある場合も、同じポリシー名・同じノード選び に揃えると挙動が追いやすくなります。2026 年のホームコンソールではクラウドセーブや追加コンテンツの取得も絡むため、失敗時は必ず 時刻とホスト名 をメモしてからルールを足すと、誤爆を減らせます。

まとめ

2026 年も、Switch 2 や Nintendo Switch で 任天堂ネットワーク の オンライン が不安定だったり、Nintendo eShop の リージョン まわりだけ挙動が変だったりするときは、更新用 CDN と セッション／口座／ストア が同じ経路に乗っていないかを疑うのが近道です。Clash 分流 では ポリシーグループ を用途別に分け、DOMAIN-SUFFIX でホストを拾い、ルールの 上からの一致 とログのポリシー名を照らし合わせます。NAT はプロキシだけでは解決しない前提で、ルーターと UDP、そして DNS や fake-ip とセットで見ると、直結や誤ノードの原因を切り分けやすくなります。

クライアントの選定や入手経路はダウンロードページで一覧できます。GUI の違いで迷ったときも、まずログで「どのルールに乗ったか」を確定させ、そこから YAML を調整すると手戻りが減ります。

→ Clashを無料ダウンロード — 各 OS 向けクライアントを比較し、自分の環境に合うものから試せます。

関連：YAML ルール分流の全般、技術コラム一覧。