어떤 증상에 이 글이 해당할까

Clash나 mihomo는 켰는데 Telegram만 상단이나 채팅 목록이 계속 연결 중(Connecting)으로 머문다면, “노드가 느려서” 한 줄로 끝나는 경우도 있지만, 동일한 노드로 브라우저·다른 앱은 정상인데 텔레그램만 멈출 때는 규칙·DNS·TUN이 텔레그램 흐름만 빗나가는 케이스를 먼저 의심하는 편이 낫습니다. 특히 t.me 링크로 초대·채널에 들어가는 경로, web.telegram.org로 여는 웹 클라이언트, 데스크톱·모바일 앱이 MTProto로 데이터센터(DC) IP에 붙는 경로는 서로 도메인 형태가 달라서, 한 가지 DOMAIN-SUFFIX만 넣고 끝내면 “일부는 되고 일부는 연결만 도는” 패턴이 나옵니다.

또 MTProto라는 말이 커뮤니티에서 MTProxy(별도 프록시 포트)로 오해되는 경우가 있는데, 여기서 말하는 것은 주로 텔레그램이 앱·클라이언트에 쓰는 기본 전송(데이터센터와의 세션)을 뜻합니다. 실제로는 149.154.0.0/16 등으로 알려진 DC 대역으로 443·기타 포트에 붙는 흐름이 도메인 규칙에 안 잡히는 IP 트래픽으로 남을 수 있어, Clash Telegram 이슈는 “호스트 몇 개만 추가”와 “IP/GEOIP/GEOSITE 층”을 같이 봐야 합니다. 음성·화상 쪽 UDP는 Discord 연결 때처럼 별도로 민감하지만, “연결 중”만 멈출 때 먼저는 TCP 443 중심의 MTProto·API와 t.me·telegram.org 계열을 맞추는 편이 일반적입니다.

한 줄 telegram.org로는 부족한 이유

많은 구독·룰 셋에 DOMAIN-SUFFIX,telegram.org가 들어가 있어도, 짧은 링크 t.me는 다른 FQDN이고, static·CDN·웹앱용 호스트가 추가로 열리기도 합니다. 게다가 클라이언트가 DC로 직접 붙는 구간은 SNI 없는 IP 연결로 찍힐 수 있어, “도메인 규칙은 PROXY인데 트래픽 로그엔 IP,149.154.x.x,DIRECT가 섞인다” 같은 이중 경로가 생깁니다. 이럴 땐 rules 위에서 아래 순서 중 더 넓은 GEOIP,CN,DIRECT나 잘못된 MATCH가 텔레그램 IP보다 먼저 잡지 않는지, Fake-IP를 켠 경우 DNS·필터가 텔레그램용 이름을 로컬 가짜 IP로 뭉갠 뒤 아웃바운드가 엇갈리지 않는지 같이 봐야 합니다. 전체 DNS·Fake-IP 설계는 YAML 설정 심화 가이드와 맞춰 읽는 것이 좋습니다.

요약하면 Clash 분기는 “눈에 보이는 도메인”만이 아니라, MTProto가 실제로 쓰는 출구 전략 그룹과, IP 기반 규칙이 같은 그룹을 가리키는지까지가 한 세트입니다. 화면에 “연결 중(Connecting)”만 뜨는 현상·Telegram 프록시·t.me 키워드로 찾아오신 분은 보통 이 지점이 비어 있을 때가 많습니다.

도메인·서비스 덩어리(교육용 예시)

아래는 수업용 예시이며, 클라이언트 버전·지역·A/B에 따라 실제 SNI가 늘거나 바뀔 수 있습니다. 자신의 연결 로그에 찍힌 이름이 최우선이고, 넓은 DOMAIN-KEYWORD는 다른 서비스와 충돌할 수 있어 장기용으로는 RULE-SET·접미사로 좁히는 것이 안전합니다.

• 초대·채널 짧은 링크: t.me, telegram.me 등
• 웹 클라: web.telegram.org, (환경에 따라) webk.telegram.org 등
• 공식 사이트·다운로드·문서: telegram.org, core.telegram.org 등
• 봇·API·접속 정보: api.telegram.org 등(인증·동기)

이 중 t.me만 PROXY로 보내고 api.telegram.org는 빠뜨리면, 앱은 여전히 연결 루프에 빠질 수 있습니다. 반대로 STUN·콜 연결은 UDP 시나리오와 겹쳐 보일 수 있으나, MTProto용 도메인·IP 규칙을 말할 때는 먼저 도메인 + DC IP를 맞추는 것이 재현·디버깅에 유리합니다.

PROXY_TG 전략 그룹: 출구를 하나로

Clash에서 Telegram만 모으려면, 일반 PROXY와 별도로 PROXY_TG 같은 전용 전략 그룹을 두고, 그 그룹에 지연은 조금 있어도 안정적인 노드만 넣는 패턴이 많습니다. url-test가 웹 측정 URL만 보고 바꾸면 텔레그램·MTProto 쪽 세션이 끊겼다 붙기를 반복해 “계속 연결 중”으로 보일 수 있어, 문제 재현 시에는 select로 한 노드에 고정한 뒤에만 자동전환을 켜는 편이 좋습니다. udp가 필요한 음성·콜을 쓴다면 그룹에 넣은 노드가 UDP 릴레이를 지원하는지도 같이 확인하세요(노드 프로토콜·공급자 설명과 상충하지 않는지).

rules 스케치(개념 예시, 프로필에 맞게 수정)

