어떤 분께 맞는 글인가요?

Discord 데스크톱 앱을 새로 깔거나 업데이트할 때 진행 막대가 0% 근처에서 오래 멈춘 것처럼 보이거나, 텍스트 채널·임베드는 되는데 음성 방에서만 소리가 끊기거나 딜레이가 튀는 경우가 있습니다. 원인은 하나가 아니라 설치·패치용 CDN, 계정·스토어 메타데이터를 비롯한 앱 API, 실시간 이벤트용 게이트웨이(WebSocket), 그리고 음성 미디어 서버로 향하는 RTP 계열 UDP가 서로 다른 호스트·프로토콜 묶음이라서, 프록시 규칙이 한 축만 맞고 다른 축은 DIRECT나 느린 노드로 새면 증상이 패치만 안 되거나 보이스만 불안정한 형태로 갈라집니다. 이 글은 Windows에서 Clash를 쓰며 “브라우저 Discord는 괜찮은데 데스크톱만 이상하다”, “프록시를 끄면 낫다” 같은 패턴을 재현 가능한 순서로 좁히는 데 초점을 맞춥니다. PC용 Clash 클라이언트를 이미 사용 중이라면 아래 체크리스트를 그대로 따라가며 로그를 채워 보시면 됩니다.

규칙 전체 구조를 손보기 전에 규칙 분할 가이드에서 설명하는 MATCH·GEOIP 배치를 한 번 확인하고, 앱이 시스템 프록시를 무시하는지 의심되면 TUN 모드 가이드와 브라우저만 우회·시스템 프록시 분리 글을 함께 읽는 편이 빠릅니다.

증상을 세 축으로 나눕니다

먼저 ① 설치·업데이트·대용량 에셋 CDN(진행률이 안 움직이거나 극단적으로 느림), ② 로그인·동기화·알림 등 세션·게이트웨이(간헐적 재연결, 온라인 표시 불안정), ③ 음성 채널 RTP·UDP(팩 손실처럼 들림, 방 입장은 되는데 품질만 나쁨)을 표로 나누세요. ①②는 대개 TCP TLS와 DNS 해석 결과·fake-ip 매핑에 민감하고, Discord 내장 웹뷰와 OS 브라우저가 같은 이름이라도 다른 경로를 탈 수 있습니다. ③은 노드가 UDP를 제한하거나 우선순위가 낮을 때 흔히 나타나며, 공유기 대칭형 NAT·보안 제품의 UDP 검사와도 겹칩니다. “지연 테스트 숫자는 괜찮은데 보이스만 문제”라면 지연 테스트·UDP·DNS 트러블슈팅에서 TCP 지표와 실사용 UDP가 어긋나는 경우를 먼저 짚어 보세요.

Epic Games Launcher나 Steam처럼 “상점 API + CDN 다운로드 + 실시간 세션/음성”가 한 아이콘 안에 들어 있는 클라이언트는 점검 순서가 비슷합니다. 이미 Epic 런처 분할이나 Steam 분할·UDP 글을 따라 해 보셨다면, Discord도 “먼저 증상 축을 고르고 → 로그에 찍힌 접미사를 규칙으로 옮긴다”는 같은 습관을 그대로 적용하면 됩니다. 차이점은 호스트 이름 접두·접미 패턴이 게임 런처와 전혀 다르다는 것뿐입니다.

관측: Clash 로그에 어떤 Discord 호스트가 찍히나

YAML을 크게 뜯기 전에 클라이언트에서 연결 로그를 켠 채로 다음을 각각 시도해 보세요: 소규모 업데이트 유도, 음성 채널 입장·퇴장, 서버 목록 새로고침. 로그에 반복되는 접미사는 환경·리전·클라이언트 버전에 따라 달라질 수 있지만, 검색 키워드 예시로는 discord.com, discordapp.com, discord.gg, discordapp.net, discord.media 등이 자주 등장합니다. 이미지·스티커·임베드용 객체는 미디어 CDN 이름으로 따로 찍히기도 하므로, “채팅은 되는데 미디어만 안 된다”면 해당 줄만 따로 표로 빼세요.

