Tailscale과 Clash가 동시에 켜지면 왜 깨질까: TUN 스택·LAN 우회·라우팅 우선순위로 차근차근 맞추기

흔한 증상: “Clash만 켜면 Tailscale이 이상해진다”의 패턴

문제는 단일 스위치가 아니라 겹친 가로채기에서 자주 발생합니다. 예를 들어 Clash TUN이 활성화된 뒤에만 같은 Wi-Fi의 다른 기기에 ping이 안 되거나, 브라우저로 공유기 192.168.x.1에 접속하지 못하는데 Tailscale 피어로는 붙는 경우가 있습니다. 반대로 Tailscale Exit Node나 공격적인 서브넷 노출을 켠 뒤 Clash를 켜면 순환 라우트나 잘못된 다음 홉 때문에 전체가 끊기기도 합니다.

또 하나는 DNS입니다. TUN 기반 클라이언트는 로컬 리졸버를 바꾸거나 53번 포트를 가로채기 쉬운데, Tailscale의 MagicDNS와 Clash의 fake-ip가 동시에 개입하면 “해석은 되는데 응답 경로가 엇갈린다”는 형태로 나타납니다. 이때는 《DNS·fake-ip 점검》과 함께 보는 것이 좋습니다.

• LAN만 죽고 인터넷은 살아 있음: 사설 대역이 터널 쪽 default에 흡수됐을 가능성.
• 인터넷 전체 단절: 기본 게이트웨이·메트릭 충돌, 또는 strict-route 조합 문제.
• Tailscale 피어만 불안정: UDP·MTU·인터페이스 바인딩이 Clash 쪽 스택과 충돌.

두 개의 터널: 누가 기본 경로(default route)를 잡는가

OS는 여러 VPN 인터페이스를 동시에 올릴 수 있지만, 가장 낮은 메트릭이나 정책적 우선순위에 따라 패킷이 빠져나갑니다. Tailscale은 보통 자체 TUN(예: Linux tailscale0, Windows Tailscale)을 만들고 원격 망과 피어 경로를 추가합니다. Clash TUN은 종종 모든 앱 트래픽을 한 번 끌어와 사용자 규칙에 태우려고 하므로, 설정에 따라 LAN 대역까지 터널 안으로 당겨지는 착시가 납니다.

정리하면 “둘 다 켜도 되는가?”의 답은 조건부 예입니다. 조건은 로컬 사설망은 반드시 직통으로 남길 것, 충돌 나는 인터페이스는 한쪽에서 명시적으로 제외할 것, 라우트 우선순위를 숫자로 확인할 것 세 가지로 압축됩니다.

1단계: Clash TUN 스택(system / gVisor / mixed) 정렬

Clash Meta 계열에서 tun.stack은 가로채기 방식을 바꿉니다. system 스택은 OS 스택과 밀접해 성능은 좋지만, 다른 VPN과의 상호작용이 민감할 수 있습니다. gvisor(또는 문서에 따라 gVisor 표기)는 사용자 공간 네트워크 스택이라 격리적인 대신 지연이 늘 수 있습니다. 환경마다 최적치가 달라 “정답 한 줄”은 없고, 충돌이 의심될 때 스택만 바꿔 재현 여부를 보는 절차가 현실적입니다.

Windows에서 TUN이 처음이라면 《Clash for Windows 설치·구독》으로 기본 연결을 만든 뒤, 이 문서의 조합을 적용하세요. macOS는 Network Extension·권한 이슈가 변수이므로 《Clash Verge Rev macOS》에서 TUN이 실제로 올라왔는지 먼저 확인하는 편이 빠릅니다.

2단계: 사설망 우회·bypass-private-network·인터페이스 제외

대부분의 “NAS만 안 된다” 사례는 Clash가 RFC1918 사설 대역(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)을 터널 경유로 보내려 하기 때문에 생깁니다. Clash Meta 프로필에서는 bypass-private-network(또는 이에 상응하는 “로컬 네트워크 우회” 옵션)을 켜 사설 목적지를 Clash 처리 전에 빼내는 패턴이 흔합니다. UI 클라이언트마다 이름이 조금씩 다르니, YAML에서 tun: 블록을 직접 볼 수 있게 준비해 두면 재발 대응이 쉽습니다.

Tailscale이 만든 인터페이스가 Clash의 auto-detect와 충돌한다면, exclude-interface(코어 버전에 따라 키 이름이 다를 수 있음)에 tailscale0, Windows의 Tailscale 어댑터 이름 등을 넣어 상대 터널을 건드리지 않게 분리합니다. 이때 이름은 OS의 ip addr, ipconfig /all, macOS의 ifconfig로 정확히 적어야 합니다.

집 안에서 다른 PC로 프록시를 열어 두었다면 《LAN·mixed-port·허용》 글의 토폴로지와 맞물릴 수 있습니다. “외부는 Clash, 내부 파일 공유는 직통”처럼 역할을 나눠 쓰는지도 함께 확인하세요.

