1. 플레이오프·라이브·끊김 검색이 튀는 이유
플레이오프는 동시 시청이 몰리고 CDN 엣지 부하와 클라이언트 적응 비트레이트가 겹칩니다. 드라마 온디맨드와 달리 수 초 단위 세그먼트가 이어지므로 경로가 조금만 갈라져도 “자꾸 멈춘다”로 느껴집니다. 기술적으로는 팀 이름이 아니라 로그에 나온 호스트 표를 한번 맞추는 것이 재현성이 높습니다.
2. 라이브 트래픽을 층으로 나누어 보기
아래는 설계 메모용 구분이며 실제 서브도메인은 플랫폼·지역에 따라 다릅니다. 도메인 하나로 끝난다고 가정하고 규칙을 쓰지 마세요.
| 층 | 예시 | 점검 포인트 |
|---|---|---|
| 웹·앱 셸 | 리그 사이트, 스토어, 설정 | 상단은 열리는데 재생만 느리면 하류 CDN을 의심. |
| 로그인·권한 | OAuth, 토큰, 기기 연동 | 로그인은 되는데 스트림만 실패할 때 로그 확인. |
| 라이브 세그먼트 | HLS/DASH 청크, 저지연 엣지 | 초반은 괜찮다가 후반에 멈추면 대역·경로 분열 의심. |
| 측정·광고·폰트 | 서드파티 경량 요청 | 본류는 아니지만 과차단 시 재시도로 스피너가 길어질 수 있음. |
2026년에도 배포 스택은 자주 바뀌므로 예전에 되던 규칙이 갑자기 안 맞을 수 있습니다. 구독 규칙만 믿지 말고 로그로 표를 다시 만드세요.
3. 버퍼와 지역 제한(블랙아웃)을 섞지 말 것
화면에 “이 지역에서는 시청할 수 없습니다”가 뜨면 대개 계약·중계권 이슈입니다. 반면 속도 진단은 괜찮은데 라이브만 끊기면 경로 불안정이나 도메인별 정책 불일치일 수 있습니다. 먼저 증상을 나누고, 전자면 공식 앱 문구를, 후자면 Clash 쪽을 로그로 좁힙니다. 부당한 지역 위장은 약관·법규에 걸릴 수 있어 다루지 않습니다.
4. 증상의 의미: 라이브 끊김은 지연만의 문제가 아님
메타데이터는 프록시, 세그먼트만 DIRECT나 다른 노드로 가면 세션이 재개될 때마다 재버퍼가 늘어납니다. Clash 연결 목록에서 재생 중 늘어나는 호스트와 선택된 정책 이름을 나란히 보면 분열 패턴을 금방 볼 수 있습니다. 라이브의 주 무대는 대개 TCP HTTPS이지만 RTT 편차는 비슷하게 작용합니다.
YAML이 낯설면 먼저 구독 가져오기 글로 프로파일 흐름을 잡으면 이후 절차가 읽기 쉽습니다.
5. 도메인 수집: 킥오프 전후로 로그를 나누기
수집 흐름은 다음과 같습니다. 쿼터 전환 직후는 캐시가 덜 타서 시작 직후 수십 초를 보면 재현이 잘 됩니다.
- Clash를 켜고 시스템 프록시 또는 TUN을 켭니다. 다른 VPN은 잠시 끕니다.
- 브라우저나 공식 앱으로 시청 페이지에 로그인해 경기 화면까지 갑니다. 연결 뷰에서 같은 시각 호스트를 메모합니다.
- 실제 라이브 재생을 시작하고 비트레이트가 오를 때 늘어나는 호스트를 따로 적습니다. 세그먼트용만 다른 정책이 아닌지 봅니다.
DIRECT나 예상 밖 정책에 떨어진 줄에 표시하고, 구독 규칙 중 어느 줄보다 위에 사용자 규칙을 둘지 검토합니다.
포트 충돌 등 일반 문제는 트러블슈팅 글로. 본문은 라이브 멀티 도메인에 초점을 둡니다.
6. 권장 점검 순서
- Clash가 떠 있고 시스템 프록시인지 TUN인지 확인합니다.
- 연결 로그에서 NBA·League Pass 관련 호스트가 의도한 정책 그룹으로 가는지, 잘못된
DIRECT가 없는지 봅니다. fake-ip를 포함한 DNS를 보고 필요 시 특정 접미사에nameserver-policy등을 둡니다.- 인증·API·세그먼트 호스트를 호스트·접미사 단위로 규칙화하고 구독 안의 넓은
DIRECT보다 위에 모순 없이 둡니다. - 같은 경기에서 저화질로만 가는지, 일시정지 후 바로 이어지는지 확인합니다.
7. 시스템 프록시와 TUN: 누락 줄이기
시스템 프록시는 간단하지만 프록시를 읽지 않는 구성요소나 TV·셋톱 경로와 겹치면 표면상 경로가 갈라집니다. TUN은 라우팅 층에서 잡아 일관성은 올라가지만 다른 VPN과의 충돌·권한 부담이 있습니다. 켤 경우 TUN 모드 글을 보고 활성화 후 로그로 관련 호스트가 모두 기대 경로인지 검증하세요.
8. DNS·fake-ip: 인증 판단과 규칙 판단의 어긋남
fake-ip는 체감 속도에 도움이 될 수 있으나 설정에 따라 규칙에 넘기기 전 이름과 실제 접속 목적지의 정합이 깨지기 쉽습니다. 스포츠처럼 CDN과 API가 많은 서비스에서는 작은 어긋남도 재시도로 스피너로 보입니다. 상류 DNS를 신뢰 가능한 것으로 맞추고 로그에 자주 나오는 접미사에 전용 이름 해석 정책을 두는 것이 기본입니다. 라우터·OS의 DoH와 Clash 내부 DNS가 이중이면 질의가 갈라집니다. 검증 시에는 어느 쪽이 권위인지 잠시 단순화하면 빠릅니다.
9. 분류 규칙 (예시는 반드시 로그로 검증)
구독에 넓은 DIRECT가 먼저 있으면 의도치 않게 국내 직결로 떨어질 수 있습니다. 더 구체적인 DOMAIN·DOMAIN-SUFFIX를 모순 없이 위에 두는 것이 실무적입니다. 아래는 예시이며 실제 호스트는 로그로 바꿔야 합니다. 공유 CDN 접미사를 넓게 잡으면 NBA 외 사이트까지 끌어옵니다.
# Example only — 로그에서 확인한 뒤 사용, PROXY는 본인 정책명으로
rules:
- DOMAIN-SUFFIX,nba.com,PROXY
- DOMAIN-SUFFIX,nba.net,PROXY세그먼트만 다른 노드로 보내는 구성은 겉으로 합리해 보여도 세션 경계에서 재핸드셰이크가 늘 수 있습니다. 먼저 같은 정책 그룹으로 맞추고, 한계에 닿으면 분할을 검토하세요.
10. 넷플릭스 스트리밍 글과의 차이
넷플릭스 글은 국가별 카탈로그와 장편 VOD CDN에 초점을 둡니다. 본문은 플레이오프 라이브와 League Pass·공식 앱에 맞추고 저지연 세그먼트 변동을 다룹니다. 검색 키워드와 도메인 집합이 드라마와 스포츠 라이브에서 겹치기 어렵다는 점에서 호스트 표를 분리해 두는 것이 좋습니다. 온디맨드 절차는 넷플릭스 분류 글을 보세요.
11. Steam CDN 글과의 차이
Steam 글은 스토어 UI와 디포 다운로드 다도메인이 중심입니다. 라이브는 연속 세그먼트가 주전장입니다. 같은 PC에서 게임과 스포츠를 같이 쓰면 표를 나누면 혼선이 줄어듭니다. 다운로드 쪽은 Steam CDN 글을 참고하세요.
12. 노드 선택: 순간 최고 속도보다 흔들림 적음
속도 테스트 1위라도 RTT가 자주 튀는 노드는 라이브 적응 비트레이트에 맞지 않습니다. TLS 재협상이 늘고 클라이언트는 버퍼 언더런으로 보입니다. 수동으로 고정하거나 시청 전용 안정 노선을 쓰는 편이 실용적입니다. 전송 특성 비교는 프로토콜 비교 글도 참고하세요.
13. 추가 함정: IPv6, 캐리어 NAT, TV 앱
IPv6가 켜진 회선에서는 IPv6만 DIRECT로 나가고 IPv4만 프록시에 탄다든지 듀얼 스택 편향이 날 수 있습니다. 모바일은 CGNAT이 길게 작용할 수 있어 Wi‑Fi와 비교 실험이 유효합니다. 대형 화면은 브라우저가 아닌 전용 앱인 경우가 많아 DNS 출처가 PC와 다릅니다. 라우터에 Clash를 못 올려도 게이트웨이 PC에서 Clash를 돌리고 하류 단말의 기본 게이트웨이·DNS를 그 PC로 두는 구성이 흔합니다. LAN 공유 개요는 LAN 프록시 글에서 allow-lan과 방화벽 요점을 보세요.
14. 정리: 증거로 라이브 경로를 묶기
플레이오프 피크는 CDN 부하와 클라이언트 재시도가 겹쳐 체감 장애가 늘기 쉽습니다. 그래도 많은 경우 단일 설정 오류보다 모드·DNS·규칙 순서·노드 흔들림의 합입니다. 순서대로 로그를 보면 “일단 다른 노드”보다 재현 가능한 개선을 기대할 수 있습니다. 2026년에도 스포츠 인프라는 빨리 바뀌므로 구독만 믿지 말고 한번씩 호스트 표를 갱신하세요.
연결 로그와 규칙 편집을 GUI로 묶은 클라이언트를 쓰면 YAML을 매번 손으로 만질 부담도 줄어듭니다. 플레이오프 라이브를 안정적으로 보고 싶다면 → Clash를 무료로 다운로드하고 쾌적한 연결을 시작하세요