왜 스토어·CDN과 커뮤니티를 한 묶음으로 두면 안 되나요?
플랫폼 클라이언트는 화면 하나지만, 실제 연결은 카탈로그·구매 확인용 호스트, 대용량 패치를 끌어오는 CDN·콘텐츠 서버, 토론·창작마당·모드용 호스트, 친구 목록·채팅 릴레이처럼 역할이 다릅니다. 이 중 일부는 지역에 가까운 저지연 직결이 유리하고, 일부는 특정 지역 노드를 써야만 페이지가 열리거나 반대로 끊기는 경우가 있습니다. Clash에서 GEOIP,CN나 넓은 MATCH가 먼저 걸리면, 의도와 다르게 스토어 트래픽만 국내로 나가거나 커뮤니티만 해외 노드로만 가는 등 한쪽만 맞고 한쪽은 깨지는 패턴이 나옵니다.
스트리밍처럼 «한 서비스 = 비슷한 호스트 묶음»에 가깝게 보이는 사례는 Netflix·지역 스트리밍 분기 가이드에서 다뤘고, 게임 플랫폼은 다운로드 대역·지연·지역 정책이 더 잘게 갈립니다. 그래서 용도별 정책 그룹을 두고 rules에서 도메인 접미사 단위로 먼저 잡는 편이 디버깅에 유리합니다.
Steam: 스토어·CDN·커뮤니티·워크숍이 나뉘는 이유
Steam 클라이언트는 게임 파일을 한 도메인에서만 받지 않습니다. 메타데이터와 구매 흐름은 steampowered.com 계열, 커뮤니티·프로필·토론은 steamcommunity.com, 정적 자산·이미지는 steamstatic.com, 창작마당·창작물 CDN은 steamusercontent.com 등으로 흔히 나뉩니다. 다운로드 자체는 지역·ISP에 따라 Valve·Akamai 등 콘텐츠 배포 호스트로 퍼지므로, «스팀만 프록시»라고 해서 실제 패치 바이트가 가는 연결까지 같은 그룹이라고 가정하면 안 됩니다.
실무에서는 (1) 스토어·인증·카탈로그를 한 정책 그룹, (2) 커뮤니티·워크숍·UGC를 다른 그룹, (3) 필요하면 대용량 다운로드 전용 그룹을 더 두는 식으로 나눕니다. DOMAIN-SUFFIX,steampowered.com·DOMAIN-SUFFIX,steamcommunity.com처럼 접미사를 쓰면 키워드 규칙보다 오탐이 적습니다. DOMAIN-KEYWORD,steam은 편하지만 다른 도메인까지 잡을 수 있어, 가능하면 DOMAIN-SUFFIX와 검증된 RULE-SET을 권장합니다.
다운로드가 «느리다»고 느껴질 때 흔한 원인
노드 품질만의 문제가 아니라, 실제로는 DIRECT로 나가 ISP QoS에 걸리는 경우, 지연 큰 노드로만 CDN이 붙는 경우, IPv6와 IPv4 경로가 갈라지는 경우가 겹칩니다. Clash 로그에서 해당 연결의 규칙 이름·아웃바운드를 보면 «프록시를 켰는데도 DIRECT»인지 «의도한 그룹이 아닌 다른 프록시」인지부터 구분할 수 있습니다.
Epic Games Launcher: 스토어·CDN·온라인 서비스
Epic Games Launcher 역시 로그인·스토어·에픽 온라인 서비스(EOS) 관련 호스트와, 실제 설치 파일을 받는 다운로드 CDN이 분리되는 경우가 많습니다. epicgames.com 접미사만 넓게 잡으면 일부는 잡히지만, 런처가 호출하는 하위 API·에셋·패치 서버가 별 접미사로 나가면 상위 규칙에 먼저 걸려 원하지 않는 DIRECT 또는 반대로 전부 해외로 갈 수 있습니다.
그래서 Epic 쪽도 Steam과 같이 «런처·스토어·계정»과 «대용량 바이너리·패치»를 나눌지, 아니면 한 그룹에 묶되 노드만 저지연·대역폭 위주로 고를지 환경에 따라 선택합니다. 기업망·기숙사처럼 P2P나 특정 포트가 막힌 곳에서는 «느린 다운로드»가 프록시가 아니라 회선 정책일 때도 있으므로, 같은 설정을 가정망에서 재현해 보는 것이 좋습니다.
정책 그룹으로 «게임 CDN」과 «커뮤니티·소셜」 경로 만들기
예시 이름은 자유이나, 의미가 드러나게 GAME-CDN·GAME-SOCIAL처럼 나누면 UI에서도 선택이 쉽습니다. GAME-CDN에는 대역이 넉넉한 노드나 필요 시 DIRECT를 넣고, GAME-SOCIAL에는 웹·커뮤니티가 열리는 지역 노드를 두는 식입니다. url-test로 자동 전환하면 다운로드 세션이 중간에 끊길 수 있어, 스토어·패치에는 select로 고정을 쓰는 사용자도 많습니다.
proxy-groups: - name: "GAME-CDN" type: select proxies: - "대역-우선-노드" - "DIRECT" - name: "GAME-SOCIAL" type: select proxies: - "저지연-노드" - "DIRECT"
그룹 이름은 rules의 세 번째 인자와 정확히 일치해야 합니다. 오타는 해당 줄이 무시되거나 기동 오류로 이어질 수 있습니다. proxy-groups 유형별 설명은 YAML 규칙 분기 가이드의 proxy-groups 절을 참고하세요.
rules 예시: DOMAIN-SUFFIX로 축을 나누기
아래는 개념을 보여 주는 최소 예시입니다. 실제 구독 RULE-SET과 병합할 때는 규칙 순서(위에서 아래로 첫 매칭만 적용)를 반드시 함께 봐야 합니다. 넓은 GEOIP·MATCH가 위에 있으면 게임용 예외 줄이 도달하지 못할 수 있습니다.
rules: # Steam: community / workshop / profiles (example axes) - DOMAIN-SUFFIX,steamcommunity.com,GAME-SOCIAL - DOMAIN-SUFFIX,steamusercontent.com,GAME-CDN - DOMAIN-SUFFIX,steamstatic.com,GAME-SOCIAL # Steam: store / client metadata (example) - DOMAIN-SUFFIX,steampowered.com,GAME-SOCIAL # Epic (example; expand from your logs) - DOMAIN-SUFFIX,epicgames.com,GAME-SOCIAL # ... LAN, GEOIP, MATCH
콘텐츠 서버 호스트명은 환경마다 다르므로, 클라이언트 업데이트 후 로그에 찍힌 실제 도메인을 RULE-SET이나 사용자 규칙에 추가하는 방식이 안전합니다. 다운로드 속도 제한처럼 보이는 증상이면, 먼저 해당 TCP 연결이 GAME-CDN인지 DIRECT인지를 확인하세요.
직행·오노드·DNS: 증상별 점검 순서
1) 프록시를 켰는데도 다운로드만 느리다
(1) 코어 로그에서 해당 호스트가 어떤 규칙 줄에 매칭됐는지, (2) 아웃바운드가 DIRECT인지, (3) fake-ip 환경에서 DNS와 규칙이 같은 날짜에 맞는지 확인합니다. 브라우저 확장·다른 VPN과 이중 경로가 겹치면 클라이언트만 예외로 동작하기도 합니다. 데스크톱에서 시스템 프록시와 TUN이 갈리는 경우는 TUN·시스템 프록시 점검 가이드를 참고하세요.
2) 커뮤니티·창작마당만 안 열린다
스토어는 되는데 steamcommunity.com만 실패하면, 해당 접미사가 더 위 규칙에 흡수됐거나, SNI와 다른 이름으로 연결되는 경우를 의심합니다. TLS 핑거프린트까지는 이 글 범위를 넘지만, 최소한 실패한 연결의 목적지 호스트 문자열을 로그에 남겨 목록을 보강합니다.
3) Epic Games Launcher만 로그인·라이브러리가 불안정하다
런처는 백그라운드에서 여러 API를 동시에 호출합니다. 한 호스트만 다른 노드로 가면 세션·토큰 불일치처럼 보일 수 있어, 처음에는 Epic 관련 접미사를 한 그룹에 모아 두고 증상이 사라지는지 본 뒤, 필요할 때만 CDN 축을 쪼개는 순서가 디버깅에 수월합니다.
스트리밍(Netflix) 분기 글과 무엇이 다른가요?
Netflix 가이드는 재생·라이선스·지역 카탈로그에 초점을 맞춘 DOMAIN·GEOIP 패턴이 중심입니다. 반면 Steam·Epic은 대용량 패치와 상호작용형 커뮤니티가 한 앱에 공존하므로, «스트리밍 전용 그룹»과 같은 단일 묶음보다 CDN·소셜 이축을 나누는 사례가 많습니다. 두 글 모두 규칙 순서·DNS·정책 그룹 이름 일치라는 Clash 공통 원리는 같습니다.
마무리
2026년에도 PC 게임 플랫폼은 스토어·CDN·커뮤니티·친구 API가 서로 다른 이름으로 트래픽을 쪼갭니다. Clash에서는 DOMAIN-SUFFIX로 축을 명시하고 정책 그룹으로 노드 선택권을 분리한 뒤, 속도·연결 실패가 남으면 로그로 DIRECT 여부와 매칭된 규칙부터 확인하는 것이 가장 빠릅니다. 호스트 목록은 구독의 RULE-SET과 병합해 유지보수하고, 코어 업데이트 시 미호모 코어 업그레이드 가이드와 맞춰 두면 클라이언트별 차이를 줄일 수 있습니다.
반복되는 수동 편집보다, 한 번 프로필을 검증된 클라이언트에 넣고 로그로 재현하는 편이 장기적으로 덜 지칩니다.