아래는 문법 개념이며, 사용 중인 프로필·룰 프로바이더·GEOSITE 유무에 맞게 조정해야 합니다. GEOSITE,telegram,PROXY_TG 류가 구독에 이미 있다면, 중복·순서 역전만 없는지 확인하세요. GEOIP,CN,DIRECT가 너무 위에 있으면(실제론 DC가 CN이 아니더라도) 다른 줄과 섞여 의도와 다른 매칭이 나올 수 있으니, 로그에 찍힌 IP·국가와 대조가 필요합니다.

# Conceptual excerpt — match your mihomo/Clash profile
proxy-groups:
  - name: PROXY_TG
    type: select
    proxies:
      - NODE_STABLE
      - PROXY

rules:
  - DOMAIN-SUFFIX,t.me,PROXY_TG
  - DOMAIN-SUFFIX,telegram.me,PROXY_TG
  - DOMAIN-SUFFIX,telegram.org,PROXY_TG
  - DOMAIN-SUFFIX,telegra.ph,PROXY_TG
  - DOMAIN,web.telegram.org,PROXY_TG
  - DOMAIN-SUFFIX,legra.ph,PROXY_TG
  # Optional when rule providers include it:
  # - GEOSITE,telegram,PROXY_TG
  # - GEOIP,telegram,PROXY_TG
  - MATCH,PROXY

위 스케치는 IP 대역(데이터센터)을 직접 쓰지 않았는데, 로그에 IP로만 뜨는 MTProto·DC 흐름이 DIRECT로 쌓이면 ipcidr 룰·아시아 DC용 프로바이더·구독에 포함된 Telegram IP류 RULE-SET을 검토하는 단계로 넘어가면 됩니다. 문서·게시물에서 MTProto 규칙을 검색할 때는 “공식 앱이 쓰는 MTProto(데이터센터)”과 “MTProxy 전용 엔트리(별도 호스트/포트)”를 문맥상 구분하는 것이 혼란을 줄입니다.

TUN·시스템 프록시: 앱이 정말 코어를 통과하는가

브라우저는 시스템 HTTP/S 프록시를 따르는데, 데스크톱·일부 UWP/스토어 앱은 예외로 직접 나갈 수 있습니다. 클라이언트에서 프록시를 켰다고 느껴져도 앱 트래픽이 코어에 안 올라오면 규칙이 무의미해집니다. 이때 TUN으로 시스템 트래픽을 한 코어에 모으거나(클라이언트 지원·OS 정책 준수 전제), 모바일은 앱별 프록시·백그라운드 정책을 함께 봅니다. Windows에서 TUN을 켰다가 전체 인터넷이 끊기면 TUN·라우트 점검을 먼저 하고, 상용 VPN과 TUN이 겹치면 라우트·MTU가 덮어씌워져 텔레그램만 이상한 동작을 할 수 있습니다.

포트 443, MTProxy, “별도” 규칙이 필요한 경우

일반 클라이언트는 443 등 흔한 포트를 쓰는 경우가 많아 포트를 따로 뚫는 설명이 항상 필요하진 않습니다. 다만 MTProxy로 공개된 비표준 포트를 수동으로 넣었거나, 회사·캠퍼스 방화벽이 일부 OUT만 막는 환경이면, Clash 안에서의 규칙과 별도로 로컬 방화벽·라우터가 443/UDP(콜)을 막는지도 같이 봅니다. 이 글은 합법적 접속 권한이 있는 네트워크에서 경로 불일치를 줄이는 데 국한합니다.

점검 순서(복붙용 체크리스트)

대규모로 구독을 갈아엎기 전에, 아래 순서를 권합니다.

1. 로그에서 t.me, telegram.org, api, IP로 찍힌 줄을 각각 메모해 첫 번째로 매칭된 규칙이 무엇인지 확인한다.
2. api.telegram.org·web.telegram.org·t.me가 같은 PROXY_TG로 가는지, 하나라도 DIRECT·다른 그룹이면 그 줄을 위쪽에 좁은 규칙으로 맞춘다.
3. DC IP만 IP 규칙에 걸릴 때는 RULE-SET/IPCIDR·GEOSITE/GEOIP 층이 비어 있지 않은지 본다.
4. Fake-IP를 쓰면 fake-ip-filter·DNS 텍스트에 텔레그램 관련 도메인이 필요한지 YAML과 맞춘다.
5. TUN ON/OFF·다른 VPN 중복·IPv6만 탄다면(텔레그램/회선) 비교해 본다.

정리

Clash를 켰는데 Telegram이 계속 연결 중이면, t.me와 telegram.org·api·MTProto(데이터센터) IP가 서로 다른 전략으로 쪼개지거나, IP 트래픽이 도메인 규칙 밖으로 직접 나가는지부터 보면 원인이 좁혀집니다. MTProto용 도메인·IP 규칙을 전략 그룹·규칙 순서·DNS·TUN과 한 축으로 맞출 때 “복붙에 가깝다”는 느낌으로 쓰기 쉬우나, 반복해서 손댈 때는 로그에 나온 실제 SNI·IP로만 점진적으로 키우는 것이 안전합니다.

지역 법·서비스 약관·내부 정책을 위반하는 목적이 아닌, 합법적으로 쓰는 환경에서 텔레그램 트래픽의 프록시 경로를 정리하는 절차로 이해해 주십시오. 코어·GUI는 배포 페이지에서 최신 흐름을 확인한 뒤, 설정을 바꾼 뒤에도 한동안 같은 노드에 고정한 채로 앱의 “연결 중”이 사라지는지 확인해 보는 것이 좋습니다. → Clash를 무료로 내려받아 정식 클라이언트를 맞춘 다음, 로그에 잡힌 호스트부터 Clash Telegram용 전용 그룹을 다시 점검해 보시기 바랍니다.