텔레그램 데스크톱 «연결 중»? Clash 도메인 분류·MTProto·DNS 점검

1. 어떤 증상부터 의심할까

Telegram 데스크톱에서 자주 보는 현상은 (1) 상단이 계속 연결 중이거나 업데이트만 돌아가는 것, (2) 메시지는 오가는데 미디어·프로필 사진이 안 받아지는 것, (3) 특정 Wi-Fi에서만 재현되는 것입니다. 서버 장애나 지역 혼잡도 원인이 되지만, 본인 기기에서만 반복된다면 Clash의 분류 규칙 순서·DNS·선택한 노드가 트래픽을 서로 다른 출구로 보내고 있지 않은지부터 의심하는 편이 낫습니다.

«웹 브라우저는 빠른데 Telegram만 멈춘다»면 HTTP 위주로 동작하는 착각에 빠지기 쉽지만, 클라이언트는 설정·업데이트·동기화 과정에서 여러 호스트명과 IP 대역을 오갑니다. 규칙 세트가 일부 호스트만 특정 지역 직접 연결로 보내고 나머지는 다른 프록시 그룹으로 보내면, 한쪽만 타임아웃처럼 보일 수 있습니다. 재현할 때는 Telegram을 완전히 종료한 뒤 Clash 연결 로그를 켜고 다시 실행해, 어떤 도메인·프로토콜이 매칭되는지 몇 분 관찰하면 원인 분리가 빨라집니다.

팁: 같은 증상이 스마트폰 앱에서는 없고 PC 데스크톱에서만 난다면, OS단 프록시/TUN 적용 범위와 데스크톱 빌드가 다르다는 뜻이므로 PC 쪽 규칙·모드를 우선 확인하세요.

2. Telegram 데스크톱 트래픽이 Clash와 엮일 때

공식 클라이언트는 업데이트·CDN·API·채팅 동기화 등 목적별로 서로 다른 호스트를 씁니다. 예를 들어 telegram.org, t.me, core.telegram.org, api.telegram.org 등 공개적으로 알려진 이름들이 문서·배포 페이지에 등장하며, 실제 세션은 사용자 계정과 데이터센터 할당에 따라 IP 대역이 달라질 수 있습니다. 그래서 «한 줄짜리 호스트만 묶으면 끝»이라고 단정하기 어렵고, 도메인 접두 규칙과 함께 MATCH 이전 순서를 통째로 살펴볼 필요가 있습니다.

본문은 특정 국가 통신 규정을 우회하거나 계정 정책을 깨는 방법을 다루지 않습니다. 대신 프록시 사용자가 흔히 겪는 «연결은 되는데 동기화만 불안정하다»를 분류 규칙과 로그로 줄이는 데 초점을 맞춥니다. 공통 문법·모드 설명은 설정 가이드와 입문 튜토리얼을 함께 보시면 이해가 빨라집니다.

3. MTProto와 «어떤 포트를 보나» 감 잡기

MTProto는 Telegram이 쓰는 전송 프로토콜 계열을 가리키는 말로, 클라이언트 버전에 따라 TCP 기반 세션이 일반적으로 443처럼 잘 허용되는 포트를 사용하는 경우가 많습니다. 다만 데이터센터·중계 방식·클라이언트 빌드에 따라 보이는 목적지 IP와 포트가 달라질 수 있어, «반드시 이 포트만 연다»식으로 단정하면 오판하기 쉽습니다.

Clash 관점에서는 중요한 것이 «레지스트리에 적힌 포트 번호 하나»보다 어떤 규칙에 먼저 걸려 어떤 노드로 나가는가입니다. 노드가 해당 목적지로의 TCP 세션을 안정적으로 유지하지 못하면 연결 표시는 멈춘 채로 남거나 재시도만 반복될 수 있습니다. UDP가 중심인 Discord 음성과 달리, 데스크톱 텍스트·미디어 동기화는 TCP 비중이 크다는 점을 전제로 두면 증상 해석이 조금 달라집니다.

보안·규정 주의

회사·학교 등에서 프록시나 우회 사용이 금지된 네트워크라면, 기술적으로 가능하더라도 내부 정책을 우선해야 합니다. 본문은 개인 기기·허용된 환경에서의 자가 점검을 전제로 합니다.

4. DNS·fake-ip가 의심될 때

fake-ip 모드를 켜 두면 로컬에서 빠르게 응답하는 대신, 일부 앱이 기대하는 DNS 해석 순서와 어긋나 특정 호스트만 실패하는 일이 생길 수 있습니다. Telegram이 «일부 리소스만 영원히 로딩»처럼 보일 때는 fake-ip-filter(또는 클라이언트 문서에서 안내하는 동등 설정)에 공식 클라이언트가 쓰는 도메인 패턴을 포함했는지, DNS 서버가 노드와 같은 신뢰 경로로 나가는지 함께 봐야 합니다.

원인 좁히기는 fake-ip·DNS 트러블슈 글의 순서를 따르면 체계적입니다. 요지는 «브라우저로 테스트한 DNS 결과와 시스템/Clash DNS 결과가 같지 않다»는 불일치를 먼저 제거하는 것입니다. 도메인 규칙을 추가하기 전에 DNS 일관성부터 맞추면 같은 증상으로 규칙만 늘리는 실수를 줄일 수 있습니다.

주의: 공개 구독 규칙을 그대로 덮어쓰면 Telegram 관련 줄이 의도보다 아래에 깔려 매칭되지 않을 수 있습니다. 개인용 줄은 보통 구독 규칙보다 위에 두되, 지나치게 넓은 DOMAIN-KEYWORD 한 줄이 다른 트래픽까지 삼키지 않게 범위를 조정하세요.

