Tailscale와 Clash를 동시에 켰을 때: 라우팅 테이블·MagicDNS·분류 예외로 끊김·오경로를 나누는 분단계 점검(2026)

① 증상을 세 줄로 고정하기

포럼·슬랙에서 「Tailscale 켜면 Clash가 망한다」는 제목은 넓습니다. 실제 지원 비용을 줄이려면 다음 중 무엇에 가까운지 먼저 적어 두세요. 첫째, 모든 TCP·UDP가 끊기거나 지연만 극단적으로 늘어난다면 기본 라우트 충돌이나 순환·블랙홀을 의심합니다. 둘째, 해외만 또는 국내 사이트만 이상하게 느리면 잘못된 노드 경유(분류 규칙 오적중) 가능성이 큽니다. 셋째, 브라우저 주소창에는 되는데 특정 호스트 이름만 안 되면 MagicDNS와 시스템 DNS·Clash DNS의 경로 불일치를 의심합니다. 같은 증상이라도 원인 축이 다르므로, 한 번에 설정 세 개를 갈아엎기보다 아래 순서를 유지하는 편이 빠릅니다.

Tailscale의 Exit Node나 「모든 트래픽을 Tailscale로」에 가까운 옵션은 OS의 기본 출구를 바꿉니다. 이때 Clash TUN도 비슷한 역할을 하려 하면, 플랫폼마다 메트릭·정책 라우팅 테이블 우선순위에 따라 한쪽이 다른 쪽을 덮어쓰거나 일부 트래픽만 예외로 새는 현상이 납니다. 사용자에게는 「어제까지 되던 브라우저가 오늘만 안 된다」처럼 보이지만, 배경에는 종종 클라이언트 자동 업데이트나 Exit Node 토글 한 번이 있습니다.

② 한 번에 하나만 끄는 A/B 분리

원인 추적의 황금 규칙은 동시에 변수를 두 개 이상 바꾸지 않는 것입니다. 재현이 된다면 순서대로 시도해 보세요. (1) Exit Node·전역 라우팅 성격의 Tailscale 옵션만 끄고 Clash는 유지. (2) 반대로 Tailscale은 유지하고 Clash TUN만 끄고 시스템 프록시만 사용. (3) 둘 다 살린 채 MagicDNS만 잠시 비활성화하고 내부 이름 대신 IP로 접속 테스트. 어느 단계에서 증상이 사라지는지가 다음 점검의 출발점이 됩니다. 장시간 운영 환경이라면 각 단계마다 스크린샷이나 메모를 남겨 두면 나중에 팀원에게 넘길 때도 유리합니다.

③ 단계 1: OS 라우팅 테이블에서 「기본 출구」 확인

라우팅 테이블은 패킷이 어떤 인터페이스로 나가야 하는지를 적어 둔 표입니다. Windows에서는 route print 또는 설정 앱의 네트워크 어댑터 우선순위와 함께 보면 이해가 빠르고, macOS·Linux에서는 netstat -rn 또는 ip route 계열로 확인합니다. 표 안에서 눈여겨볼 것은 다음입니다. 0.0.0.0/0(IPv4 기본 경로)과 ::/0(IPv6 기본 경로)가 어느 인터페이스·게이트웨이를 가리키는지, 그리고 Tailscale 대역(문서에 안내된 노드 주소 공간)으로 향하는 더 구체적인(static) 항목이 있는지입니다.

Clash를 TUN 모드로 쓰면 커널에 가상 인터페이스가 생기고, 클라이언트나 코어 설정에 따라 기본 경로가 TUN 쪽으로 붙는 경우가 있습니다. 반대로 Tailscale이 Exit 경로를 추가하면 두 개의 “전역 터널” 후보가 표에 동시에 존재하게 됩니다. 이 상태에서 특정 앱만 문제인 경우, 해당 앱이 바인딩한 주소나 정책 라우팅(소스 IP 기준 라우팅)을 쓰는지까지 들여다봐야 합니다. 같은 PC에서 가상화 계층까지 겹치면 더 복잡해지므로, Hyper-V와 호스트 Clash 또는 Docker Desktop과 프록시·DNS 글과 증상을 비교해 보세요. 레이어는 다르지만 「호스트에 이미 터널이 있다」는 점은 공통입니다.

