웹 플레이어만 멈춘 것처럼 보이는 이유: 페이지 CDN과 오디오 CDN이 갈라질 때

브라우저에서 Spotify를 열면 HTML·스크립트·이미지는 한 묶음의 호스트에서 오고, 실제 스트림은 오디오 전용 CDN 접미사로 이어지는 경우가 많습니다. 사용자 입장에서는 «전역 프록시를 켰는데도 왜 로딩만 도나»처럼 보이지만, 코어 입장에서는 open.spotify.com만 프록시를 타고 spotifycdn.com·scdn.co 계열이 DIRECT나 다른 리전 노드로 새는 상황일 수 있습니다. 이때 지연·타임아웃·DRM 초기화 실패가 한꺼번에 겹치면 UI는 살아 있는데 재생만 진행되지 않습니다.

또 하나의 축은 DNS 유출입니다. TCP 연결 전에 운영체제나 브라우저가 ISP DNS·공유기 DNS로 이름을 먼저 물어보면, 응답이 기대 리전과 다르게 떨어져 규칙 매칭과 실제 경로가 어긋납니다. Clash는 dns 섹션과 TUN·시스템 프록시 설정으로 이 경로를 정리하려 하지만, 브라우저 보안 DNS(DoH)·분 앱 예외·IPv6 우회가 끼면 여전히 재현이 어렵습니다.

OTT 글과 비교해서 읽기 Netflix 지역 분기Disney+ DNS 유출 점검 글은 카탈로그·지역 메시지 중심이라면, Spotify 웹은 세션·CDN 라인업이 더 잘게 쪼개진다는 점에서 «로그에 찍힌 호스트 묶음을 한 번에 스트리밍 그룹으로 올리는 것»에 비중을 두었습니다.

실측 1단계: Rule 모드 로그로 호스트와 정책 그룹 이름을 고정했는가?

먼저 Clash를 Rule 모드로 두고, 크롬·엣지·사파리 등에서 웹 플레이어를 연 직후 코어 로그를 봅니다. 여기서 확인할 것은 단순히 «연결됐다»가 아니라 어떤 FQDN이 어떤 정책 그룹으로 분류됐는지입니다. spotify.com 한 줄만 스트리밍 그룹에 넣고 나머지가 기본 그룹으로 떨어지면, 증상은 그대로입니다.

로그에 반복되는 접미사를 메모한 뒤, rules에서 해당 DOMAIN-SUFFIX 줄들이 스트리밍 전용 그룹보다 아래에 있지 않은지 확인합니다. 넓은 GEOIP나 파일 말미의 MATCH가 더 위에 있으면 의도와 다른 줄이 먼저 선택됩니다. 라이브·스포츠 CDN을 다룬 월드컵 스트리밍 분기에서도 같은 원리로 «세그먼트 호스트 누락»을 경고했습니다.

실측 2단계: proxy-groups 이름과 rules 인자가 문자 단위로 같은가?

rules 끝에 적힌 그룹 이름은 proxy-groupsname완전히 같아야 합니다. GUI에서 표시 이름만 바꿨는데 YAML에는 옛 문자열이 남아 있으면 해당 규칙이 무시되거나 예상치 못한 기본 그룹으로 붙습니다. 스트리밍용은 url-test가 너무 자주 노드를 바꿔 세션을 끊지 않도록 select로 리전을 고정하는 패턴이 안정적인 경우가 많습니다.

실측 3단계: sniffing·규칙 순서가 목적지를 덮어쓰지 않는가?

일부 프로필에서는 스니핑이 활성화되어 TLS SNI 기준으로 도메인을 다시 매깁니다. 이 동작이 특정 앱에서만 부작용을 낼 때가 있어, 증상이 남으면 스니핑·규칙 순서 글의 체크리스트로 교차 확인합니다. Spotify 웹은 브라우저 스택이라 증상 표현이 세밀하게 갈립니다.

Spotify 관련 DOMAIN-SUFFIX 시작점(개념 스니펫)

아래는 출발점으로 쓰는 예시이며, 실제 환경에서는 로그·Rule Provider 갱신에 맞춰 줄을 더하거나 줄여야 합니다. 호스트는 시기·클라이언트·AB 테스트에 따라 바뀔 수 있습니다.