5. 도메인 분류 규칙으로 출구 한 줄로 묶기

분류 규칙은 위에서 아래로 첫 매칭이 적용됩니다. MATCH나 GeoIP 직통 줄이 Telegram 관련 줄보다 위에 있으면, 아래에 아무리 정교한 규칙을 넣어도 실행되지 않습니다. 데스크톱 클라이언트 전용으로 묶고 싶다면 DOMAIN-SUFFIX로 공식적으로 알려진 접미사를 안전한 범위에서 반복하는 방식이 보수적입니다.

아래는 이해를 돕기 위한 개념 예시이며, 실제 키 이름·문법은 사용 중인 Mihomo 버전과 GUI 문서를 따르세요.

# Conceptual example — adapt to your Mihomo / client version
rules:
  - DOMAIN-SUFFIX,telegram.org,PROXY-TG
  - DOMAIN-SUFFIX,t.me,PROXY-TG
  - MATCH,DIRECT

PROXY-TG는 사용자가 만든 정책 그룹 이름이어야 하며, 자동 지연 선택보다는 안정적인 단일 노드를 고정해 두고 증상을 비교하는 편이 «연결 중» 멈춤 원인 분리에 유리한 경우가 많습니다. 규칙을 바꾼 뒤에는 클라이언트를 한 번 완전히 종료했다가 다시 켜 DNS 캐시와 세션을 새로 맞추는 것도 도움이 됩니다.

Telegram 관련 호스트명은 시간이 지나며 바뀔 수 있으므로, 로그에 실제로 찍힌 이름과 규칙을 대조해 필요하면 줄을 추가하는 방식이 안전합니다.

6. RULE 모드·정책 그룹·노드 선택

RULE 모드에서만 위 규칙이 의미 있습니다. 실수로 GLOBAL로 모든 트래픽을 한 노드에 몰거나 반대로 DIRECT 고정이면 도메인 줄과 무관하게 증상이 달라집니다. 또한 url-test류 그룹이 짧은 주기로 노드를 바꾸면 장시간 세션이 끊겨 메신저가 재연결을 반복할 수 있어, 테스트 단계에서는 가능하면 select로 한 노드를 고정하고 비교하는 것이 좋습니다.

노드를 바꿔도 동일하면 해당 노드 경로가 목적지까지 TCP를 안정적으로 유지하지 못하는 경우를 의심합니다. 반대로 특정 노드에서만 정상이라면 그 노드의 지연 숫자보다 «실제 앱 동작»을 기준으로 고르는 편이 Telegram에는 더 잘 맞습니다.

7. 시스템 프록시만으로는 부족한 이유

Windows·macOS의 시스템 프록시 설정은 모든 앱에 일관되게 전달되지 않으며, 일부 데스크톱 빌드는 자체 네트워크 스택을 씁니다. 그래서 «브라우저만 프록시를 타는데 Telegram은 직접 나간다»는 패턴이 나올 수 있습니다. TUN 모드를 켜면 OS 레벨에서 트래픽을 코어로 보내기 쉬워지지만, 라우팅·DNS·다른 VPN과 충돌하면 전체 인터넷이 끊기는 부작용도 있습니다. Windows에서는 TUN 후 라우팅·방화벽 점검 글의 순서를 참고하고, TUN 없이 규칙만으로 해결되는지 먼저 시험해 보는 것도 방법입니다.

IPv4·IPv6 혼합 환경에서는 한쪽만 프록시를 타고 다른 한쪽이 직접 나가면 동기화 일부만 실패하는 것처럼 보일 수 있습니다. 듀얼 스택 전반 점검이 필요하면 IPv6·인터페이스 규칙 글과 함께 읽으면 전제를 맞추기 쉽습니다.

8. 증상별 자가 점검표

Clash를 쓰는 데스크톱에서 Telegram을 점검할 때 참고할 표입니다.

증상	의심 지점	조치
상단만 연결 중, 채팅은 안 됨	규칙 순서·MATCH 직통·노드 불안정	RULE 확인·Telegram 줄 상단 배치·노드 고정
텍스트는 되는데 미디어만 안 받음	CDN·별도 호스트가 다른 출구	로그 도메인 확인 후 DOMAIN 줄 추가
fake-ip 켠 뒤부터만 이상	fake-ip-filter·DNS 불일치	fake-ip 글 순서대로 필터·DNS 정렬
Clash 끄면 정상	프록시 그룹·모드·TUN 충돌	단순 RULE·select 고정으로 재현 비교

GUI 편집기 종류에 따라 YAML 저장 경로와 재시작 동작이 다릅니다. 클라이언트 비교 글에서 사용 중인 앱에 맞는 편집 흐름을 익혀 두면 재시도 속도가 빨라집니다.

9. 요약

Telegram 데스크톱의 «연결 중» 멈춤은 단일 포트 설명으로 끝나지 않고, 분류 규칙이 여러 호스트를 어떤 노드로 보내는지·DNS·fake-ip 설정이 앱이 기대하는 해석과 맞는지가 함께 얽힙니다. MTProto라는 용어는 원인 표시를 돕지만, 실무에서는 로그에 찍힌 목적지와 규칙 매칭을 맞추는 작업이 우선입니다. Discord처럼 프로세스 이름과 UDP가 중심인 사례와는 접근이 다르므로, 증상에 맞는 글을 나누어 참고하는 것이 좋습니다.

설치 패키지는 공식 다운로드 페이지에서 받고, 오픈 소스 저장소는 빌드·이슈 확인용으로 두면 다운로드 경로 혼선이 적습니다.

→ Clash를 무료로 내려받아 Telegram용 도메인 규칙과 DNS·노드를 한 줄로 맞춰 보세요