증상: 웹·앱·CDN이 「반쯤」만 맞을 때

Clash로 음악만 조용히 돌리려다 보면, 브라우저 탭은 정상인데 데스크톱 앱만 끊기거나 그 반대인 경우가 흔합니다. UI는 열리는데 곡 재생이 몇 초 뒤 멈추거나, 라이브러리가 익숙한 국가와 다르게 보이는 느낌이 든다면 단일 스위치 문제가 아니라 여러 호스트의 출구 불일치를 의심하는 편이 맞습니다. 특히 오디오 조각은 CDN POP에 따라 지연·지터가 달라지므로, 메타데이터만 빠르고 실제 스트림만 느린 패턴이 나올 수 있습니다. 이런 때는 규칙을 무작정 늘리기보다, 규칙·분류 모범 사례에서 말하는 것처럼 로컬 대역 DIRECT·보안 목록·광고 목록과의 순서를 먼저 정리하고 Spotify 줄을 그 위에 두는지부터 확인하는 것이 안전합니다.

영상 OTT와 달리 음원은 비트레이트 숫자가 눈에 덜 띄어도, TLS 재협상·세션 쿠키·OAuth 토큰이 다른 출구를 타면 앱이 조용히 재시도 루프에 빠질 수 있습니다. 같은 Wi-Fi에서 한 기기만 이상하면 그 기기의 DNS 고정·IPv6 경로·다른 VPN 겹침도 함께 점검하세요. 스트리밍 공통 축은 Netflix 분류 글과 같지만, Spotify는 nflxvideo나 googlevideo 표를 그대로 가져오면 구멍이 남습니다.

ℹ 관측부터: 재생 직후 Clash 연결 로그에 반복되는 접미사를 적어 보세요. audio-ak-spotify-com처럼 Akamai 스타일의 긴 이름이나 fastly·edge류가 보이면, 그 줄을 DOMAIN-KEYWORD가 아니라 가능한 한 DOMAIN-SUFFIX로 안전하게 덮는 방향을 검토합니다(과도한 키워드 규칙은 오탐 위험이 큽니다).

Spotify가 쓰는 이름 공간(메타·오디오·CDN)

시기·클라이언트 빌드·A/B 실험에 따라 달라지지만, 실무에서 자주 등장하는 축은 다음과 같습니다. spotify.com·open.spotify.com·accounts.spotify.com은 로그인·웹 UI·계정 흐름에 가깝고, 앱 내부 API에는 spclient.wg.spotify.com·apresolve.spotify.com 같은 이름이 붙는 경우가 있습니다. 정적 자산과 스크립트는 scdn.co·spotifycdn.com 계열로 흩어지고, 실제 오디오는 audio-ak-spotify-com-*.akamaized.net 같은 패턴으로 보이기도 합니다. 이 글은 고정 불변의 공식 목록을 제시하기보다, 도메인 규칙을 쌓을 때 어떤 축을 한 정책 그룹으로 묶을지 틀을 제공합니다.

Disney+나 YouTube에서 이미 익힌 패턴—즉 프런트 호스트와 미디어 CDN을 분리해 보는 습관—은 그대로 이식됩니다. 다만 Spotify는 Google·Netflix와 다른 상용 CDN 조합을 쓰므로, YouTube 분류나 Disney+ 분류 글의 YAML을 통째로 복사해 오면 오디오 줄이 빠지기 쉽습니다. 로그에 찍힌 접미사를 기준으로 자신만의 SPOTIFY_MEDIA 그룹을 만드는 편이 낫습니다.

도메인 규칙·규칙 세트·순서

Clash 계열은 위에서 아래로 규칙을 읽으며 먼저 맞은 줄이 이깁니다. Spotify용 DOMAIN-SUFFIX는 지나치게 넓은 MATCH류보다 위쪽에 두되, LAN·사내망·업데이트 CDN을 DIRECT로 빼는 안전망 아래가 아니라 그 앞에 둘지·뒤에 둘지는 자신의 프로필 철학에 따라 달라집니다. 원격 규칙 세트만 믿기보다 로컬에 짧은 보강 블록을 두면, Akamai/Fastly 호스트가 바뀔 때 대응이 빨라집니다. 구독 URL이 깨졌을 때의 절차는 구독·노드 유지보수와 같이 관리하면 정신 건강에 이롭습니다.