IP만 보이고 도메인 열이 비면 Sniffer와 override-destination 순서를 점검합니다. 스니핑이 빗나가면 의도한 DOMAIN-SUFFIX 줄을 건너뛰고 위쪽 GEOIP·MATCH에 먼저 걸려, 결과적으로 업데이트 트래픽만 다른 노드로 새는 일이 생깁니다. 목표는 커뮤니티에 붙어 있는 긴 목록을 통째로 붙여 넣는 것이 아니라, 본인 세션에서 실제로 출현한 문자열과 TCP/UDP 구분을 표로 남기는 것입니다.

규칙 우선순위와 DOMAIN-SUFFIX 배치

GEOIP나 광역 MATCH가 목록 위쪽에서 트래픽을 먼저 소비하면 아래쪽 Discord 전용 줄은 실행되지 않습니다. 그래서 “discord 줄을 넣었는데 왜 안 먹지?”는 대개 순서 문제입니다. 반대로 Discord 관련 접미사를 지나치게 위에 몰아 넣으면 다른 앱과 충돌하지 않는지도 함께 봐야 합니다. 일반적으로는 앱 전용 전략 그룹을 하나 두고, 그 아래에 세부 호스트를 같은 그룹 또는 CDN 전용 그룹으로 나누는 방식이 읽기 쉽습니다.

수집한 접미사를 묶을 때 이름은 구독 프로파일에 맞게 바꿉니다. 아래는 예시일 뿐이며, 실제 노드 그룹 이름·순서는 본인 규칙표와 합쳐야 합니다.

# Example only — adapt group names; verify hostnames from your logs
rules:
  - DOMAIN-SUFFIX,discord.com,PROXY-DISCORD-APP
  - DOMAIN-SUFFIX,discordapp.com,PROXY-DISCORD-APP
  - DOMAIN-SUFFIX,discord.gg,PROXY-DISCORD-APP
  - DOMAIN-SUFFIX,discordapp.net,PROXY-DISCORD-MEDIA

보이스 미디어 전용 접미사를 따로 잡았다면 PROXY-DISCORD-VOICE처럼 분리해, 지연에 민감한 UDP 경로만 다른 노드 프로파일로 보낼 수 있습니다. 다만 출구 IP가 채팅 API와 완전히 엇갈리면 일부 서버 기능에서 세션 불일치가 날 수 있으니, 분리는 “로그로 증명된 후”에 적용하는 편이 안전합니다.

업데이트가 0%로 보이거나 극도로 느릴 때

CDN 계열은 대용량 바이너리와 작은 메타데이터 요청이 같은 접두 아래 섞여 있을 수 있습니다. fake-ip와 공유기 DNS가 섞이면 터미널의 조회 결과와 앱이 실제로 붙는 엣지가 달라져, “같은 회선인데도 패치만 이상하다”는 체감이 납니다. Clash DNS의 nameserver·폴백, 그리고 라우터의 DNS 재지정·가속 옵션을 함께 확인하세요. 순수 회선 문제라면 로그에 TLS 재시도·장시간 대기가 남는 경우가 많고, 디스크 여유나 권한 문제로 진행률이 안 움직이는 것처럼 보일 수도 있으니 클라이언트 내 캐시·설치 경로도 병행해서 확인합니다.

한 노드에서만 CDN 속도가 막히면 전략 그룹 내 다른 서버로 바꿔 동일 로그를 비교해 보세요. 이때 웹 브라우저로 discord.com을 여는 테스트만으로는 부족하고, 반드시 데스크톱 설치 프로그램이 생성하는 연결을 로그에서 따라가야 합니다.

게이트웨이·WebSocket과 채팅 안정성

실시간 알림·입장 상태·음성 방 입장 협상 등 일부 흐름은 지속 연결에 의존합니다. 중간 프록시가 긴 유지 연결을 잘못 끊거나, 노드가 재연결 빈도를 제한하면 텍스트는 되는데 상태 표시만 들쭉날쭉한 패턴이 나올 수 있습니다. 이때는 도메인 규칙만이 아니라 노드 품질·타임아웃 정책을 의심해야 합니다. 브라우저 탭만 프록시를 타고 Discord.exe가 시스템 프록시 밖으로 나가면 증상이 더 분명해지므로, TUN으로 경로를 통일했을 때 개선되는지를 비교 실험하는 것이 좋습니다.

