2026 Switch 2 온라인·eShop 다운로드가 버벅일 때: Clash 닌텐도 도메인 분류·RULE-SET·DNS·노드 선택 실측

2025–2026 주기에 Nintendo Switch 2를 사거나 기존 본편과 병행해서 쓰는 사용자가 늘면서, 검색창에는 「eShop 느림」「펌웨어·게임 다운로드」「닌텐도 온라인 매치」 같은 키워드가 같이 붙습니다. Clash를 켠 가정용 게이트웨이·공유기 옆 라우팅(PC)·LAN HTTP 프록시 환경에서는, 브라우저가 빠른데 콘솔만 업데이트가 멈추는 식으로 증상이 갈라지기 쉽습니다. 이 글은 Steam·Epic 스토어·CDN 분류 글과 달리, 윈도 런처가 아닌 닌텐도 OS·NAT·P2P성 온라인까지 포함한 콘솔 트래픽을 전제로, 출구별 도메인DOMAIN-SUFFIX·RULE-SET으로 정리하고 DNSfake-ip를 맞춘 뒤 노드 지연을 비교하는 실측 순서입니다. 합법적인 본인 소프트웨어 이용을 전제로, 지역 스토어 약관·온라인 서비스 이용 조건을 어기는 우회를 다루지 않습니다.

① PC Steam·Epic 글과 무엇이 다른가

Steam이나 Epic Games Launcher는 윈도·맥에서 동작하고, 시스템 프록시나 TUN으로 잡으면 연결 로그에 호스트가 비교적 모이기 쉽습니다. 반면 Nintendo Switch 2는 브라우저 개발자도구로 한 번에 보기 어렵고, eShop·시스템 업데이트·일부 온라인 플레이가 서로 다른 닌텐도 CDN·인증 계층으로 갈립니다. 그중 일부는 NAT 타입·UDP·세션 유지 특성 때문에「노드만 바꾸면 된다」는 단순 모델이 잘 안 맞습니다. 따라서 목표는 글로벌 MATCH 한 줄에 콘솔까지 맡기는 것이 아니라, 게이트웨이에서 관측 가능한 목적지를 모아 분류 규칙을 적층하는 것입니다.

이미 OpenWrt·OpenClash로 집 전체를 올린 사용자라면, LAN 대역에서 콘솔 MAC·IP를 고정하고 동일한 YAML 패턴만 반복 적용하면 됩니다. 절차는 OpenWrt 오픈클래시 구독·분류 글과 맞물리며, 본문은 데스크톱 Clash·Mihomo 코어가 게이트웨이 뒤에서 돌아가는 경우에도 동일한 논리를 씁니다.

② 증상을 네 가지 축으로 나누기

첫째, eShop 목록은 뜨는데 결제·캐시 적립만 실패한다. 둘째, 펌웨어게임 본편 다운로드 진행률이 0% 근처에서 멈춘다. 셋째, 스플래툰·마리오 카트 같이 온라인 매치만 끊긴다. 넷째, 닌텐도 온라인 클라우드·확장 팩 관련 기능만 불안정하다. 이 중 1~2번은 HTTPS 기반 상점·CDN 경로와 DNS·규칙 순서 이슈가 비중이 크고, 3번은 회선 품질과 더불어 NAT·UDP가 상위 후보입니다. 같은 「프록시를 껐을 때만 괜찮다」라도 원인 레이어가 다르므로, Clash 로그에서 어느 도메인 묶음이 먼저 걸리는지부터 씁니다.

가정에서 흔한 오해는「노드 선택을 일본으로 두면 eShop이 항상 빨라진다」는 것입니다. 실제로는 계정 리전·결제 수단·컨텐츠 배포망 엣지가 얽혀 있어, 이름만 같은 프록시 그룹이라도 대역폭·지터 차이가 큽니다. 그래서 측정값과 함께 규칙을 적어야 하며, 프록시 그룹 가이드에 맞춰 그룹 이름·url-test·fallback을 설계합니다.

③ 닌텐도 트래픽의 도메인 층(관측 우선)

인터넷에 돌아다니는 고정 목록을 통째로 붙여 넣기보다, 본인 환경에서 Clash가 잡은 목적지를 기준으로 접미사를 늘려 가는 편이 안전합니다. 구조적으로는 다음 유형이 자주 등장합니다.

  • 계정·전자상거래 계열: 로그인·구독·영수증·환불과 연결된 호스트. 작은 요청이 많아 지연에 민감하고, 브라우저로 결제한 뒤 콘솔이 동기화하는 시나리오와 겹치기도 합니다.
  • eShop·콘텐츠 메타데이터: 카드·썸네일·설명 페이지. CDN로 리다이렉트되는 패턴이 있어 상점 본문과 실제 바이너리 호스트가 갈라질 수 있습니다.
  • 시스템·게임 다운로드: 대용량 전송은 특정 상업 닌텐도 CDN 호스트에 모이는 경우가 많습니다. PC 스토어 글의 「상점 vs 콘텐츠」 분리와 같은 발상입니다.
  • 온라인 세션·친구·알림: 매치메이킹과 별도로 장기 세션을 유지하는 호스트가 있을 수 있어, 규칙 순서 앞쪽에서 잘못 잡히면 간헐적 끊김으로 이어집니다.

