1. 증상: 모두 "배틀넷이 안 된다"로 보이지만 징후는 다릅니다

많은 사용자는 한꺼번에 "클라이언트가 켜지지 않는다"고 말하지만, 실제로는 단계가 갈립니다. 첫째, 메인 윈도우는 뜨는데 로그인 화면만 스피너로 남는 경우입니다. 둘째, 로그인은 끝났다고 뜨는데 상점·뉴스가 비고 배너가 로드되지 않는 경우입니다. 셋째, 업데이트·게임 다운로드는 진행률·속도는 보이는데 0% 근처에서 사실상 멈추거나, "최적화"·"초기화" 문구 뒤에 아무것도 오르지 않는 경우입니다. 넷째, Agent(백그라운드 프로세스)는 붙는데 런처 UI만 느리게 뜨는 경우입니다. 어떤 호스트 뭉치가 Clash 규칙과 어긋났는지에 따라 느껴지는 장면이 달라지므로, 먼저 "어느 화면이 막혔는지"를 짧게 메모한 뒤 연결 로그로 그때 뜨는 도메인을 캡처하는 것이 이후 Blizzard·CDN 분기를 안전하게 잡는 첫걸음입니다.

구독·프로필이 아직 흔들릴 수 있다면 구독 가져오기로 기본 연결을 먼저 안정시킨 뒤 이 문서의 분류 절차로 넘어오는 편이 좋습니다. 일반 연결·포트·규칙 점검은 트러블슈팅 가이드를, 시스템 터널 쪽은 TUN 모드 문서를 함께 두면 맥락이 잡힙니다.

2. Battle.net/Blizzard 트래픽이 한 줄로 "전부 PROXY"로 잘 안 쌓이는 이유

배틀넷 생태는 단일 *.battle.net 만으로 끝나지 않는 경우가 많습니다. 계정·인증, 웹뷰성 UI, CDN 엣지(지역·ISP·캐시), 게임/패치 본딩이 서로 다른 접미사를 쓰고, HTTP·TLS 연결이 동시에 수십 갈래로 퍼질 수 있습니다. Windows는 일부 흐름이 WinINet·다른 런타임에 나뉘어, "브라우저만 되는데 배틀넷만 이상" 같은 패턴도 흔합니다. 반대로, 공급자 규칙에 GEOIP,CN,DIRECT 나 광범위 DOMAIN 덮어쓰기가 섞이면, 의도는 해외 노드인데 특정 Blizzard 호스트만 국내 직접·혼재로 빠지면서 TLS·세션이 끊기는 일도 생깁니다. 그래서 "유명 도메인 리스트"를 그대로 붙여 넣는 것보다, 본인 PC에서 실시간으로 찍힌 이름을 Clash 규칙 상단에 수집해 가며 좁혀 가는 쪽이 재발이 적습니다. 동일한 "게임 런처" 주제이어도 Epic·Steam 과 실제 호스트 집합이 다르므로, 글마다 끌어다 쓰기보다는 로그에 기대는 편이 낫습니다.

3. 권장 점검 순서 (한 번에 이것만)

  1. Clash가 켜져 있고, 시스템 프록시인지 TUN·가상 어댑터인지, 혹은 둘 다인지 먼저 기록합니다.
  2. 런처를 완전히 끄고(트레이 포함), 배틀넷을 다시 켜며 실시간 연결 목록에 battle·blizzard·akamai·cloudfront·게임 퍼블리셔 접미사가 어떤 정책으로 잡히는지 확인합니다. 실패(타임아웃·리셋) 행에 나온 도메인에 우선순위를 둡니다.
  3. fake-ip·상위 DNS·nameserver-policy 구성이 규칙 판정과 맞는지, 해석 캐시가 흔들리지 않는지 점검합니다.
  4. 이미 있는 공급자 규칙(GEOIP, 대륙, DIRECT)과 로컬 Clash 규칙의 순서·중복·예외를 정리한 뒤, 부족한 Blizzard·CDN 접미사를 DOMAIN-SUFFIX 등으로 올립니다.
  5. 지터·손실이 큰 노드는 대용량 패치에서 끊김의 직접 원인이 되므로, 규칙이 맞는가를 확인한 뒤 회선을 바꾸고 자동 전환 민감도는 너무 공격적이지 않게 둡니다.

