一、主機與 PC：為什麼不能照搬 Steam 進程分流
在 PC 上，許多使用者會參考本站 Steam 與 Clash 進程分流 或 Discord 語音與 UDP 專文，透過 PROCESS-NAME 鎖定特定執行檔，再搭配 TUN 讓 UDP 一併進核心。這條路在 Windows 客戶端上非常直觀，因為你能看見是哪個行程在連線。
Nintendo Switch 2（以及前代 Switch）則封閉得多：你無法在主機上安裝 Clash、也無法指名「只代理某個系統行程」。主機對外連線時，對你的區網來看就是一台終端設備的 IP 在發起連線。因此，實務上的切入點變成兩件事：
- 讓 Switch 2 的預設閘道指向你正在跑 Clash 的設備（或上層路由器已把透明流量導去該設備）。
- 在 Clash 內用網域／IP 規則描述「任天堂相關流量」該走哪個策略組，並確保 DNS 與 fake-ip 行為不會讓主機拿到錯誤的解析結果。
換句話說：PC 場景常問「哪個 exe 沒進代理」；主機場景要先問「整台主機有沒有把閘道指對」以及「規則有沒有覆蓋到實際連線的主機名與 CDN」。
二、eShop 與下載：CDN 網域與策略組思路
eShop 卡在下載、更新進度條不動，或速度長期偏低，常見原因不一定是「節點不夠貴」，而是下載流量實際沒有走你預期的出口，或解析到的 CDN 邊緣節點與你當前網路路徑不相配。任天堂的內容分發會使用多組公開可觀察到的網域後綴（實際清單會隨時間調整），實務上會以 DOMAIN-SUFFIX 類規則成組指向同一個策略組，例如專用的「任天堂／遊戲下載」分組，與一般瀏覽、串流分開，避免互相搶佔延遲或頻寬感知。
與「只開系統代理」的差異
主機沒有「系統 HTTP 代理」這種 PC 常見路徑；它預設就是IP 層直連經閘道。若你只在 PC 上開代理，而 Switch 2 仍指向家裡路由器的預設 DNS 與 WAN，那麼 eShop 行為完全不會被 Clash 看見。這也是為什麼討論 Clash 與任天堂時，幾乎一定會回到閘道／旁路由架構。
DNS 與 fake-ip 的連動
若你的 Clash 使用 fake-ip，請確認主機取得的 DNS 回應與核心日誌一致；部分情境下，主機內建 DNS 快取或路由器轉發順序會讓你以為「規則已寫好卻沒命中」。可先對照 fake-ip 與 DNS 排查 的思路，並在測試時盡量一次只改一個變因。
三、線上遊玩、UDP 與 NAT：代理要接得住
線上對戰、語音與部分配對流程高度依賴 UDP。當使用者描述「下載還行，一進連線就掉」「NAT 從 B 變 D」時，往往要同時檢查：
- Clash／節點路徑是否完整轉發 UDP（含核心與上游協定能力；名稱與預設隨版本而異，請以所用版本文件為準）。
- 雙層 NAT 或電信級 CGNAT 是否讓主機難以建立穩定對外映射；有時需在上層路由器做 DMZ／連接埠轉發，或調整「誰是對外最後一跳」。
- IPv6 雙堆疊是否讓部分流量繞過你預期的 IPv4 代理路徑；若家裡啟用了 IPv6，可一併閱讀 IPv6、介面與規則 的核對順序，避免「以為全走 Clash，其實一半走別條隧道」。
與 Discord 語音類似，TCP 正常但 UDP 異常時，問題經常不在「網站打不開」，而在即時連線的封包型態。差別在於 Switch 2 無法像 PC 一樣用進程規則精準點名，你要用閘道規則把整台主機的出口行為調到一致，並在日誌中觀察實際命中的規則與節點。
四、閘道與旁路由：Clash 放在哪裡最有效
實務上常見兩種拓扑：
- 旁路由（gateway 指向旁路由 LAN IP）：主機與其他裝置仍在家用子網路內，但預設閘道設為旁路由；旁路由上跑 Clash 並負責把對外流量依規則送出。透明轉發、nftables 與預設路由細節可對照 旁路由透明代理與閘道排查。
- 主路由直刷／內建 Clash：整網出口統一由一台設備處理，Switch 2 只需 DHCP 取得正確閘道與 DNS；維護成本較低，但硬體與固件選型要求高。
無論哪一種，核心都是：Switch 2 發出的封包要先進入你能看見日誌的那層，否则再漂亮的 DOMAIN-SUFFIX 也不會被觸發。若你同時在 PC 上使用區網共享或混合埠，亦可參考 混合埠與區網防火牆，但請注意主機場景的重點仍是閘道 IP，不是 Windows 系統代理。
設定 訂閱與規則 時，建議為「任天堂／遊戲主機」單獨建立策略組，與一般 PROXY 大雜燴分離；這樣在做下載測速或對戰測試時，可以快速 A／B 切換節點而不影響其他裝置。
五、規則草圖：DOMAIN-SUFFIX 與順序（概念示例）
以下僅為結構性示例，實際網域集合請依你所在區服、固件版本與抓包日誌更新；切勿未驗證就整段複製到生產環境。
- 策略組：新增
Nintendo-Shop、Nintendo-Online等分組，依需求合併或分離「下載」與「對戰」。 - 規則順序：將較具體的任天堂相關條目放在寬鬆的
GEOIP或MATCH之前，避免被提前吃掉。 - 典型後綴方向（須自行核對）：常見討論會提到
nintendo.net、nintendo.com、nintendo.co.jp、nintendo-europe.com等商務與服務網域，以及與內容交付相關的主機名；實務上宜搭配連線日誌動態補齊。
若你使用圖形介面客戶端，重點仍是「策略組是否獨立」與「規則是否早於最終匹配」；YAML 只是表達同一邏輯的一種方式。
六、實測排查順序（從現象到設定）
建議依序收斂問題，避免同時更換節點、DNS、閘道與固件設定：
- 確認閘道：在 Switch 2 網路詳情中檢查 IPv4 預設閘道是否為你的旁路由／Clash 設備。
- 確認日誌有主機流量：於 eShop 觸發一次下載或更新，觀察核心是否出現對應連線；若完全沒有，先修拓扑與防火牆，不要先換節點。
- 分離下載與對戰問題：下載慢偏向 CDN／TCP 吞吐；對戰掉線偏向 UDP／NAT／雙層路由——兩組現象的優先檢查項不同。
- 最後才微調節點地區：在路徑正確的前提下，再比較延遲、丟包與實際「NAT 顯示」是否改善。
| 現象 | 優先檢查 |
|---|---|
| eShop 長時間 0％ 或極慢 | 閘道與 DNS 是否經 Clash；任天堂 CDN 網域規則是否命中；節點對大檔下載是否穩定 |
| 下載正常但線上對戰頻繁斷線 | UDP 是否完整經過代理鏈路；是否存在雙層 NAT；IPv6 是否繞路 |
| 日誌幾乎沒有任天堂連線 | Switch 是否仍走原路由器出口；DHCP 閘道是否被還原；透明轉發規則是否漏配 |
七、常見誤區與合規提醒
常見誤區包括：以為「買更高價節點」就能解決一切，其實主機流量根本沒進 Clash；或同時開啟多個會改寫路由的服務，導致來回切換預設路由而讓 NAT 表現更不穩定。建議保留可還原的設定備份，並在每次改動後只驗證一類現象（下載或對戰擇一）。
請遵守所在地法律與任天堂網路服務條款；本文僅討論區網拓扑與規則分流的通用技術，不鼓勵任何違規使用方式。若你僅需改善家庭區網品質，亦可先從實體線路、路由器韌體與 DNS 著手，再決定是否引入代理分流。
八、小結
Nintendo Switch 2 的 eShop 與線上聯機問題，與 Clash 結合時，核心不是再找一條「神奇節點」，而是把主機流量納入你可觀測的閘道路徑，再用分流規則對任天堂相關 CDN 網域與出口策略做收斂，並嚴肅看待 UDP 與 NAT 與 PC 場景的差異。相較於可在 Windows 上鎖定行程的 Steam／Discord 方案，主機路線更依賴旁路由或主路由上的 Clash，也與本站 透明閘道 類文章形成互補。
長期維護上，把「任天堂／遊戲主機」獨立成策略組、用日誌驗證規則命中，通常比堆疊靜態網域表更可靠；若你偏好圖形客戶端與可替換核心，Clash 生態在規則組合與可觀測性上仍較容易與家庭網路一併調校。
想從本站取得適用多平台的客戶端與設定指引，可先匯入訂閱後，再依本文順序檢查閘道、DNS 與 UDP 相關選項。