YAML 스케치: tun 블록만 발췌한 예시

아래는 참고용 발췌입니다. 사용 중인 코어 버전 문서와 키 호환성을 반드시 맞추고, 자신의 LAN 대역이 표준 RFC1918 밖(예: 캠퍼스망)이면 추가 route 예외가 필요할 수 있습니다.

# Illustrative tun section — verify keys against your core version
tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  strict-route: false
  bypass-private-network: true
  # exclude-interface:
  #   - tailscale0

auto-route: false로 바꾸고 OS에 정적 라우트를 수동으로 깔아 운용하는 방법도 있으나, 유지보수 부담이 큽니다. 먼저는 우회·제외·메트릭으로 자동 경로 안에서 해결할 수 있는지 보는 편이 낫습니다.

3단계: OS 라우팅 테이블과 메트릭·서비스 순서

앱 설정만으로 부족할 때는 OS가 실제로 어떤 인터페이스를 고르는지 봅니다. Windows PowerShell의 Get-NetRoute, Linux의 ip route, macOS의 netstat -rn로 default와 사설 대역 행을 비교하세요. Administrative distance / Metric이 더 큰 값일수록 우선순위가 낮다는 점을 헷갈리지 말고, 출력 해석 규칙을 OS 문서와 함께 확인합니다.

Tailscale 쪽에서 서브넷 라우터를 공유하면 회사 10.x 전체가 tailscale 인터페이스로 빨려 들어가 Clash의 “직통 우회”와 겹칠 수 있습니다. 이 경우 어느 터널이 그 대역의 소유자인지를 정책으로 한 번 더 정해야 합니다. 가정용이라면 대개 “집 LAN은 항상 물리 NIC 직통, 회사망만 Tailscale”처럼 역할을 나눕니다.

가상화 환경에서는 호스트·브리지 NAT가 또 하나의 층입니다. VM 안에서 같은 증상이 반복된다면 《VMware·Parallels·호스트》 글과 교차해 게이트웨이를 점검하세요.

증상 단서	우선 확인
공유기·NAS IP만 타임아웃	bypass-private-network, LAN static route, Clash 규칙의 잘못된 PROXY
Tailscale ping만 끊김	UDP·MTU, Tailscale 인터페이스 제외, 방화벽 프로파일
모든 앱 즉시 오프라인	default route 중복·메트릭 역전, strict-route 상호작용

Tailscale 측에서 같이 볼 것: Exit·서브넷·ACL

Tailscale Exit Node를 켜면 기본 인터넷 출구가 tailscale 터널로 옮겨집니다. 이미 Clash가 비슷한 역할을 한다면 이중 NAT·이중 출구가 되어 지연과 인증 오류가 늘 수 있습니다. 운영 목적이 “관리망 접속”이라면 Exit 대신 필요한 서브넷만 공유하는 편이 Clash와 충돌이 적습니다.

ACL에서 특정 태그에 넓은 IP 권한을 준 경우, 의도치 않은 경로가 열려 디버깅을 어렵게 만듭니다. 네트워크 이슈를 추적할 때는 우선 단순한 ACL/태그로 줄여 재현하는 것이 좋습니다. mesh 제품을 self-host하는 조직이라면 동일한 원리가 적용됩니다.

FAQ

켜는 순서가 영향을 주나요?

간혹 초기 라우트 설치 순서에 따라 메트릭이 달라질 수 있어, 완전 재부팅 후 Tailscale → Clash 혹은 그 반대로 한 번씩 비교해 볼 가치는 있습니다. 다만 근본 해결은 순서가 아니라 명시적 우회·제외·메트릭입니다.

Linux에서만 문제입니다

방화벽(nftables/iptables) 정책이 TUN 체인과 tailscale 체인 사이에서 패킷을 잘못 넘길 수 있습니다. distro별 네트워크 매니저도 라우트를 재적용합니다. 증상이 재부팅 직후에만 잠깐 정상이라면 후행 스크립트가 라우트를 덮는지 의심하세요.

당장 LAN만 살려야 합니다

Clash에서 TUN을 끄고 시스템 프록시·PAC만 쓰는 임시 회피도 가능하지만, 게임·일부 앱은 프록시를 무시합니다. 장기적으로는 TUN을 유지한 채 사설 우회를 정확히 거는 편이 낫습니다.

실무 체크리스트

규칙과 라우트가 보이는 클라이언트에서 마무리

mesh VPN과 범용 프록시 TUN은 “겉으로 비슷해 보이는데 겹치면 아주 먼저 깨지는” 조합입니다. 로그와 라우트 테이블에서 누가 어떤 대역을 소유하는지를 한 번 그림으로 정리해 두면 이후 트러블슈팅 시간이 크게 줄어듭니다.

Clash를 무료로 내려받고 TUN·규칙 기반 출구를 안정적으로 맞춰 보세요