④ 단계 2: 서브넷 라우팅과 사설 대역 충돌

서브넷 라우팅(subnet router)을 켜 두면 Tailscale이 조직 내부 사설망 대역을 광고합니다. 집·회사 라우터가 사용하는 192.168.x.x나 10.x.x.x가 Tailscale 경로와 겹치면, 사용자의 PC는 「물리 LAN의 그 서브넷」 대신 「Tailscale이 알려 준 원격 서브넷」으로 패킷을 보내려 할 수 있습니다. 결과적으로 프린터·NAS·국내 전용 포털 같은 로컬 자원에만 지연이 생기고, 해외 웹은 정상인 것처럼 보이기도 합니다.

이때 필요한 조치는 (1) 사설 대역을 재번호화해 충돌을 없애거나, (2) 문제되는 대역만큼 더 높은 우선순위의 호스트 라우트를 수동으로 넣거나, (3) Tailscale 쪽에서 해당 서브넷 광고를 조정하는 것입니다. Clash 분류 예외만으로는 라우팅 표 자체의 충돌을 완전히 치유하지 못하는 경우가 많으니, 먼저 OS 표를 정리한 뒤 규칙을 손보는 순서가 안전합니다.

⑤ 단계 3: MagicDNS와 이름 해석 경로 정렬

MagicDNS는 Tailscale 네임스페이스 안에서 기계 이름을 응답해 줍니다. 활성화돼 있으면 클라이언트가 조회하는 DNS 서버는 보통 Tailscale이 제공하는 경로를 타게 되고, 여기에 Clash의 DNS 블록(enhanced-mode, fake-ip, fallback 등)이 겹치면 「조회는 한 번 성공했는데 실제 연결 단계에서 다른 IP를 본다」 같은 불연속이 생길 수 있습니다. 특히 브라우저가 HTTPS DNS(DoH)를 직접 쓰면 시스템 레졸버와 병렬로 동작해 디버깅이 어려워지므로, 재현 중에는 DoH를 잠시 끄고 비교하는 것을 권합니다.

실무 점검 순서는 다음과 같습니다. 문제 호스트에 대해 (1) OS 도구로 조회한 응답과 (2) Clash DNS 로그의 응답을 나란히 적습니다. (3) *.ts.net·조직 내부 전용 접미사는 Clash에서 DIRECT 또는 최소한 프록시 그룹 밖으로 빼는 분류 예외를 고려합니다. 문법은 구독 프로필마다 다르지만, 원칙은 「Tailscale이 기대하는 이름→주소 매핑이 Clash의 가상 IP 단계에서 가로막히지 않게 한다」입니다. TUN과 DNS의 관계는 TUN 모드 심화 글과 함께 읽으면 큰 그림을 공유하기 쉽습니다.

⑥ 단계 4: Clash 규칙에서 Tailscale·메시 트래픽 예외

연결 로그에 Tailscale 관련 호스트나 할당된 노드 대역으로 향하는 플로우가 보이면, 상단 규칙에 예외를 두어 직접 연결(DIRECT) 또는 전용 그룹으로 보내는 패턴이 흔합니다. 예시 개념은 다음과 같습니다. (실제 YAML은 사용 중인 코어 문서를 따르세요.)