아래는 Illustrative YAML fragment입니다. 정책 그룹 이름·노드 풀은 자신의 구독에 맞게 바꾸고, 실제 호스트는 반드시 로그로 대조하세요.

Illustrative YAML fragment

rules:
  - DOMAIN-SUFFIX,spotify.com,SPOTIFY
  - DOMAIN-SUFFIX,scdn.co,SPOTIFY
  - DOMAIN-SUFFIX,spotifycdn.com,SPOTIFY
  - DOMAIN-SUFFIX,pscdn.co,SPOTIFY
  - DOMAIN-SUFFIX,akamaized.net,SPOTIFY
  - DOMAIN-SUFFIX,fastly.net,SPOTIFY
  - GEOIP,KR,DIRECT
  - MATCH,DIRECT

akamaized.net·fastly.net 전체를 SPOTIFY에 넣으면 다른 서비스까지 끌려올 수 있어 위험합니다. 위 예시는 「어떤 키가 필요한지」를 보여 줄 뿐이며, 운용에서는 로그에서 반복되는 하위 도메인만 좁혀 넣는 것이 맞습니다. 넓은 키워드 한 줄이 생각보다 많은 트래픽을 잡아먹으면, 정책 그룹·지연 측정에서 말하는 것처럼 측정 URL과 실제 체감이 어긋날 수 있습니다.

계정 리전과 노드 출구를 맞추기

Spotify는 결제·라이선스·카탈로그가 계정 국가와 연결되는 경우가 많습니다. 노드 출구만 바꿔도 추천·가사·팟캐스트 가용성이 달라 보일 수 있으니, 「노드 국기 = 반드시 원하는 카탈로그」라는 단순 공식은 피하는 편이 좋습니다. 가족 요금제·여행 중 로그인처럼 엣지 케이스는 약관과 계정 설정 화면을 먼저 확인하고, 네트워크는 그 다음에 맞춥니다.

분류 목표가 “지역 표시를 바꾼다”가 아니라 “끊김만 줄인다”라면, 계정 리전은 그대로 두고 오디오 CDN 출구만 안정화하는 전략이 더 현실적일 때가 많습니다. STREAM/SPOTIFY 그룹 안에서 노드만 바꿔 A/B 테스트하면, 전역 프록시로 몰아넣었을 때보다 원인 분리가 쉬워집니다.

「웹만」「앱만」 프록시로 나누는 실측

데스크톱: 시스템 프록시 vs TUN

macOS·Windows에서 데스크톱 앱은 시스템 프록시를 무시하는 경우가 있습니다. 이때는 TUN으로 전체 트래픽을 규칙에 올리거나, 반대로 브라우저 확장으로 웹만 출구를 고정하는 식으로 역할을 나눕니다. TUN과 다른 VPN·보안 소프트가 겹치면 라우팅이 꼬이므로, 병용 전 TUN 심화 글의 충돌 패턴을 읽어 두세요.

Android: 앱 단위 분류

모바일에서는 Spotify 앱만 프록시에 태우고 나머지는 직결로 두고 싶은 요구가 많습니다. Clash Meta 계열의 앱 단위·프로세스 기반 옵션은 Android 앱 단위 프록시 글과 같이 단말·빌드에 따라 다르므로, 문서와 실제 단말에서 동작을 확인한 뒤 켜는 것이 안전합니다.

DNS·fake-ip·TUN과 재생 경로

DNS 응답과 실제 프록시 출구가 다르면 HTTPS는 열려도 세션이 끊기거나 재생이 들쭉날쭉해질 수 있습니다. fake-ip 모드를 쓸 때는 DOMAIN 규칙과 해석 경로가 같은 체계를 바라보는지 점검해야 합니다. nameserver·fallback·fake-ip-filter를 단계적으로 맞추려면 Meta DNS 가이드의 순서를 참고하세요. 브라우저 DoH·OS 리졸버·Clash DNS를 동시에 섞으면 우선순위가 꼬이기 쉬우니, FAQ의 연결성·DNS 항목과 함께 한 갈래로 정리하는 편이 낫습니다.

