Telegram Desktop이 ‘연결 중’에서 멈출 때: Clash TUN·프로세스 분류·telegram 도메인으로 순차 복구
Telegram Desktop은 모바일 앱과 달리 OS의 시스템 프록시를 항상 따르지 않습니다. Clash를 켠 뒤 상단이 오래 ‘연결 중’으로 남거나, 텍스트만 오가고 스티커·사진·음성·영상 동기화가 밀리는 패턴은 2026년에도 커뮤니티에서 자주 보고됩니다. 원인은 단일 스위치가 아니라 MtProto 기반 세션, UDP·443 혼용, DNS·fake-ip, 그리고 규칙이 텔레그램 트래픽을 DIRECT로 보내 차단 구간에 두는 경우가 겹칠 때 많이 납니다. 이 글은 Clash Meta(Mihomo) 계열과 TUN 모드를 전제로, PROCESS-NAME·PROCESS-PATH와 telegram 관련 도메인을 같은 축에서 맞추는 순서를 정리합니다. 브라우저에서 telegram.org는 열리는데 데스크톱만 이상한 경우에도 적용할 수 있습니다.
흔한 증상: 연결 중, 글만 됨, 미디어·프로필 동기 지연
먼저 표면 증상을 나눕니다. 완전 오프라인이 아니라 “어느 정도 살아 있는데 불완전”한 상태가 많습니다. 예를 들어 채팅 입력은 되지만 상단 상태가 갱신되지 않거나, 작은 텍스트는 오는데 사진·파일이 회색 로딩에 머무릅니다. 이런 현상은 TCP만 프록시되고 UDP가 다른 출구로 나가거나, 미디어용 CDN·별도 호스트가 규칙에서 빠져 DIRECT로 떨어지는 경우와 맞물리기 쉽습니다.
또 한 가지는 스마트폰 앱은 정상인데 PC 클라이언트만 불안정한 경우입니다. 모바일이 셀룰러 또는 다른 DNS를 쓰고, PC는 Clash의 fake-ip와 시스템 해석이 엇갈리면 같은 계정이라도 동기 시점이 어긋납니다. 여기서는 “한 번에 글로벌 프록시로 때려 넣기”보다 로그에서 프로세스·목적지·매칭 규칙을 확인한 뒤 좁히는 접근이 안전합니다.
- 연결 중 무한 로딩: 핸드셰이크·DC 선택·업데이트 확인 등 초기 단계에서 막힘.
- 텍스트 위주로만 동작: 일부 경로만 살아 있거나 MTU·UDP 경로 문제를 시사.
- 웹 텔레그램은 되고 앱만 문제: 브라우저는 시스템 프록시를 따르지만 네이티브 클라이언트는 다를 수 있음.
시스템 프록시만으로는 부족한 이유와 TUN
Windows·macOS에서 “시스템 프록시 사용” 옵션은 많은 앱에 영향을 주지만, 데스크톱 메신저는 자체 스택으로 나가는 경우가 있습니다. TUN은 트래픽을 커널 근처에서 가로채 Clash 정책을 적용하게 해 주므로, “프록시 환경 변수를 무시하는 바이너리” 문제를 줄입니다. 특히 Rule 모드에서 최종 MATCH가 잘못된 그룹을 가리키면 텔레그램만 이상하게 보일 수 있으니, TUN ON + Rule 조합이 기준선이 됩니다.
Windows에서 Clash 기본 설치·구독·모드가 아직이라면 《Clash for Windows 설치·구독》을 먼저 맞추세요. macOS는 런치 에이전트·방화벽·Network Extension 권한이 변수입니다—《Clash Verge Rev macOS》 순서로 TUN이 실제로 올라왔는지 확인한 뒤 텔레그램 규칙을 조정하는 편이 빠릅니다.
점검 순서
① 코어 로그에서 TUN 어댑터·스택이 오류 없이 올라왔는지 ② Rule에서 의도한 행이 매칭되는지 ③ 그 다음에 도메인 목록을 늘리세요. 반대로 하면 규칙만 자꾸 덧붙이게 됩니다.
MtProto·UDP·443: 왜 ‘글만 된다’와 연결되는가
Telegram은 사용자에게 익숙한 HTTPS 웹뿐 아니라 MtProto 기반 연결을 사용합니다. 클라이언트는 데이터 센터·프로토콜 조합에 따라 TCP와 UDP를 함께 쓰기도 하며, 방화벽·ISP·DPI 환경에서는 특정 포트·프로토콜만 불안정해질 수 있습니다. Clash 쪽에서는 프록시 노드가 UDP 릴레이를 제대로 지원하는지, 규칙이 텔레그램 관련 트래픽을 어떤 정책 그룹으로 보내는지가 핵심입니다.
음성·통화까지 쓴다면 《Discord 음성·UDP·TUN》에서 다룬 것처럼 UDP 지연·단절은 다른 앱과 원인이 겹칩니다. 다만 텔레그램은 프로세스가 명확하므로 PROCESS-NAME으로 우선 묶고, 로그에 찍힌 목적지로 도메인 규칙을 보강하는 방식이 반복 디버깅에 유리합니다.
노드 전환만 반복하지 마세요
지연 수치만 보고 노드를 바꾸면 같은 규칙 오류를 반복합니다. “어떤 행에 매칭됐는지”가 먼저입니다.
telegram·t.me·CDN: 도메인 축을 한 번에 맞추기
원격 규칙 세트마다 표기가 조금씩 다르지만, 실무에서는 넓은 접두사로 묶은 뒤 로그로 좁히는 방식이 흔합니다. 예시로 자주 거론되는 계열에는 telegram.org, t.me, cdn.telegram.org, core.telegram.org 등이 있습니다. 중요한 점은 목록을 길게 복사해 붙이는 것보다, 자신의 로그에 실제로 나타난 호스트를 우선 반영하는 것입니다. CDN 엣지나 서브도메인은 바뀔 수 있어, 오래된 스크린샷만 믿으면 빈 규칙이나 잘못된 DIRECT가 남습니다.
브라우저로 telegram.org에 접속해 보고 데스크톱만 문제라면, 웹은 시스템 프록시를 타고 앱은 그렇지 않다는 신호일 수 있습니다. 이 경우 TUN + 앱 프로세스 규칙이 정답에 가깝습니다. 반대로 둘 다 실패하면 DNS·ISP 차단 쪽을 의심합니다.
| 구분 | 의미 |
|---|---|
DOMAIN-SUFFIX,telegram.org |
넓게 잡는 기본 축(환경에 맞게 세분화) |
PROCESS-NAME |
Windows Telegram.exe 등 실행 파일 단위 분류 |
| 정책 그룹 | 안정적인 해외 출구·UDP 지원 노드 풀을 따로 두는 경우가 많음 |
PROCESS-NAME·PROCESS-PATH로 데스크톱 클라이언트 고정
Clash Meta 계열에서는 PROCESS-NAME과 PROCESS-PATH로 특정 실행 파일의 트래픽을 정책 그룹에 연결할 수 있습니다. Windows에서는 작업 관리자에서 정확한 파일명(예: Telegram.exe)을 확인하세요. 동일 이름이 여러 경로에 있으면 PROCESS-PATH로 설치 폴더를 지정합니다. macOS는 /Applications/Telegram.app 트리 안의 바이너리 이름이 버전에 따라 다를 수 있으니, 클라이언트 로그나 활동 모니터로 맞춥니다.
프로세스 규칙은 보통 GEOIP나 최종 MATCH보다 위에 두어야 의도대로 승리합니다. 원격 규칙을 병합했다면 로컬 오버라이드가 병합 결과에서 앞쪽에 남는지 확인하세요. 그렇지 않으면 “규칙을 추가했는데도 로그상 DIRECT”가 계속됩니다.
규칙 순서와 YAML 예시
아래는 예시입니다. PROXY 자리에 실제 정책 그룹 이름을 넣고, 운영체제에서 프로세스 이름을 검증하세요.
# Illustrative rules — verify names and policy groups on your system
rules:
- PROCESS-NAME,Telegram.exe,PROXY
- DOMAIN-SUFFIX,t.me,PROXY
- DOMAIN-SUFFIX,telegram.org,PROXY
- DOMAIN-KEYWORD,telegram,PROXY
- MATCH,DIRECT
DOMAIN-KEYWORD는 범위가 넓어 오탐이 생기기 쉽습니다. 가능하면 로그로 확인된 호스트부터 DOMAIN·DOMAIN-SUFFIX로 촘촘히 조정하세요. 최종 MATCH가 전부 PROXY인 구독 프로필에서는 텔레그램만 DIRECT로 빠지는 모순이 나올 수 있으니, 그룹 안의 fallback·url-test 결과도 함께 봅니다.
규칙 배치 메모
- 차단 회피가 목적이면 텔레그램 관련 행을 광역 DIRECT보다 앞에 둠.
- 특정 국가·리전 노드만 쓰려면 해당 그룹이 UDP·장기 세션에 맞는지 확인.
- 프로세스 규칙과 도메인 규칙이 서로 모순되지 않게 한쪽을 기준으로 통일.
DNS·fake-ip·분할 튜널
TUN 사용 시 DNS 해석 경로가 바뀌면서 “브라우저와 앱의 도메인 결과가 다르게 보이는” 일이 생깁니다. 연결은 되는데 특정 기능만 깨질 때 《DNS·fake-ip 점검》과 함께 nameserver·fallback·fake-ip 필터를 점검하세요. 한 번에 여러 변수를 바꾸지 말고, DNS 고정 → 규칙 수정 → 노드 변경 순으로 좁히면 재현성이 좋아집니다.
일부 클라이언트는 분할 튜널(split tunnel) 목록에 텔레그램을 빠르게 예외 처리할 수 있습니다. 장기적으로는 YAML 규칙이 더 예측 가능하지만, “당장 업무용만 국내 직통” 같은 요구에는 GUI 예외가 빠른 해결책이 될 수 있습니다.
DPI·ISP 차단이 의심될 때
증상이 특정 회선에서만 나고 VPN 없이는 완전 차단된다면 Clash 규칙만으로는 한계가 있습니다. 그래도 클라이언트 내부에서는 목적지가 어디로 매칭되는지를 먼저 확정해야 합니다. 차단이 아니라 잘못된 DIRECT인 경우가 훨씬 흔합니다. 공용 Wi-Fi에서만 실패한다면 포트·UDP 제한을 의심하고, 집에서는 규칙·DNS를 우선 의심하세요.
FAQ
웹 텔레그램은 되는데 앱만 ‘연결 중’이다
TUN과 프로세스 규칙으로 데스크톱 실행 파일 트래픽을 명시적으로 프록시 그룹에 붙이세요. 시스템 프록시만 믿지 마세요.
글·스티커는 되는데 사진·파일이 안 받아진다
미디어 CDN 호스트가 다른 규칙에 DIRECT로 빠지는지 로그에서 목적지를 확인하고, 필요한 서픽스 규칙을 추가하세요.
PC에 텔레그램이 두 벌 깔려 있다
PROCESS-PATH로 폴더를 구분하거나, 사용하지 않는 설치본을 정리해 혼선을 없애세요.
실무 체크리스트
- TUN·Rule 모드에서 코어 로그에 치명 오류가 없는지 확인.
- Telegram 데스크톱 프로세스명·경로를 OS에서 확정.
PROCESS-NAME또는PROCESS-PATH행을 GEOIP·MATCH보다 앞에 배치.telegram.org·t.me등 실제 로그에 나온 호스트로 도메인 규칙 보강.- DNS·fake-ip 점검 후에야 노드 교체를 반복.
규칙이 보이는 클라이언트에서 시작
Telegram은 트래픽 종류가 많아 보이지만, 분류 축은 프로세스 → 목적지 → 정책 그룹으로 단순화할 수 있습니다. 로그가 투명할 때 원인도 줄어듭니다.