1. 증상 읽기: 회색 곡과 스킵은 경로가 갈라졌을 때 흔합니다
Spotify 웹 플레이어와 데스크톱·모바일 앱은 실행 직후 카탈로그·인증·메타데이터·오디오 스트림·측정용 비콘 등으로 병렬 요청을 보냅니다. 목록은 뜨는데 특정 트랙만 회색으로 비활성화되거나, 재생 직후 스피너만 도는 패턴은 단순 지연보다 일부 서브도메인만 다른 경로로 나갈 때 자주 보입니다. Clash 연결 목록에서 호스트명과 선택된 정책을 나란히 보면 원인 후보를 빠르게 줄일 수 있습니다. “Spotify 해제”라는 검색어로 접근하는 사용자도 많지만, 실제로는 규칙을 넓게 켜기보다 본인 세션에서 붙는 이름에 맞추는 편이 재현성이 높습니다.
YAML 구조가 아직 낯설다면 구독 가져오기 튜토리얼에서 프로필 흐름을 먼저 잡아 두세요.
2. Spotify 주변 트래픽을 층으로 나누기
실제 호스트는 클라이언트 버전과 CDN 계약에 따라 달라질 수 있으므로 로그에 나온 이름을 정답으로 둡니다. 아래는 규칙을 쓸 때 머릿속에 두기 좋은 역할 구분입니다.
| 층 | 이미지 | 점검 포인트 |
|---|---|---|
| 계정·OAuth | accounts.spotify.com 등 | 로그인은 되는데 라이브러리 동기화만 어긋날 때 의심합니다. |
| 웹·앱 셸·API | spotify.com·spclient 계열 | 카탈로그·개인화·세션 토큰과 함께 묶이는지 확인합니다. |
| 오디오 CDN | audio-fa.scdn.co·scdn.co 등 | 회색 곡·재생 중단은 스트림 엣지만 잘못된 DIRECT로 새는 전형입니다. |
| 이미지·정적 | mosaic.scdn.co 등 | 커버만 느린 패턴과 맞물립니다. 접미사를 과하게 넓히면 부작용이 납니다. |
로그인에 성공했다고 전부 통과한 것은 아닙니다. 앱은 백그라운드에서도 다른 호스트를 부르므로 한 덩어리 도메인 가정으로 규칙을 쓰면 금방 깨집니다.
3. 넷플릭스·Perplexity 글과의 차이
넷플릭스 분류 글은 nflx·영상 세그먼트·Open Connect 성격 호스트가 중심입니다. Perplexity 분류 글은 perplexity.ai와 검색·추론 프런트가 중심입니다. Spotify는 음악 스트리밍과 팟캐스트가 같은 클라이언트에 묶여 있어 호스트 이름도 다르고, “영상 버퍼”와 “오디오 스트림”의 체감 증상도 다릅니다. 키워드만 덮어쓰지 말고 재생 세션에서 실제로 붙는 이름을 근거로 적용하세요.
4. 도메인 수집: 재생 시도와 Clash 로그를 함께
한쪽만 보면 빠뜨리기 쉬우니 아래를 병행하세요.
- Spotify 웹 또는 앱에서 회색으로 보이는 트랙이 있는 플레이리스트를 연 뒤, 가능한 트랙을 재생해 증상을 재현합니다.
- Clash(Mihomo GUI의 연결 보기)에서 같은 직후에 뜬 연결 행을 시간순으로 모아
spotify·scdn이 들어간 호스트와 CDN으로 보이는 이름을 적습니다. DIRECT나 의도와 다른 정책에 떨어진 행에 표시를 하고, 구독 규칙 중 어느 줄 위에 사용자 규칙을 둘지 판단합니다.- 재생이 성공한 뒤에도 다시 로그를 보고 팟캐스트 전용 호스트가 늘었는지 확인합니다.
포트 충돌 등 일반 이슈는 트러블슈팅 가이드로. 본문은 Spotify에 한정합니다.
5. 권장 점검 순서
- Clash가 실행 중인지, 시스템 프록시인지 TUN인지 확인합니다.
- 연결 로그에서 Spotify 관련 호스트가 의도한 정책 그룹으로 나가는지, 잘못된
DIRECT가 없는지 봅니다. fake-ip를 쓰는지와 DNS 설정을 확인하고, 필요하면 특정 접미사에nameserver-policy등을 둡니다.- 계정·API·오디오 CDN을 호스트·접미사 단위로 규칙화하고, 구독 안의 넓은
DIRECT보다 위쪽에 모순 없이 둡니다. - 규칙이 맞은 뒤 지터가 적은 노드를 고르고 과도한 자동 전환을 줄입니다.
6. 시스템 프록시와 TUN: 빠짐 줄이기
시스템 프록시는 편하지만 프록시를 읽지 않는 구성요소나 다른 VPN 드라이버와 겹치면 표면상 경로가 갈라집니다. TUN은 라우팅 계층에서 잡아 일관성은 올라가지만 다른 VPN과의 경합이 있습니다. 켤 경우 TUN 모드 글을 보고, 켠 뒤 Spotify 관련 호스트가 모두 기대 경로인지 다시 로그로 검증하세요.
7. DNS·fake-ip: 이름 해석과 규칙 판정의 어긋남
fake-ip는 체감에는 유리할 수 있지만 설정에 따라 규칙에 넘기기 전 이름과 실제 연결 목적지가 어긋나기 쉽습니다. 서브도메인과 서드파티 CDN이 많은 서비스에서는 작은 어긋남도 클라이언트가 재시도를 반복해 사용자에게는 로딩이나 회색 트랙으로 보입니다. 상위 DNS를 안정적으로 맞추고, 로그에 자주 나오는 접미사에 전용 해석 정책을 두는 방식을 검토하세요. 필드 이름은 Mihomo·Clash Meta 버전별로 다를 수 있습니다.
8. 분류 규칙 예시(교체 전제)
구독에 넓은 DIRECT가 앞에 있으면 의도치 않은 직결이 섞입니다. 더 구체적인 DOMAIN·DOMAIN-SUFFIX를 위쪽에 두는 것이 실무적입니다. 아래는 예시이며 실제 호스트는 반드시 로그로 확인하세요.
# Example only — verify hostnames in your Clash logs before use
rules:
- DOMAIN-SUFFIX,spotify.com,SPOTIFY
- DOMAIN-SUFFIX,scdn.co,SPOTIFY
- DOMAIN-SUFFIX,spotifycdn.com,SPOTIFY
- DOMAIN-SUFFIX,spotifycdn.net,SPOTIFY스트림 전용 대역만 다른 그룹(SPOTIFY_AUDIO)으로 나누면 장애 시 원인을 나누기 쉽습니다. 그룹 이름은 proxy-groups에 정의되어 있어야 합니다.
9. GEOIP·대륙 직결 규칙과의 충돌
공항 구독에 GEOIP,KR,DIRECT 같은 광범위 규칙이 있으면, 일부 오디오 CDN 엣지만 의도치 않게 직결로 보내져 “노드는 맞는데 재생만 끊긴다”는 패턴이 납니다. 이럴 때는 Spotify 관련 블록을 규칙 상단에 두거나, 충돌하는 공급자 규칙 뒤에 로컬 덮어쓰기가 먹히도록 순서를 재확인하세요. 구독이 업데이트되며 예전에 넣어 둔 로컬 규칙이 뒤로 밀리는 경우도 흔합니다.
10. 노드 선택: 순간 속도보다 흔들림이 적은 회선
속도 테스트 1위라도 RTT가 자주 튀는 노드는 다수 요청 UI나 오디오 스트림에 불리합니다. TLS 핸드셰이크가 늘고 클라이언트는 타임아웃으로 보입니다. 수동으로 고정하거나 게임용 안정 노드를 쓰는 편이 낫습니다. 전송 특성은 프로토콜 비교 글을 참고하세요.
11. 추가 함정: LAN 공유·복수 VPN·hosts 수정
다른 PC에 프록시를 나눠 줄 때는 LAN 프록시 글에서 allow-lan과 방화벽을 확인하세요. Clash 외 상시 VPN과 TUN을 동시에 켜면 라우트가 겹쳐 가끔만 직결이 섞일 수 있습니다. hosts를 수동으로 바꾸면 특정 CDN만 다른 IP로 풀려 규칙과 어긋나기도 합니다. 한 경로로 되돌린 뒤 로그로 확인하는 것이 빠릅니다.
12. 준수·지역 정책에 대한 안내
이 글은 저작권을 침해하거나 불법 공유를 돕는 방법이 아니라, 합법적으로 이용 가능한 회선과 구독 조건 안에서 네트워크 경로를 일관되게 맞추어 품질을 개선하는 데 초점을 둡니다. 콘텐츠 제공 범위·지역 제한은 Spotify 및 권리자 정책을 따르세요.
13. 정리: 증거 기반으로 Spotify용 호스트를 묶기
Spotify 웹·앱에서의 회색 곡·재생 중단은 단일 스위치보다 모드·DNS·규칙 순서·노드 흔들림이 겹친 결과인 경우가 많습니다. 순서대로 로그를 보면 “무작정 글로벌 프록시”보다 재현 가능한 개선을 기대할 수 있습니다. 2026년에도 음악 스트리밍 인프라는 빠르게 바뀌므로 구독 규칙만 믿지 말고 본인 환경에서 호스트 표를 한 번씩 갱신하는 습관이 안전합니다.
연결 로그와 규칙 편집을 GUI에서 묶을 수 있는 클라이언트를 쓰면 YAML을 매번 손으로 고치는 부담도 줄어듭니다. Spotify 계정·재생·오디오 CDN을 한 출구로 안정화하고 싶다면 → Clash를 무료로 내려받고 매끄러운 연결을 시작해 보세요