1. 증상을 먼저 나누기: 업데이트와 음성은 다른 축입니다
사용자 입장에서는 모두 “Discord 가 불안정하다”로 느껴지지만, 관찰 포인트는 다릅니다. 첫째, 앱 상단의 업데이트 안내가 뜬 뒤 진행률이 0% 에서 오래 멈추거나 다운로드 속도가 표시되지 않는 경우입니다. 둘째, 서버 목록·채팅은 되는데 음성 채널에 들어가면 몇 초 뒤 끊기거나, 상대 목소리만 끊기고 자신의 마이크는 살아 있는 것처럼 보이는 경우입니다. 셋째, 스트리밍·화면 공유만 끊기고 텍스트는 되는 경우입니다. 넷째, 특정 노드로 바꾸면 즉시 나아지고 다른 노드에서는 항상 같은 패턴이 반복되는 경우입니다. 각각 걸리는 호스트 묶음과 전송 방식이 조금씩 다르므로, 한 번에 “Discord 전부 PROXY” 로 덮기보다 연결 로그에 찍힌 도메인 을 근거로 나누는 편이 안전합니다.
구독 YAML 을 아직 익숙하게 다루지 않는다면 구독 가져오기 튜토리얼에서 프로필을 먼저 안정화한 뒤 이 글의 분류 단계로 넘어오는 편이 좋습니다.
2. 왜 CDN 트래픽과 음성·RTC 경로를 나누어 생각해야 하나요?
클라이언트 업데이트 패키지는 대용량 파일이 CDN 엣지에서 내려오는 경우가 많고, 채팅·REST·웹소켓 성격의 API 는 discord.com 이나 discordapp.com 계열에 모입니다. 반면 음성은 지연이 적은 회선을 찾아 UDP 기반 미디어 경로를 쓰는 구간이 있어, TCP 만 잘 되는 노드라도 체감이 다를 수 있습니다. 공항 구독의 광범위 규칙이 CDN 접미사를 DIRECT 로 보내고 핵심 API 만 프록시를 타면, 화면은 “반쯤” 뜨고 업데이트 바만 멈춘 것처럼 보이기도 합니다. 반대로 모든 트래픽을 무조건 먼 노드로 몰면 음성 RTC 지연이 커져 끊김으로 느껴질 수 있습니다. 그래서 “같은 앱이라도 호스트 목적별로 정책을 나누고, 로그로 검증한다”는 접근이 중요합니다.
Clash 계열은 버전과 코어에 따라 UDP·TUN 처리 세부가 다릅니다. 이 글은 특정 필드 이름을 강제하지 않고, Mihomo 최신 문서와 GUI 설명을 함께 보는 전제에서 공통 원리만 짚습니다.
3. 권장 점검 순서
- Clash 가 켜져 있는지, 시스템 프록시 인지 TUN 인지 기록합니다.
- 실시간 연결 목록에서 discord·discordapp·discordcdn·gateway 등 관련 호스트가 기대한 정책 그룹으로 나가는지,
DIRECT로 새는지 확인합니다. - 업데이트를 시도할 때 새로 뜨는 호스트와 음성 채널 입장 직후 뜨는 호스트를 각각 비교합니다.
fake-ip사용 여부와 DNS 해석 정책을 확인하고, 필요하면 핵심 접미사에nameserver-policy를 둡니다.- 로그에서 본 호스트를
DOMAIN-SUFFIX규칙으로 올리고, 공급자 규칙·로컬 규칙의 순서 충돌을 정리합니다. - UDP·음성이 여전히 불안정하면 TUN 전환, 방화벽 예외, 다른 상시 VPN 종료를 순서대로 시험합니다.
4. Windows에서 Discord가 프록시를 타는 경로
Electron 기반 데스크톱 앱은 많은 경우 시스템 프록시를 따르지만, 일부 네이티브 모듈이나 백그라운드 다운로더는 예외가 있어 DIRECT 로 나가기도 합니다. 브라우저 Discord 는 되는데 앱만 Discord 업데이트 실패 가 반복되면 이런 경로 차이를 의심하세요. 이때 TUN 모드를 켜면 라우팅 계층에서 잡혀 동일 출구로 묶이기 쉽습니다. 다만 다른 상시 VPN 과 동시에 켜면 어댑터 충돌이 생길 수 있으니, 한 번에 하나의 터널만 남기고 다시 테스트하세요.
Windows 방화벽·보안 제품이 Discord 실행 파일의 아웃바운드 UDP 를 막으면 프록시 규칙과 무관하게 음성만 끊깁니다. Clash 설정을 고치기 전에 예외 목록을 함께 확인하는 것이 좋습니다.
5. DNS·fake-ip: 규칙과 어긋나면 진행률이 멈춘 것처럼 보입니다
fake-ip 는 체감 지연을 줄이는 데 도움이 될 수 있지만, 해석 결과와 실제 연결 목적지가 어긋나면 TLS 핸드셰이크가 반복되고 대용량 다운로드는 시작조차 못 하는 것처럼 보입니다. 특히 CDN 분류 가 끼어 있는 서비스에서 서브도메인마다 다른 엣지로 붙는 패턴이면 증상이 두드러집니다.
상위 DNS 가 신뢰 가능하고 Clash 에서 도달 가능한지 먼저 확인한 뒤, discord.com·discordapp.com 등 핵심 접미사에 별도 해석 정책을 두는 방식을 검토하세요. 필드 이름은 Mihomo 버전에 따라 다를 수 있으니 최신 문서와 예제를 함께 보는 것이 안전합니다. 규칙을 고친 뒤에는 Windows DNS 캐시를 비우거나 Discord 를 완전히 종료했다가 다시 열어 이전 세션이 남지 않게 하는 것도 도움이 됩니다.
6. 도메인 수집: 연결 패널이 최우선 증거입니다
인터넷에 떠도는 “완성된 Discord 도메인 목록”은 배포 시점과 지역·ISP 에 따라 빠르게 달라질 수 있습니다. 그래서 이 글은 고정 목록을 외우게 하기보다, 본인 PC 세션에서 실제로 붙는 호스트 를 모으는 절차를 권장합니다.
Clash Verge Rev 등 GUI 에서 실시간 연결을 연 뒤 Discord 에서 업데이트 를 재시도하고, 음성 채널에 들어갔다 나왔다를 반복합니다. discord.com·discordapp.com·discord.gg 외에 discordcdn.com·discord.media 같은 자산 호스트, gateway.discord.gg 계열, 지역에 따라 보이는 엣지 이름을 메모합니다. 실패한 연결(타임아웃·리셋)의 호스트를 우선적으로 규칙에 올리면 체감이 가장 큽니다.
Discord 프록시 문제를 줄이려면 “추측으로 노드만 바꾸기”보다, 로그에 찍힌 문자열을 그대로 복사해 두었다가 규칙에 반영하는 습관이 더 빠릅니다.
7. 규칙에 올리기 전 체크리스트
아래 표는 사고를 돕는 틀일 뿐이며, 실제 이름과 개수는 반드시 연결 로그로 검증해야 합니다.
| 구분 | 예시 방향 | 메모 |
|---|---|---|
| 웹·API·로그인 | discord.com·discordapp.com | 채팅·설정 동기화와 함께 묶이는지 확인합니다. |
| 초대·세션 | discord.gg | 딥링크·초대 흐름에서 별도로 보일 수 있습니다. |
| CDN·정적 자산 | discordcdn.com 등 | 업데이트 패키지와 이모지·이미지가 같은 출구인지 봅니다. |
| 게이트웨이·음성 | gateway.discord.gg 등 | 음성 RTC 입장 직후 로그가 바뀌는지 확인합니다. |
8. 규칙 예시 (정책 그룹 이름은 교체)
# Example only — replace PROXY with your policy group name
rules:
- DOMAIN-SUFFIX,discord.com,PROXY
- DOMAIN-SUFFIX,discordapp.com,PROXY
- DOMAIN-SUFFIX,discord.gg,PROXY
- DOMAIN-SUFFIX,discordcdn.com,PROXY
- DOMAIN-SUFFIX,discord.media,PROXY
- DOMAIN-SUFFIX,discordstatus.com,PROXYDOMAIN-KEYWORD,discord 는 편하지만 오탐이 생기기 쉬우니 과도하게 쓰지 말고, 로그에 근거해 접미사를 좁히세요. 업데이트만 특정 노드로 보내고 음성은 지연이 적은 다른 그룹으로 보내고 싶다면 정책 그룹을 두 개로 나누어 디버깅하기 쉽게 만들 수 있습니다. 다만 실제 운영에서는 “한 세션 안에서 호스트가 서로 다른 출구를 보면” 인증·쿠키·지역 판정이 꼬일 수 있으니, 먼저 같은 출구로 묶인 상태에서 안정화 한 뒤 세분화하는 순서를 권합니다.
Discord 측 호스트 명은 시기에 따라 바뀔 수 있으므로, 위 예시는 출발점으로만 두고 본인 세션 기준으로 덮어쓰는 것이 좋습니다.
9. UDP·음성(WebRTC): TUN과 방화벽을 함께 봅니다
음성 품질 문제는 TCP 규칙만 맞춰서는 끝나지 않는 경우가 많습니다. Mihomo 를 쓰는 클라이언트라면 TUN 모드에서 UDP 가 기대대로 코어를 통과하는지, Windows 방화벽이 해당 프로세스를 허용하는지 확인하세요. 공항 노드가 UDP 를 제한하면 음성은 끊기고 텍스트는 정상인 패턴이 나올 수 있습니다. 이때는 규칙보다 노드 제약 이 원인입니다.
지터가 큰 노드는 대화형 미디어에 불리합니다. 규칙이 맞는지 확인한 뒤에는 손실이 적은 회선을 고정하거나 자동 전환 임계값을 완화하는 편이 낫습니다. 전송 계층 특성은 프로토콜 비교 글을 참고해 보조 근거를 얻을 수 있습니다.
10. GEOIP·대륙 직결 규칙과의 충돌
공항 구독에 GEOIP,CN,DIRECT 같은 광범위 규칙이 있으면, 일부 CDN 엣지가 의도치 않게 직결로 보내져 “한국 노드를 썼는데도 업데이트만 이상하다”는 패턴이 납니다. 이럴 때는 Discord 관련 블록을 규칙 상단에 두거나, 충돌하는 공급자 규칙 뒤에 로컬 덮어쓰기가 먹히도록 순서를 재확인하세요.
구독이 업데이트되며 예전에 넣어 둔 로컬 규칙이 뒤로 밀리는 경우도 흔합니다. “Discord 전용 블록”을 파일 상단에 두고 주기적으로 순서를 점검하면 재발을 줄일 수 있습니다.
11. GUI 워크플로: Clash Verge Rev
연결 패널에서 호스트 문자열을 필터링하면 잘못된 DIRECT 를 빠르게 찾을 수 있습니다. 첫 설치와 구독 흐름은 Clash Verge Rev 초보자 가이드를 따르세요. 대용량 CDN 분류 패턴을 이미 다뤄본 적이 있다면 Steam 상점·CDN 분류 가이드와 로그 읽는 습관을 나란히 두면 학습 곡선이 줄어듭니다.
12. 그래도 안 될 때: 일반 트러블슈팅과의 교차
포트 충돌·구독 파싱 오류·코어 업데이트 실패 같은 주제는 앱별 글보다 공통 절차가 빠릅니다. Clash 일반 트러블슈팅 가이드에서 7890 포드·프로필 유효성·TUN 권한을 먼저 확인한 뒤, 이 글의 Discord 전용 단계로 돌아오세요.
13. 정리: 로그 근거를 한 층씩 쌓기
Discord Clash 조합에서 Discord 업데이트 가 0% 에 고정되거나 음성 RTC 가 끊기는 현상은 단일 스위치가 아니라 프록시 모드·DNS·규칙 순서·UDP·노드 품질 이 겹친 결과인 경우가 많습니다. 이 글의 순서대로 연결 로그 증거를 남기면 불필요한 노드 순환과 잘못된 DIRECT 를 빠르게 줄일 수 있습니다.
설정 파일을 매번 직접 고치기보다 Mihomo 를 내장한 공식 클라이언트에서 로그·업데이트·프로필 전환을 한 화면에서 처리하는 편이 운영 부담이 적습니다. 범용 프록시 도구와 비교해도, 구독·분류·연결 기록이 함께 있으면 “일부 호스트만 빠진다”는 증상을 빠르게 좁힐 수 있습니다. → Clash 를 무료로 내려받고 Discord 세션을 같은 출구로 묶어 보세요