한 기기에서만 증상이 반복되면 그 기기의 DNS 고정 여부부터 의심합니다. IPv6가 켜져 있으면 “절반만 터널”처럼 보이는 경우도 있으니, 필요 시 IPv6·DNS 직결 축은 별도 글과 교차 확인하세요.

로그로 출구를 확인하는 법

추측 대신 로그에 찍힌 정책 적중과 목적지를 봅니다. 재생을 시작한 직후 어떤 접미사가 SPOTIFY를 탔는지, 동일 세션의 다른 호스트가 DIRECT로 새는지를 나란히 적어 두면 규칙 수정이 빨라집니다. TLS 핸드셰이크 단계에서 끊기는지는 timeout·TLS 진단 글의 관점과도 연결됩니다. GUI마다 로그 가독성이 다르므로 클라이언트 선택 때 진단 화면을 기준에 넣을 만합니다.

핵심은 「전부 프록시」도 「최소 프록시」도 아니라, Spotify가 쓰는 이름 공간을 한눈에 덮는 중간의 명시성입니다. 규칙이 읽히면 밤마다 무작위로 토글을 돌릴 필요가 줄어듭니다.
⚠ 준수: Spotify 및 관련 서비스 이용약관·저작권·지역 라이선스, 소재지 법령과 조직 정책을 지키세요. 이 글은 허용된 네트워크에서의 경로·DNS·프록시 설정 위생을 다루며, 무단 우회나 약관 위반을 조장하지 않습니다.

일부 지역에서는 VPN·프록시 사용 자체가 제한되거나 계약 위반으로 이어질 수 있습니다. 기술적 가능성과 합법적 이용 범위는 별개이므로, 설정을 바꾸기 전에 약관과 내부 보안 정책을 확인하는 것이 안전합니다.

맺음말

Spotify 문제는 종종 단일 토글이 아니라 메타 호스트와 오디오 CDN의 출구 불일치에서 옵니다. Clash는 정책 그룹·도메인 규칙·원격 규칙 세트·DNS 모드라는 언어로 그 불일치를 드러낼 수 있고, Netflix·YouTube에서 배운 스트리밍 분류 패턴을 음원 CDN 표에 맞게 다시 쓰면 됩니다. 불투명한 「부스터」보다 규칙이 파일에 남는 쪽이 장기적으로 덜 지치는 운영입니다.

노드 품질은 날마다 변하지만, 어떤 이름이 어떤 정책을 탔는지가 기록 가능하면 원인 분리가 빨라집니다. 새 Akamai/Fastly 접미사가 보이면 접미사를 보강하고, DNS와 TUN을 같은 전제로 맞추며, SPOTIFY 그룹 안에서만 A/B 테스트를 하면 지역 감지·끊김 이슈도 추측이 아니라 확인으로 바뀝니다.

같은 분류 사고방식은 다른 음원·팟캐스트 앱에도 이식할 수 있으나, 호스트 표는 서비스마다 다르므로 복붙보다 관측을 우선하세요. 영상 OTT 글에서 익힌 세분성을 Spotify 줄에 그대로 적용하면, 웹과 앱이 서로 다른 이야기를 하는 순간을 줄일 수 있습니다.

Clash는 한 번 맞춰 두면 이후 운영에서 되돌아보기 쉬운 편이라, 단순히 “빠른 노드”만 바꿔 끼우는 것보다 체감이 안정적인 경우가 많습니다. 다른 상용 클라이언트와 비교했을 때도, 규칙과 로그가 남는 쪽이 장기적으로 예측 가능한 경우가 많습니다.

→ Clash를 무료로 다운로드해 Spotify·CDN 호스트를 한 정책으로 묶고, 재생이 끊길 때마다 규칙 룰렛 대신 로그로 원인을 줄여 보세요.