왜 Steam은 「한 앱」인데 증상이 갈라지나요?

Steam 데스크톱 클라이언트는 화면 하나로 보이지만, 실제로는 상점 페이지, 커뮤니티·프로필·창작마당, 게임 파일·패치 다운로드가 서로 다른 호스트와 CDN으로 traffic을 나눕니다. 네트워크가 한쪽으로만 막히거나 지연되면 사용자 입장에서는 「Steam이 안 된다」로 뭉뚱그려지지만, 로그를 보면 도메인 단위로 성공·실패가 갈리는 경우가 많습니다.

특히 매년 봄 세일처럼 프로모션 페이지와 트래픽이 몰리는 시기에는 DNS 캐시·지역 CDN·혼잡한 회선이 겹치기 쉽습니다. 이때 필요한 것은 모든 것을 한 그룹에 몰아넣는 것이 아니라, Clash 분류로 목적지를 읽고 정책 그룹별로 출구를 고르는 것입니다. 브라우저로 store.steampowered.com은 열리는데 클라이언트 상점만 하얗게 남는다면, 앱이 다른 이름으로 붙거나 시스템 프록시를 타지 않는 경로가 섞였을 가능성을 의심합니다.

증상을 세 가지로 나누면 원인이 빨라집니다

상점·카탈로그만 느리거나 열리지 않음

HTML·이미지·스크립트가 상점 전용 호스트에 모여 있는 편입니다. 일부 규칙 세트에서 이 구간만 DIRECT로 새거나, 반대로 해외 노드 대역이 막혀 있으면 로딩이 멈춘 것처럼 보입니다. Steam 상점이 안 열린다고 느낄 때는 먼저 연결 로그에서 실제로 붙는 이름을 확인하는 것이 안전합니다.

커뮤니티·창작마당·토론만 실패

Steam 커뮤니티는 상점과 다른 도메인 트리를 쓰는 경우가 많습니다. 상점은 정상인데 프로필·스크린샷·모드 페이지만 비어 있으면, 커뮤니티 구간만 다른 정책으로 보내야 할 신호입니다. 창작마당 미리보기 이미지가 깨지는 패턴도 같은 계열로 자주 묶입니다.

페이지는 되는데 다운로드·압축 해제만 극도로 느림

이 경우는 「상점이 안 열린다」와는 결이 다릅니다. 게임 본편·패치는 Steam CDN과 캐시 서버 쪽 대역을 많이 쓰므로, 프록시 노드의 대역·지연뿐 아니라 어느 POP으로 붙었는지에 따라 체감이 크게 달라집니다. 규칙으로 출구를 바꿔도 대역이 좁은 노드면 여전히 느릴 수 있으니, 그룹 안에서 노드를 바꿔 대조하는 단계가 필요합니다.

💡
다른 글과의 역할 분리 같은 Wi-Fi에서만 이상하면 LAN 프록시 가이드, 터미널·런처까지 한 번에 묶으려면 TUN 모드를 함께 보세요. 본문은 Steam 호스트 분리와 분류 규칙에 초점을 둡니다.

정책 그룹 설계: 최소한의 나누기

실무에서는 처음부터 세분화하기보다, 아래처럼 두 단계를 추천합니다. 첫째, STEAM 하나로 묶어 문제가 재현되는지 확인합니다. 둘째, 로그에 이름이 명확히 갈리면 STEAM-STORE와 STEAM-COMMUNITY처럼 쪼갭니다. 다운로드만 따로 조정하고 싶다면 STEAM-CDN 같은 셀렉터를 추가해 브라우징용 노드와 대용량 전송용 노드를 분리할 수 있습니다.

자동 선택(URL-Test)을 쓰더라도, 세일 기간에는 노드가 잦게 바뀌며 세션이 끊겨 체감이 나빠질 수 있습니다. 상점·커뮤니티처럼 페이지를 오래 띄워 두는 용도는 Selector로 안정적인 한두 노드를 고정하고, 다운로드만 별도 그룹에서 대역이 넉넉한 출구를 고르는 식이 무난합니다.

규칙에 넣기 전에: 자주 등장하는 이름 계열

버전·지역·캐시에 따라 실제 호스트는 달라질 수 있습니다. 아래는 출발점으로 쓰는 예시이며, 최종 목록은 항상 연결 로그의 목적지를 기준으로 좁혀야 합니다.

  • 상점·웹: steampowered.com, store.steampowered.com 등
  • 커뮤니티: steamcommunity.com 및 하위 경로
  • 콘텐츠·CDN: 클라이언트가 붙는 파일·이미지 호스트(환경마다 상이)

IP만 보이는 연결이 섞이면 DOMAIN만으로는 부족할 수 있습니다. 이때는 로그로 규칙 적중을 분해하는 절차에서처럼, 반복되는 대역을 IP-CIDR나 Rule Provider로 보강하는 편이 빠릅니다.

YAML 골격 예시: STEAM 그룹과 DOMAIN 초안

아래는 샘플입니다. PROXY 자리에는 실제 구독의 정책 그룹 이름을 넣고, rules:는 기존 설정과 병합할 때 지나치게 넓은 GEOIP·국내 DIRECT보다 위에 두는 것이 핵심입니다. 이름은 프로필 안에서만 일치하면 됩니다.