음성 RTP·UDP와 Windows 환경

음성 경로는 게임 음성과 마찬가지로 UDP 비중이 큽니다. 노드가 TCP 웹 위주로 안정적이어도 UDP가 차단되거나 우선순위가 낮으면 “방에는 들어가는데 소리만 깨진다”는 패턴이 나옵니다. Clash·Mihomo 계열에서 UDP가 어떤 체인으로 들어가는지는 코어·프로파일·TUN 설정에 따라 다르니, 음성 채널을 켠 상태로 로그를 열어 프로토콜 열을 확인하는 것이 가장 확실합니다. Windows에서는 방화벽에서 Discord.exe가 프라이빗 프로필에서 허용돼 있는지, 보안 제품이 UDP 스트림을 검사하지 않는지도 프록시와 별도 축으로 점검하세요.

공유기 뒤에서 이중 NAT이거나 NAT 타입이 매우 엄격하면, 규칙을 완벽히 맞춰도 음성 품질에 한계가 있습니다. 이런 경우는 “Clash Discord 분할”과 다른 문제이므로, 동일 증상이 프록시를 완전히 끈 상태에서도 재현되는지 먼저 나눕니다.

게임 클라이언트와 함께 쓸 때의 점검 순서

Discord를 띄운 채 Steam·Epic·기타 타이틀을 돌리는 환경에서는, 증상이 어느 앱에서 시작됐는지 먼저 고정해야 합니다. 동시에 여러 클라이언트가 UDP를 쓰면 공유기 QoS나 보안 소프트웨어 한도에 걸려 “Discord만”이 아니라 “UDP 전반”이 흔들리는 것처럼 보일 수 있습니다. 순서 제안은 다음과 같습니다: (1) 문제 재현 시점에 Discord 단독으로도 같은지 확인, (2) Clash 로그에서 해당 PID·프로세스 이름과 매칭되는 아웃바운드 확인, (3) 규칙 표에서 위쪽 광역 규칙이 Discord 줄보다 먼저 매칭되는지 출력해 검토, (4) 필요 시 TUN으로 경로 통일 후 다시 (2). 게임 전용 분할을 이미 쓰고 있다면 Steam·Epic 글의 “로그 기반 접미사 표” 습관을 Discord 표와 나란히 두고 관리하면 중복이 줄어듭니다.

이용 약관·합법 사용

Discord 이용약관·지역 정책은 수시로 바뀝니다. 프록시나 VPN을 이용해 허용되지 않은 우회를 목적으로 하는 구성은 약관 위반이 될 수 있습니다. 이 글은 네트워크 관측·분기 방법을 기술적으로 설명할 뿐, 특정 제한을 무력화하도록 권장하지 않습니다. 직장·학교·타인 회선에는 동일 구성을 임의로 적용하지 마세요.

마무리

Discord 데스크톱은 한 아이콘 안에 패치 CDN, API·게이트웨이, 음성 미디어 UDP가 함께 들어 있습니다. Clash 분할을 논할 때는 증상 축을 먼저 세우고, 로그에 찍힌 도메인·프로토콜을 근거로 DOMAIN-SUFFIX와 전략 그룹을 쌓아야 재현 가능한 튜닝이 됩니다. Windows에서는 시스템 프록시와 앱 실제 경로가 어긋나는 경우가 많으므로 TUN 비교 실험을 빼먹지 마세요.

브라우저와 데스크톱 클라이언트가 섞인 환경에서 정책을 한곳에 모아 두기에 Clash 계열은 적합합니다. 다른 시나리오에서 익힌 분할 습관을 Discord에도 이식하되, 호스트 이름은 자주 바뀌므로 로그 기반 업데이트를 습관화하세요. 우선 문서·튜토리얼로 프로파일 개념을 정리한 뒤 본문 순서대로 CDN·게이트웨이·UDP를 각각 재현해 보시길 권합니다. 준비가 되었다면 Clash를 무료로 다운로드하여 규칙과 노드를 손에 익혀 보세요. 패치 진행과 보이스 품질이 단계적으로 안정되는 것을 확인할 수 있을 것입니다.