실제 접미사는 리전·펌웨어 버전·콘텐츠에 따라 바뀔 수 있으므로, 아래 코드 블록의 이름은 예시이며 반드시 로그로 교체해야 합니다.

④ DNS·fake-ip가 콘솔 규칙을 흐리는 방식

DNS는 이름을 IP로 바꾸는 계층이지만, Clash에서는 규칙 매칭의 전제가 됩니다. fake-ip 모드에서는 브라우저에 보이는 주소와 코어가 규칙을 적용할 때 쓰는 흐름이 달라질 수 있어, no-resolve·규칙 순서를 세트로 맞춰야 합니다. 반면 redir-host 계열은 해석 경로가 다르게 느껴질 수 있고, 공유기에 별도 DoH를 켜 둔 채 코어 DNS와 이중으로 쓰면 「규칙에는 맞는데 실제 소켓이 다른 길」 같은 증상이 나올 수 있습니다.

가정용 하드웨어에서 자주 보이는 구성은「ISP 기기 → 클라이언트 공유기Switch」 삼단입니다. 이때 DNS 서버가 한쪽만 부모 쪽으로 올라가고 콘솔만 다른 값을 쓰면, PC에서 잘 되던 프록시가 콘솔에만 깨져 보일 수 있습니다. 점검 시에는 한 번에 한 계층만 바꾸고, 동일한 다운로드를 재시도하며 연결 로그의 적중 규칙이 같은지 확인하세요. 원리 보완은 TUN·DNS 심화를 함께 보면 빠릅니다.

⑤ DOMAIN·RULE-SET을 쌓는 순서

구독 공급자의 RULE-SET이 이미 게임·소셜 대역을 넓게 덮고 있다면, 사용자 규칙은 앞쪽에 두어야 합니다. 그렇지 않으면 닌텐도 접미사가 더 일반적인 MATCH나 다른 그룹에 먼저 먹혀, 의도와 다른 노드 선택으로 빠집니다. 문법은 사용자 정의 규칙과 동일하며, YAML에서 rules에 적은 대상 이름이 proxy-groups완전히 일치해야 합니다.

원격 규칙 세트를 쓰는 경우에도, 로컬 DOMAIN-SUFFIX 몇 줄이 실제 증상을 바꿀 때가 많습니다. 이유는 세트가 의도한 지역·상품군과 본인 계정 리전이 다르거나, CDN 호스트가 세트 스냅샷에 아직 없을 수 있기 때문입니다. 이때는 로그에서 나온 접미사를 일시적으로 직접 적고, 후속 갱신 때 세트 쪽으로 합류하는 접근이 안전합니다.

⑥ 규칙 예시: 상점·배포·계정을 나누기

아래는 구조 설명용 예시입니다. PROXY_JP·PROXY_NA 등은 실제 프로필의 proxy-groups 이름으로 바꾸고, 도메인은 본인 로그 기반으로 수정하세요.

# Example only — replace proxy group names and domains from your Switch traffic logs
rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,accounts.nintendo.com,PROXY_ACCOUNT
  - DOMAIN-SUFFIX,nintendo.com,PROXY_ESHOP
  - DOMAIN-SUFFIX,nintendo.net,PROXY_CDN
  - DOMAIN-SUFFIX,nintendo.co.jp,PROXY_ESHOP
  - GEOIP,KR,DIRECT
  - MATCH,DIRECT

마지막 MATCH는 예시입니다. 실제로는 구독 규칙 세트의 기본 정책과 합치되게 조정하고, 집 LAN을 직결로 두고 싶다면 사설 대역·국내 ASN 관련 예외를 앞에 두는 편이 자연스럽습니다. 온라인 플레이가 특정 IP 대역으로 나가는 경우에는 IP-CIDR 규칙이 필요할 수 있으나, 대역이 바뀌면 따라가야 하므로 우선 도메인 로그로 좁힌 뒤 보강하는 순서를 권장합니다.

⑦ 노드 선택: 일본·북미 엣지와의 관계

eShop·대용량 패치는 왕복 지연뿐 아니라 TCP 윈도우·대역폭 안정성이 함께 보입니다. Nintendo Switch 2가 같은 해에 판매되면 트래픽이 몰리며 일시적으로 엣지 혼잡이 커질 수 있어, 노드 이름만 보고 고르기보다 동일한 다운로드를 여러 번 시도하며 손실률·지터를 비교하는 편이 낫습니다.

url-test·fallback 그룹에 동일 지역 후보를 넣고 자동 선택하게 두는 패턴이 흔합니다. 다만 자동 측정은 ICMP에 가까운 경로를 볼 때가 있어, 실제 HTTPS·대용량과 항상 일치하지는 않습니다. 그래서 최종 판단은 한 번의 실패/성공이 아니라, 같은 콘텐츠를 같은 시간대에 재시도했을 때의 로그와 전송률을 함께 봐야 합니다. 상업용 단일 VPN 터널과의 차이는 Clash와 VPN의 차이에서 정리할 수 있습니다.