rules:
  - DOMAIN-SUFFIX,spotify.com,SPOTIFY
  - DOMAIN-SUFFIX,spotifycdn.com,SPOTIFY
  - DOMAIN-SUFFIX,scdn.co,SPOTIFY
  - DOMAIN-SUFFIX,pscdn.co,SPOTIFY
  # 로그에 보이는 wg·audio·akamai 계열 접미사를 이어서 추가

DOMAIN-KEYWORD,spotify처럼 과하게 짧게 쓰면 다른 트래픽까지 같은 그룹으로 붙을 수 있어, 가능하면 접미사 단위와 검증된 RULE-SET을 우선합니다.

proxy-groups:
  - name: "SPOTIFY"
    type: select
    proxies:
      - "리전고정-A"
      - "리전고정-B"
      - "DIRECT"

구독 번들에 streaming·spotify류 RULE-SET이 포함돼 있다면 중복 줄을 정리하고, 충돌 없는 순서만 유지합니다. 지역 필터가 필요하면 좁은 목적의 GEOIP 줄을 스트리밍 묶음 바로 아래에 두되, 말미의 넓은 GEOIP가 먼저 잡아먹지 않게 배치합니다.

DNS 유출 점검을 깊게 하는 방법

같은 시점에 다음 세 가지를 적어 두세요: (1) 로그의 아웃바운드 이름, (2) 문제 호스트에 응답한 DNS 서버 경로, (3) IPv4만 썼는지 IPv6도 섞였는지. 다음 시도에서 값이 바뀌면 원인 후보가 빠르게 좁혀집니다.

fake-ip 프로필에서는 화면에 보이는 해석 결과와 코어 내부 동작이 다르게 느껴질 수 있습니다. 이때는 fake-ip와 redir-host 비교 글을 따라 dns.enhanced-mode와 nameserver 폴백을 규칙과 같은 날 점검합니다.

IPv6가 활성화되어 있고 특정 호스트가 IPv6로만 나가면, IPv4 프록시만 맞춘 구성과 결과가 달라집니다. 일시적으로 IPv6를 끄거나 TUN·라우팅으로 스트리밍 트래픽을 한 스택으로 모으는 방식이 현장에서 자주 쓰입니다.

브라우저 보안 DNS 크롬·엣지의 «보안 DNS»가 켜져 있으면 Clash 밖으로 질의가 새어 나갈 수 있습니다. Spotify 웹 문제가 특정 브라우저에서만 날 때는 이 설정부터 끄고 재측정합니다.

Open Spotify 링크·로그인·Premium 이슈를 네트워크 관점에서 좁히기

Open Spotify 버튼과 트랙 공유 링크는 랜딩 페이지를 빠르게 열어 주지만, 실제 재생은 별도 CDN 라인으로 이어집니다. 링크는 열리는데 재생만 안 되면 앞서 말한 오디오 CDN 규칙 누락을 우선 의심합니다.

Premium 상태에서만 특정 기능이 막히거나 로그인 세션이 자주 끊기면, 계정·결제·가족 플랜 정책은 공식 안내를 따르고, 네트워크 측에서는 세션 쿠키·타사 로그인·API 호스트가 한 출구로 고정됐는지 로그로 확인합니다. «한 브라우저 프로필만 실패» 패턴은 확장 프로그램이 상위 프록시를 가로채는 경우도 많습니다.

회사망·교육망에서는 HTTPS 차단·MITM이 TLS 레벨에서 실패를 내기도 합니다. 지역 메시지와 별개로 TLS handshake failed가 보이면 TLS 핸드셰이크 5단계 글의 순서로 시계·체인·SNI를 점검합니다. DNS·분기 체크와 직교하는 축입니다.

증상별로 좁히기

UI는 살아 있는데 재생 막대만 짧게 튄다

버퍼링과 비슷하지만 규칙 문제일 때는 특정 CDN 줄만 다른 노드로 새는 경우가 많습니다. 재생 직전 로그의 FQDN을 잡아 스트리밍 그룹으로 올립니다.

모바일 브라우저만 실패한다