proxy-groups:
  - name: STEAM
    type: select
    proxies:
      - PROXY
      - DIRECT
  - name: STEAM-CDN
    type: select
    proxies:
      - PROXY
      - DIRECT

rules:
  - DOMAIN-SUFFIX,steampowered.com,STEAM
  - DOMAIN-SUFFIX,steamcommunity.com,STEAM
  - DOMAIN-SUFFIX,steamusercontent.com,STEAM
  # Optional: send large downloads to a different exit
  # - DOMAIN-KEYWORD,steamcontent,STEAM-CDN
  # Refine with connection logs; avoid over-broad DOMAIN-KEYWORD

운영 포인트는 세 가지입니다. 첫째, STEAM에 DIRECT를 남겨 두면 노드 의심 시 즉시 대조할 수 있습니다. 둘째, 원격 Rule Provider가 이미 「게임」 묶음을 넣었다면 병합 후 최종 순서에서 로컬 줄이 먹히는지 확인합니다. 셋째, DOMAIN-KEYWORD는 범위가 넓어 오탐이 나기 쉬우니, 로그로 호스트를 확인한 뒤 DOMAIN-SUFFIX로 정리하는 편이 안전합니다.

스플릿 라우팅의 큰 틀은 분류 규칙 최적화 튜토리얼과 같이 읽으면, Steam 구간을 어디에 끼워 넣을지 감이 잡힙니다.

규칙 순서: 넓은 직결이 앞서면 Steam이 갈라집니다

앞쪽에 거대한 GEOIP나 「특정 국가는 전부 DIRECT」 같은 규칙이 있고, Steam 관련 DOMAIN이 뒤에만 있으면 실제 매칭은 DIRECT가 이깁니다. 사용자는 YAML에 프록시를 썼다고 기억하지만, 로그의 최종 정책이 다르게 찍히는 전형적인 패턴입니다. 해결책은 명시적인 DOMAIN·RULE-SET을 앞으로 당기고, 범용 규칙은 뒤에서 받는 구조로 재정렬하는 것입니다.

구독에서 내려온 원격 규칙과 로컬 규칙이 겹칠 때도 마찬가지입니다. 병합 정책을 완전히 외우지 못해도, 연결 로그에 표시된 매칭 줄을 기준으로 역추적하면 됩니다.

DNS와 fake-ip: 이름이 갈리면 규칙도 갈립니다

fake-ip는 규칙 매칭과 맞추기 쉽다는 장점이 있고, redir-host 계열은 실제 IP를 더 직접 다루는 편이라 디버깅이 쉬울 때가 있습니다. 중요한 것은 모드 이름 자체가 아니라 DNS 질의가 Clash 밖으로 새지 않는지, TUN·시스템 프록시·클라이언트 자체 설정이 한 흐름인지입니다. 한쪽만 맞아도 「상점만 간헐적으로 실패」 같은 증상이 남을 수 있습니다.

DNS 항목을 바꾼 뒤에는 코어 재시작과 OS DNS 캐시 비우기까지 한 세트로 보는 것이 좋습니다. Windows에서는 이전 결과가 남아 설정을 고쳐도 예전 증상이 반복되는 경우가 있습니다.

점검 순서: 봄 세일 전후에 바로 쓰는 체크리스트

  1. 연결 로그를 켠 채 Steam에서 문제를 재현하고, 첫 실패 호스트와 매칭된 정책을 적습니다.
  2. DIRECT로 나가면 rules 전체에서 해당 문자열을 검색해, 더 위쪽 규칙에 가로막힘이 없는지 봅니다.
  3. STEAM 계열 그룹을 단일 안정 노드로 고정한 뒤, 상점·커뮤니티·다운로드를 각각 짧게 시험합니다.
  4. DNS 모드·nameserver·fallback을 점검하고, 변경 후 코어와 OS 캐시를 갱신합니다.
  5. 클라이언트가 시스템 프록시를 무시하는지 의심되면 TUN으로 동일 앱이 같은 규칙을 타는지 확인합니다.
⚠️
준수 사항 거주 지역의 법령과 서비스 이용약관을 지켜 주세요. 본문은 합법적으로 접근 가능한 네트워크에서 기술적 경로를 맞추는 방법을 설명합니다.

정리: Steam은 호스트가 여럿인 하나의 클라이언트

봄 세일처럼 트래픽이 몰릴 때 Steam이 안 열린다는 느낌은, 종종 단일 원인이 아니라 상점·커뮤니티·CDN 중 일부만 막히거나 느려진 결과입니다. Clash에서는 이를 분류 규칙으로 드러내고, 정책 그룹으로 출구를 나누면 같은 구독 안에서도 체감이 달라집니다. 노드만 바꿔 반복하기 전에 로그로 실제 매칭을 확인하면 시행착오 시간을 크게 줄일 수 있습니다.

문서 전체 구조는 문서 센터에서 함께 확인할 수 있습니다. 클라이언트 설치가 아직이라면 다운로드 페이지에서 패키지를 고르고, 구독은 구독 링크 가이드로 연결한 뒤 이 글의 규칙만 얹으면 됩니다. 환경을 맞춘 다음 → Clash를 무료로 내려받아 Steam용 분류와 DNS를 직접 조합해 보세요.