⑧ 게이트웨이·LAN 프록시에서 콘솔만 묶는 실무 팁

PC에는 시스템 프록시를 쉽게 줄 수 있지만, 콘솔은 기본적으로 HTTP 프록시 UI가 제한적입니다. 그래서 (1) 공유기 전체가 투명 프록시·TUN 게이트웨이를 타게 하거나, (2) PC를 이중 NAT가 아닌 DMZ·정적 경로로 맞추거나, (3) 스위치·AP에서 MAC별로 다른 게이트웨이를 주는 식으로 나눕니다. 여기서 (1)은 집 전체 트래픽이 한 코어를 지나가므로, 국내 은행·OTT가 섞이지 않게 GEOIP·DOMAIN 예외를 앞에 두는 것이 중요합니다.

수동으로 DNS만 바꿔 보는 실험도 도움이 됩니다. 단, 부모 공유기가 DHCP로 특정 DNS를 밀어 넣으면 콘솔 설정과 충돌할 수 있으니, 실험 전후로 어떤 서버가 실제로 쓰였는지 확인하세요. 가능하면 실험 구간을 짧게 잡고, 약관상 허용된 네트워크 범위 안에서만 조정합니다.

⑨ 권장 실측 순서(체크리스트)

  1. 전제 정리: 다른 상용 VPN·브라우저 확장을 끄고, 동일 공유기에 붙은 다른 기기의 대용량 다운로드를 잠시 줄여 변수를 줄입니다.
  2. 증상 고정: eShop·펌웨어·특정 게임 온라인 중 어디에서 끊기는지 한 번에 한 시나리오만 재현합니다.
  3. 로그 수집: Clash 연결 로그에 찍힌 목적지와 적중한 규칙 이름을 메모합니다. DOMAIN-SUFFIX 후보를 여기서 뽑습니다.
  4. DNS 정렬: fake-ip·DoH·상위 DHCP DNS를 순서대로 점검해 규칙과 해석 경로가 같게 맞는지 봅니다.
  5. 규칙 삽입: 사용자 규칙을 구독 세트보다 앞에 두고, 지역별 프록시 그룹을 나눕니다.
  6. 노드 비교: 같은 다운로드를 같은 시간대에 반복해 전송률과 재현성을 비교합니다.

이 순서는 라이브 스포츠·대형 패치 글에서 반복해 온 「로그 우선」 접근과 같으며, 대상만 Nintendo Switch 2·eShop·닌텐도 CDN으로 바뀐 것입니다.

⑩ 자주 묻는 질문

eShop만 느리고 다른 게임 온라인은 괜찮아요.

상점·결제·메타데이터 경로와 실제 바이너리 CDN이 다른 규칙에 걸렸을 가능성이 큽니다. 연결 로그에서 두 묶음이 서로 다른 프록시 그룹으로 나가는지 확인하고 접미사를 분리하세요.

펌웨어는 되는데 새 본편 다운로드만 0%예요.

대역폭이 큰 호스트가 규칙에서 빠졌거나 GEOIP·MATCH에 의해 느린 출구로 붙었을 수 있습니다. 잠시 규칙을 단순화해 동일 호스트가 반복되는지부터 보는 것이 빠릅니다.

NAT A인데도 매치만 끊겨요.

NAT 등급은 충분해도 라우터 단에서 UDP·세션 타임아웃이 짧거나, 이중 NAT가 숨어 있으면 증상이 남을 수 있습니다. 프록시 경로가 UDP를 어떻게 다루는지도 제품마다 달라, 규칙·코어 옵션을 함께 봐야 합니다.

⑪ 정리

Nintendo Switch 2 시대의 eShop·온라인 플레이 이슈는 단일 「빠른 노드」로 끝나지 않고, 닌텐도 CDN·계정·세션 호스트가 Clash 분류 규칙에서 어디로 보내지느냐에 크게 좌우됩니다. PC 스팀·에픽 글과 비교하면, 콘솔은 관측 도구가 제한적이므로 게이트웨이 로그와 반복 재현이 더 중요합니다. DNS·fake-ip·RULE-SET 순서를 한 세트로 맞춘 뒤 노드 선택을 비교하면, 증상이 통신사 혼잡인지 설정 문제인지 가늠하기 쉬워집니다.

클라이언트 설치·업데이트는 GitHub 릴리스만 보기보다 다운로드 페이지입문 튜토리얼을 함께 보는 편이 덜 헷갈립니다. 규칙형 Clash는 가정 LAN·개발 PC·콘솔을 한 관문에서 나눠 보낼 수 있어 장기적으로 유지 보수가 쉬운 경우가 많습니다. → Clash를 무료로 내려받고, Switch 2·eShop·온라인에 맞춰 닌텐도 도메인 분류와 DNS를 점검해 보세요.