4. Windows: 런처·Agent·게임이 시스템 프록시를 항상 타지 않을 수 있음

일부 배틀넷 구성요소는 OS가 제공하는 시스템 프록시를 따르지만, 다른 모듈은 직접 DIRECT로 남을 수 있어, "브라우저와 동일한 출구"가 자동으로 보장되지는 않습니다. 이 경우 TUN이나 동등한 전역 캡처 층에서 흐름을 한 묶음으로 보내는 시도가 효과가 있는 경우가 많습니다. 다만 별도 VPN·필터 드라이버·보안 제품이 동시에 올라가 있으면 어댑터 우선순위가 꼬여, Battle.net만 죽고 다른 앱은 되는 "특이 케이스"가 납니다. 이때는 Clash 외 계층을 먼저 정리한 뒤 다시 업데이트·로그인을 시험하는 것이 낫습니다. Microsoft Store UWP·루프백 이슈가 겹칠 수 있는 PC는 UWP·스토어 문서를 함께 참고하세요. 방화벽/백신이 Agent·런처 실행 파일의 아웃바운드를 잘라도 동일한 스피너가 나올 수 있으니, 프록시 이전에 OS 측 차단도 한 번씩 훑습니다.

5. DNS·fake-ip: 판정과 실제 목적지가 어긋나면 "영원한 로딩"처럼 보입니다

fake-ip 는 체감을 줄이는 데 도움이 될 수 있지만, Blizzard·CDN 처럼 엣지가 서브도메인마다 갈리는 흐름에서는 해석·정책·실제 연결이 틀어질 때 UI 가 스피너로만 남는 경우가 있습니다. 핵심 배틀넷·공식 접미사에 대해 일관되게 DNS 를 밟히도록 상위 리졸버를 정하고, 필요하면 Mihomo 쪽 nameserver-policy (필드명은 코어·버전에 따름)에 블록을 둡니다. 규칙을 손댄 뒤에는 Windows DNS 캐시를 비우고, 런처를 완전히 종료했다가 열어 이전 세션 흔적이 남지 않게 하면 판독이 쉬워집니다. 이미 비슷한 "웹+CDN 갈라짐"을 다룬 글은 많지만(예: 스팀 다운로드·CDN), Steam 과는 퍼블릭 도메인 풀이 다르므로, 반드시 본인 로그를 기준으로 잡는 것이 안전합니다.

6. 연결 로그로 호스트를 모을 때

인터넷에 떠돌이는 "완성 Blizzard 목록"은 배포 시점·지역·ISP·클라이언트 버전에 따라 빠르게 달라질 수 있어, 이 글은 고정 목록 암기보다 세션 기준 수집을 권장합니다. Clash Verge Rev 등 GUI 의 실시간 연결을 연 상태에서 로그인·스토어·업데이트·게임 기동·패치를 차례대로 누릅니다. battle.net·blizzard.com·battlenet 계열, 이미지·JSON 을 끌어오는 CDN 후보(예: 로그에 보이는 대형 CDN 접미사, 지역·에지 호스트)를 따로 모읍니다. 다운로드가 0% 근처에 붙잡혀 있을 때 뜨는 대용량 호스트·실패 행이 특히 중요합니다. 실패·리다이렉트가 반복되는 도메인DOMAIN-SUFFIX 로 올릴지, 보다 짧은 DOMAIN 을 쓸지는 로그와 프라이버시·오탐 범위의 균형을 보고 결정하세요. Clash Verge Rev 의 연결·규칙 UI 흐름이 익숙해지면 재현과 수정이 훨씬 빨라집니다.

7. 규칙에 올리기 전에 표로 훑는 체크리스트

아래는 사고의 틀일 뿐, 실제 이름·개수는 반드시 연결 로그로 검증해야 합니다.

구분로그에 보이기 쉬운 축메모
계정·인증·APIbattle.net·blizzard.com 하위다른 Web 의 로그인과 겹칠 수 있으니, 앱·브라우저를 번갈아 켤 때 비교합니다.
런처 UI·뉴스웹뷰·API 혼재콘솔/탭이 비면 정적·API 어느 쪽이 DIRECT 인지 봅니다.
CDN·정적 자산지역/벤더별 접미사범위가 너무 넓은 DOMAIN-SUFFIX 는 다른 서비스와 충돌할 수 있어 좁힐 수록 안전합니다.
패치·게임 다운로드대용량·장시간 연결노드 품질·MTU·손실과 함께 봅니다.

