왜 «닌텐도만 프록시» 한 묶음으로 두면 증상이 엇갈리나요?
콘솔 화면에서는 모두 «닌텐도»로 보이지만, 실제 TLS·HTTP 연결은 시스템 업데이트·대용량 다운로드용 CDN, 계정·부모·결제·eShop 카탈로그, 온라인 플레이·보이스·친구처럼 역할이 갈립니다. 한 접미사만 넓게 잡으면 나머지 호스트가 GEOIP나 MATCH에 먼저 흡수되거나, 반대로 다운로드만 느리고 스토어는 안 열리는 식으로 디버깅이 꼬입니다. 특히 리전을 바꿔 구매하거나 다른 국가 카드로 결제하는 흐름은 상점 표시·실제 청구·다운로드 서버가 어긋나면 «구매는 됐는데 받기만 실패»처럼 보이기도 합니다.
PC에서 Clash를 쓰는 사용자 입장에서는 브라우저의 닌텐도 계정 페이지와 공유기 뒤 콘솔의 온라인 세션이 완전히 다른 경로일 수 있다는 점이 핵심입니다. 그래서 «규칙을 잘 썼는데도 NAT가 D다»처럼 느껴지면, 먼저 어떤 기기의 어떤 연결을 로그로 보고 있는지부터 맞춰야 합니다.
Switch 2·닌텐도 네트워크: 펌웨어·eShop·온라인이 나뉘는 이유
Switch 2를 포함한 닌텐도 기기는 백그라운드에서 짧은 상태 동기화와 긴 시간 대역을 쓰는 패치를 동시에 돌립니다. 전자는 저지연·안정적인 TCP가 중요하고, 후자는 대역·캐시 거리가 중요합니다. 둘을 같은 정책 그룹에 넣고 지연 큰 노드만 고르면 «온라인 로비는 되는데 업데이트만 끊긴다» 같은 패턴이 나올 수 있습니다.
Nintendo eShop은 카탈로그·가격·할인 정보를 보여 주는 호스트와, 실제 게임 파일을 받는 콘텐츠 배포 호스트가 분리되는 경우가 많습니다. 리전을 전환해 다른 상점을 볼 때는 계정 국가·결제 수단·세금 표시가 얽혀, 프록시 노드가 바뀔 때마다 «장바구니만 비정상»처럼 보일 수 있습니다. 그래서 eShop 전용으로 한 지역 노드를 고정해 두고, CDN만 별도 그룹으로 빼는 식의 분리가 디버깅에 유리합니다.
닌텐도 «온라인 플레이»와 NAT 표시
연결 테스트에서 NAT 유형이 나쁘다고 나오는 것은 대개 UDP·P2P 홀펀칭과 공유기 포워딩 문제입니다. Clash가 PC에서 돌아가는 한, 그 설정이 자동으로 콘솔의 UDP 세션까지 동일하게 개선된다고 가정하면 오해입니다. 콘솔이 Clash가 있는 PC를 기본 게이트웨이로 쓰거나, 공유기·OpenWrt 등에서 동일한 분기 정책을 태우지 않는 한, «PC만 프록시» 상태에서는 콘솔 패킷이 그 경로를 지나지 않습니다.
정책 그룹으로 «CDN」「계정·eShop」「온라인·웹」 경로 만들기
이름은 자유지만, 의미가 드러나게 NINTENDO-CDN·NINTENDO-ACCOUNT·NINTENDO-WEB처럼 나누면 UI에서도 선택이 쉽습니다. NINTENDO-CDN에는 대역이 넉넉한 노드나 환경에 따라 DIRECT를, NINTENDO-ACCOUNT에는 eShop·계정 결제에 맞는 고정 리전 노드를, NINTENDO-WEB에는 브라우저에서 여는 지원 페이지용 노드를 둘 수 있습니다. url-test가 자동으로 바뀌면 세션이 끊길 수 있어, 계정·결제 축에는 select 고정을 선호하는 사용자도 많습니다.
proxy-groups: - name: "NINTENDO-CDN" type: select proxies: - "대역-우선-노드" - "DIRECT" - name: "NINTENDO-ACCOUNT" type: select proxies: - "리전-고정-노드" - "DIRECT" - name: "NINTENDO-WEB" type: select proxies: - "저지연-노드" - "DIRECT"
그룹 이름은 rules 세 번째 인자와 정확히 일치해야 합니다. proxy-groups 유형별 설명은 YAML 규칙 분기 가이드의 proxy-groups 절을 참고하세요.
rules 예시: DOMAIN-SUFFIX로 축을 나누기
아래는 개념을 보여 주는 최소 예시입니다. 실제 구독 RULE-SET과 병합할 때는 규칙 순서(위에서 아래로 첫 매칭만 적용)를 함께 봐야 하며, 넓은 GEOIP,CN·MATCH가 위에 있으면 예외 줄이 도달하지 못할 수 있습니다.
rules: # Account / eShop / web (example axes; expand from your logs) - DOMAIN-SUFFIX,nintendo.com,NINTENDO-WEB - DOMAIN-SUFFIX,nintendo.net,NINTENDO-ACCOUNT # JP regional storefront / info (example) - DOMAIN-SUFFIX,nintendo.co.jp,NINTENDO-WEB # Large downloads often hit CDNs; match real hostnames from logs # - DOMAIN-SUFFIX,cdn.example.com,NINTENDO-CDN # ... LAN, GEOIP, MATCH
DOMAIN-KEYWORD,nintendo는 편하지만 오탐이 늘 수 있어, 가능하면 DOMAIN-SUFFIX와 검증된 RULE-SET을 권장합니다. 펌웨어·게임 파일이 전혀 다른 최상위 도메인으로 나가면, 키워드 규칙만으로는 잡히지 않으므로 실패한 연결의 호스트 문자열을 로그에 남겨 목록을 보강하는 방식이 안전합니다.
NAT·게이트웨이: PC Clash와 콘솔을 헷갈리지 않기
Clash 분기는 그 Clash 인스턴스가 처리하는 트래픽에만 적용됩니다. 데스크톱 브라우저로 accounts.nintendo.com을 열 때는 PC의 시스템 프록시·TUN 설정을 따르지만, TV 옆 Switch 2는 공유기 DHCP로 직접 인터넷에 나가는 경우가 대부분입니다. 그 상태에서 «Clash 규칙을 추가했는데도 콘솔 NAT가 그대로»라면, 규칙이 아니라 경로 자체가 다르기 때문인지 먼저 확인해야 합니다.
집 전체를 한 정책으로 묶으려면 공유기 게이트웨이에서 Clash·OpenClash 계열을 쓰거나, PC를 유선 공유·인터넷 연결 공유로 쓰는 등 콘솔의 기본 라우터가 Clash 쪽을 가리키게 만드는 설계가 필요합니다. 이중 NAT(공유기 뒤에 또 공유기)에서는 포트 매핑이 꼬여 온라인 세션만 불안정해지기 쉬우므로, OpenWrt 라우터와 데스크톱 Clash 병행 가이드에서 다룬 것처럼 DHCP 기본 게이트웨이·DNS를 한 번에 정리하는 편이 낫습니다.
증상별 점검 순서: eShop·다운로드·온라인
1) eShop는 되는데 펌웨어·다운로드만 느리거나 끊긴다
코어 로그에서 해당 TCP 연결이 NINTENDO-CDN인지 DIRECT인지, fake-ip 환경에서 DNS 응답과 규칙 매칭이 같은 날짜에 맞는지 확인합니다. IPv6만 직행하고 IPv4만 프록시하는 경우에도 동일 서비스가 다른 경로로 보일 수 있습니다.
2) 스토어·계정 페이지만 오류이고 게임 온라인은 된다
nintendo.com 계열이 더 위 규칙에 흡수됐거나, 브라우저 확장·다른 VPN과 이중 경로가 겹치는 경우를 의심합니다. 결제·부모 통제·이메일 인증이 섞이면 세션 쿠키가 리전과 불일치하는 것처럼 보이기도 하므로, 한 브라우저 프로필·한 노드로 고정해 재현해 보는 것이 좋습니다.
3) 온라인만 끊기고 다운로드는 정상이다
UDP·P2P·NAT 쪽 가능성이 큽니다. PC Clash 규칙과 무관하게 공유기 포트·UPnP·방화벽을 점검하고, 가능하면 이중 NAT 여부를 제거합니다. 동일 증상이면 ISP의 캐리어급 NAT 이슈일 수도 있어, «프록시로 모든 것이 해결된다»는 기대는 내려놓는 편이 맞습니다.
Steam·Epic 분기 글과 무엇이 다른가요?
Steam·Epic 스토어 CDN과 커뮤니티 분기 가이드는 PC 클라이언트 안에서 스토어·CDN·커뮤니티 축을 나누는 데 초점을 맞춥니다. 반면 닌텐도는 콘솔·PC 브라우저·공유기 뒤 기기가 동시에 등장하고, NAT·UDP 이야기가 앞에 나옵니다. 공통점은 규칙 순서·DNS·정책 그룹 이름 일치라는 Clash의 원리입니다. 스트리밍 쪽 패턴은 Netflix·지역 스트리밍 분기 가이드와 비교해 보면, «한 서비스 = 한 그룹»에 가깝게 쓰는 경우와 게임·콘솔처럼 축이 더 잘게 갈리는 경우를 구분하는 데 도움이 됩니다.
마무리
2026년에도 Switch 2·닌텐도 온라인·Nintendo eShop 이슈는 «한 도메인만 잡으면 끝»이 아니라 CDN·계정·온라인 세션이 서로 다른 이름으로 흩어집니다. Clash에서는 DOMAIN-SUFFIX로 축을 명시하고 정책 그룹으로 노드 선택권을 분리한 뒤, 증상이 남으면 로그로 매칭된 규칙과 아웃바운드부터 확인하는 것이 가장 빠릅니다. NAT는 규칙만으로 바뀌지 않을 수 있으니, 콘솔이 실제로 어떤 게이트웨이를 쓰는지부터 맞추세요. 코어·클라이언트 업데이트 시에는 미호모 코어 업그레이드 가이드와 함께 프로필을 점검하면 환경 차이를 줄일 수 있습니다.
반복되는 수동 편집보다, 한 번 검증된 프로필에 넣고 로그로 재현하는 편이 장기적으로 덜 지칩니다.