Android의 Private DNS·셀룰러 프로필이 Clash와 따로 동작할 수 있습니다. 앱 환경 전체를 다룬 Android DNS·구독 타임아웃 글 순서를 참고해 단말 설정과 코어 DNS를 맞춥니다.

데스크톱 앱은 정상인데 웹만 로그인이 반복된다

앱은 시스템 프록시를 따르고 웹은 확장·프로필별 예외를 탈 수 있습니다. 시크릿 창에서 확장을 모두 끈 뒤 같은 프로필로 재현되는지 비교합니다.

특정 노드에서만 플레이리스트 메타가 느리다

url-test 그룹이 너무 공격적이면 메타 요청마다 노드가 바뀌어 세션이 흔들립니다. 스트리밍 묶음은 select 고정이 안전한 경우가 많습니다.

TUN·시스템 프록시 선택과의 관계

Windows·macOS에서 TUN과 시스템 프록시를 혼용할 때, 브라우저가 어떤 경로를 타는지가 미묘하게 갈립니다. 전역처럼 보여도 일부 프로세스만 예외면 Spotify 웹만 로딩 문제가 남을 수 있습니다. OS별 차이는 TUN·시스템 프록시 트러블슈팅 글에서 한 번에 정리했습니다.

짧은 Q&A

Q. 구독 링크만 갈아끼우면 Spotify 규칙도 자동으로 생기나요? A. 노드 목록은 바뀌어도 로컬 rules 병합 상태는 그대로입니다. 스트리밍 RULE-SET이 포함돼 있지 않다면 호스트별 줄을 직접 보강해야 합니다.

Q. 같은 노드인데 어제는 됐고 오늘만 웹이 느린 이유는? A. CDN 엣지 교체·DNS 캐시·세션 토큰 만료가 겹칠 수 있습니다. 앱 데이터를 비우고 하드 리프레시한 뒤, 위 실측 순서를 처음부터 다시 밟아 보세요.

Q. 사내 프록시와 Clash를 동시에 쓰면? A. 이중 프록시에서는 출구와 DNS가 어디에 묶이는지 추적이 어렵습니다. 가능하면 한 경로로 단순화하는 편이 재생 안정성에 유리합니다.

마무리

2026년에도 Spotify 웹 플레이어는 링크 공유·브라우저 청취·Premium 관리 때문에 검색량이 큰 주제입니다. «전역 프록시인데도 로딩만 된다»는 말은 종종 페이지와 오디오 CDN의 출구 불일치DNS 유출로 설명됩니다. Netflix·Disney+ 글에서 익힌 원리를 그대로 가져오되, Spotify는 호스트 묶음이 더 잘게 나뉘므로 로그를 한 번 모아 두면 이후 튜닝이 빨라집니다.

장기적으로는 검증된 클라이언트에서 프로필을 고정하고, 구독 갱신과 로컬 규칙 보강만 주기적으로 하는 편이 덜 지칩니다. 전체 YAML 설계는 규칙 분기 완전 가이드를 기준으로 삼으면 됩니다.

시중의 단순 VPN 앱이나 «원클릭 전환만 제공하는» 프록시 도구는 Spotify처럼 호스트가 잘게 갈라진 웹 스트리밍에서 세분 규칙·DNS 체인을 함께 다루기 어렵고, 업데이트가 느리면 새 CDN 접미사가 생길 때마다 사용자가 원인을 찾기까지 시간이 걸립니다. 반면 Clash 계열은 Rule Provider·정책 그룹·DNS 섹션을 한 프로필에서 묶어 다룰 수 있어 같은 증상이라도 재현과 수정이 빠릅니다. ClashNote가 안내하는 클라이언트는 이런 분기 중심 워크플로에 맞춰 선택지를 정리해 두었으니, 위 순서로 프로필을 다듬은 뒤 검증된 실행 파일을 받아 적용해 보시면 브라우저 세션을 반복해서 깨지 않고 Spotify 웹을 쓰기가 한결 수월해집니다.

Clash 무료 다운로드 — 여러 플랫폼용 클라이언트를 한곳에서 받고, 구독 링크와 규칙·DNS를 한 화면에서 다루기 쉬운 구성으로 Spotify 웹 플레이어 분기를 정리해 보세요.

추가 설정이 필요하면 도움말기술 칼럼 목록을 참고해 주세요.