# Conceptual — keep Tailscale control plane / mesh-friendly paths above broad PROXY RULE-SET
rules:
  - DOMAIN-SUFFIX,tailscale.com,DIRECT
  - DOMAIN-SUFFIX,ts.net,DIRECT
  - IP-CIDR,100.64.0.0/10,DIRECT,no-resolve
  # Optional IPv6 ULA used by Tailscale — verify current docs for your release
  # - IP-CIDR6,fd7a:115c:a1e0::/48,DIRECT,no-resolve
  - MATCH,PROXY

no-resolve를 붙일지 여부는 트래픽이 도메인 규칙에서 이미 결정되는지에 따라 달라집니다. 복사만 해서 넣기보다 한 줄씩 의미를 확인하세요. 또한 거대한 RULE-SET이 위쪽에서 이미 프록시를 걸고 있으면 이 예외 줄은 실행되지 않습니다. 규칙 순서 기본 원리는 사용자 정의 규칙 튜토리얼과 동일합니다.

⑦ 단계 5: 「국내 사이트가 해외 노드를 탄다」일 때

한국 사용자에게 흔한 불만은 해외 서비스가 아니라 국내 포털·은행·공공 앱이 느려지는 경우입니다. Tailscale과 무관하게도 Clash 프로필에서 GEOIP·RULE-SET·MATCH 배치가 어긋나면 비슷하게 보입니다. 세부 절차는 대륙 우회·GEOIP 체크리스트 글의 사고방식을 빌려, 「직결을 원하는 목적지 IP·도메인」을 로그로 확인한 뒤 예외를 위로 올리면 됩니다. 단, 글의 GEOIP 코드가 다르다면 그대로 복사하지 말고 본인 프로필이 타깃으로 삼는 지역 코드에 맞추세요.

⑧ 단계 6: Linux 데스크톱에서 systemd-resolved까지 겹칠 때

우분투·페도라 등에서 systemd-resolved가 이미 스텁 리졸버를 들고 있고, 그 위에 Tailscale과 Clash DNS가 올라가면 세 단계 계층이 됩니다. 증상은 「dig로는 되는데 앱만 안 된다」처럼 표현되기도 합니다. 이 레이어는 Linux에서 Clash와 systemd-resolved DNS 글의 순서를 그대로 참고할 수 있습니다. Tailscale을 추가했다면 어떤 프로세스가 최종적으로 어떤 리졸버 주소를 바라보는지만 한 번 더 확인하면 충분히 줄일 수 있습니다.

⑨ 보안·운영 메모

subnet routing과 Exit Node는 편리하지만, 노출 범위를 넓히므로 조직 정책과 장치 신뢰 모델을 무시하면 안 됩니다. 개인 실험 환이라도 라우트를 손볼 때는 변경 전후의 라우팅 테이블 스크린샷을 남기고, 가능하면 유선 연결만 남긴 채 재현해 보세요. Wi-Fi와 셀룰러 테더링을 오가며 테스트하면 메트릭이 바뀌어 같은 설정이라도 결과가 달라질 수 있습니다.

⑩ 한 줄 요약

Tailscale과 Clash가 함께 깨질 때는 먼저 OS 라우팅 테이블에서 기본 출구와 서브넷 광고를 확인하고, 이어 MagicDNS와 Clash DNS·fake-ip의 경로를 맞춘 다음, 연결 로그를 근거로 분류 예외를 규칙 상단에 두면 재현을 크게 줄일 수 있습니다. 레이어가 다른 WSL2·Docker·Hyper-V 글과 짝을 이루어 읽으면 「왜 내 증상만 다르게 보이는지」가 분명해집니다.

데스크톱 클라이언트는 릴리스 노트만 따라가기보다 이 사이트 다운로드 페이지를 기준으로 잡는 편이 설치 경로가 분명합니다. 입문 흐름은 튜토리얼과 함께 보셔도 좋습니다. 규칙형 클라이언트는 로그와 함께 쓸 때 장기적으로 시간이 아낍니다. → Clash를 무료로 내려받고, Tailscale·MagicDNS와 겹치는 라우팅·DNS를 단계적으로 맞춰 보세요.