8. rules 예시 (정책 그룹 이름·순서는 본인 프로필에 맞게)

필드 문법·들여쓰기·프로필 머지 방식은 사용 중인 Mihomo / Clash 빌드에 따릅니다. 아래는 출발용 예시뿐이며, 실제 목록은 로그·계정·지역·클라이언트에 맞게 덮어써야 합니다.

# Example only — replace PROXY with your policy group; verify domains in logs
rules:
  - DOMAIN-SUFFIX,battle.net,PROXY
  - DOMAIN-SUFFIX,battlenet.com,PROXY
  - DOMAIN-SUFFIX,blizzard.com,PROXY
  - DOMAIN-SUFFIX,akamai.net,PROXY

akamai.net 등 광접미사는 Steam·다른 게임·웹에도 쓰일 수 있으니, Clash 로그에서 배틀넷 세션에 실제로 붙는 호스트를 확인한 뒤 필요한 만큼만 DOMAIN 수준으로 좁혀 쓰는 편이 안전합니다. DOMAIN-KEYWORD 는 편하지만 오탐이 커질 수 있으니, 짧은 키워드만 무분별하게 늘리지 않는 것이 좋습니다. 공급자 파일 맨 뒤에 있는 광범위 규칙이 로컬 규칙을 잠식하지 않는지, 정기적으로 "내가 넣은 Blizzard 블록"이 그대로 앞에 있는지 확인하세요.

9. GEOIP·대륙·국내 직결 규칙과의 충돌

일부 공항·공용 구독은 GEOIP,CN,DIRECT 같은 광범위 규칙을 앞이나 뒤에 섞어 둡니다. CDN 엣지나 캐시 도메인이 의도치 않게 DIRECT 로만 나가면, 나머지 인증·API 만 해외 노드에 붙는 식의 불일치가 생겨, 인증·콘텐츠가 서로 엇갈릴 수 있습니다. 이럴 때는 Battle.net·Blizzard 관련 블록을 로컬 규칙 상단에 고정하거나, 충돌하는 구독 룰 뒤에 덮어쓰기가 먹는지(중복·우선순위)를 다시 봅니다. 동일 Windows 머신에서 다른 런처 다운로드 글(Epic 등)을 참고하더라도, GEOIP·정책이 같다고 도메인 풀까지 같다고 가정하면 안 됩니다.

10. Clash가 아닌 쪽: 캐시·권한·Blizzard 쪽 안내(요약)

프록시·분류 이전에, Blizzard 공식 배틀넷 지원 문서에 나오는 "런처 복구", 강제 로그아웃, 캐시/구성재설정(제품·버전마다 다름)은 네트워크와 무관하게 증상을 흉내 낼 수 있습니다. 본문은 Clash·Mihomo 관점에만 머물며, 게임·계정·이용약관·지역·제재와 관련한 동작 취의의 세부는 공식 가이드와 Windows·보안·회사 IT 정책을 함께 따르는 것이 좋습니다. 오픈소스 Clash / Mihomo·GUI 저장소·이슈 트래커는 "신뢰·빌드" 확인용으로만 언급하며, 설치 파일의 주된 받기 경로는 사이트 다운로드 쪽이 일관됩니다(오픈소스 저장소의 릴리스는 "소스/검증"용으로 읽는 편이 무난합니다).

11. 정리: 로그·DNS·TUN·규칙 순을 한 층씩

Windows 배틀넷에서 로그인 스피너·업데이트·초기화 정체·Blizzard CDN 누락은, 단일 체크박스가 아니라 Clash 모드·DNS·fake-ip·규칙 순서·노드 품질이 겹친 결과인 경우가 많습니다. 연결 로그로 실제 도메인을 모으고, Blizzard·배틀넷 관련 호스트를 한 정책으로 묶은 뒤, GEOIP 등과의 충돌을 풀어 가면 "일부 화면만 느리다"는 증상을 빠르게 좁힐 수 있습니다. 비슷한 범용 프록시 도구와 달리, 구독·분류·연결 기록·프로필 전환이 한 GUI에 모여 있으면 Battle.net 만 반복 시험하기도 쉬워집니다. → Clash를 무료로 내려받아, 배틀넷 세션이 기대한 출구로 이어지는지 함께 점검해 보세요