이 글의 목차
원격 접속과 일상적인 프록시를 함께 쓸 때는 기기 주소로 접속이 안 되는지, 기기 이름이 안 되는지, 인터넷 접속이 안 되는지 구분하기 어려울 수 있습니다. 각 결과를 따로 기록하면 라우팅, 이름 해석, 기본 접속 경로 중 어디를 확인할지 판단할 수 있습니다. 각각은 정상인 두 도구도 같은 기기에서 함께 사용할 때의 작동을 확인해야 합니다.
동시 실행할 때만 끊긴다면 경로와 기기 이름 해석 비교
Tailscale과 Clash TUN을 함께 실행할 때만 실패하는 경우에 아래 표로 공통 라우팅, DNS, 기본 접속 경로를 확인하세요. 어느 한 도구가 단독 실행에서도 실패한다면 그 도구 자체의 설정을 점검해야 합니다. 이를 동시 실행에 따른 충돌로 취급하지 마세요.
Tailscale만 켠 상태, Clash만 켠 상태, 둘 다 켠 상태를 각각 기록하세요. 각 상태에서 tailnet IP 하나, tailnet 기기 이름 하나, LAN 주소 하나, 공용 인터넷 주소 하나를 테스트합니다. IP와 기기 이름의 결과가 다르면 라우팅 문제와 MagicDNS 문제를 이미 구분할 수 있습니다.
세 가지 비교 결과가 알려 주는 것
| 결과 | 가능성이 높은 문제 |
|---|---|
| 100.x 주소와 기기 이름이 모두 연결되지 않음 | Tailscale 대역을 TUN 또는 기본 경로가 가져감 |
| 100.x 주소에는 접속되지만 기기 이름은 연결되지 않음 | MagicDNS 또는 Clash DNS의 인계 순서 |
| tailnet은 정상이나 공용 인터넷이 끊김 | 두 도구가 기본 출구 또는 exit node를 두고 경쟁함 |
| 특정 LAN 대역만 연결되지 않음 | Tailscale 서브넷 경로와 로컬 네트워크 대역이 겹침 |
어떤 네트워크 어댑터가 대상 대역을 가져갔는지는 라우팅 테이블에서 확인할 수 있습니다
Tailscale은 기기에 100.64.0.0/10 범위의 주소를 할당하고 관리자가 승인한 서브넷 경로를 받을 수도 있습니다. exit node를 선택하면 기본 경로도 설치합니다. Clash TUN도 라우팅을 작성하므로 두 개의 스위치만 보고 충돌을 판단할 수는 없습니다.
문제가 발생한 상태에서 운영체제에 맞는 아래 명령의 결과를 저장하고 각 도구를 단독 실행했을 때와 비교하세요. Linux에서는 ip route show table all과 ip rule로 정책 라우팅을 확인해야 하며 주 테이블만 보면 안 됩니다.
100.64.0.0/10, 게시한 서브넷, 홈 LAN, 기본 경로의 인터페이스와 테이블·규칙이 이를 선택하는 방식을 확인하세요. 동일한 테이블 안에서 같은 접두사의 metric을 비교합니다.
# Windows
route print
# Linux
ip route show table all
ip rule
# macOS
netstat -rn기본 인터넷 출구는 한 도구에만 맡기세요
Tailscale exit node와 Clash TUN은 모두 기본 인터넷 트래픽에 영향을 줄 수 있습니다. Tailscale로 집의 NAS에 접속하고 공용 인터넷 분리 라우팅은 Clash가 맡는 것이 목적이라면 이 기기에서 Tailscale exit node를 선택하지 마세요.
회사가 모든 인터넷 트래픽을 지정된 Tailscale exit node로 보내도록 요구한다면 Clash는 특정 앱이나 프록시 포트만 처리하게 하고 이런 조합이 조직 정책에 맞는지 확인하세요. 두 도구가 모두 기본 출구를 설정하면 가끔 연결이 성공해도 경로 우선순위(metric)가 일시적으로 유효한 것일 수 있으며 설정이 안정적이라는 뜻은 아닙니다.
tailnet 제외 범위와 서브넷 중복 처리
Clash Verge Rev처럼 TUN에서 사용자 지정 대역을 제외할 수 있는 클라이언트에서는 100.64.0.0/10, 실제로 사용하는 홈 LAN, Tailscale 관리 콘솔에서 승인한 advertised routes를 제외 범위에 추가할 수 있습니다.
다른 사람의 모든 사설 대역을 그대로 복사하지 마세요. 제외 범위가 지나치게 넓으면 Clash가 처리해야 할 연결까지 직접 빠져나갑니다.
Mihomo 규칙에서도 해당 대역을 명시적으로 DIRECT 처리할 수 있지만 라우팅 계층의 제외와 규칙 계층의 DIRECT는 완전히 같지 않습니다. 연결이 먼저 코어에 들어와야 규칙이 판단할 수 있습니다. 100.x 요청이 Clash 연결 기록에 전혀 나타나지 않으면 시스템 라우팅을 바로 확인하고, 나타나면서 프록시에 일치하면 규칙을 조정하세요.
자신의 네트워크에 맞게 입력해야 합니다
- 100.64.0.0/10 tailnet 주소 범위
- 집 또는 사무실에서 실제 사용하는 LAN 대역
- Tailscale 콘솔에서 승인한 서브넷 경로
- Docker, WSL 또는 가상 머신에서 실제로 tailnet과 겹치는 대역
Tailscale 서브넷 경로가 192.168.1.0/24를 게시하는데 현재 카페나 집에서도 192.168.1.0/24를 사용하면 시스템은 주소만 보고 어느 쪽에 접속할지 구분할 수 없습니다. Docker와 WSL2도 자체 사설 대역을 추가하므로 충돌이 컨테이너나 하위 시스템에서만 나타날 수도 있습니다.
서브넷이 겹치면 먼저 직접 관리할 수 있는 LAN, Docker, 가상 머신의 주소 계획을 바꾸세요. 같은 서브넷의 경로 우선순위를 계속 높이는 방식은 네트워크 전환, 절전 복귀, 업데이트 후 다시 실패할 수 있습니다.
IP에는 접속되지만 기기 이름은 실패하면 라우팅이 아니라 MagicDNS를 점검하세요
100.x 주소에 직접 접속된다면 tailnet으로 가는 경로는 대체로 존재합니다. 이때 기기 이름 확인이 실패하면 Clash DNS, 브라우저 DoH 또는 시스템 resolver가 tailnet 이름을 Tailscale DNS 설정에 넘기지 않았을 가능성이 큽니다.
tailscale status로 대상 기기의 주소를 확인한 뒤 운영체제의 기본 이름 확인 도구로 짧은 이름과 전체 tailnet 이름을 비교하세요. 일부 플랫폼에서 nslookup은 시스템 DNS 설정을 읽지 않으므로 그 결과만으로 MagicDNS가 작동하지 않는다고 판단할 수는 없습니다.
macOS에서는 dscacheutil -q host -a name DEVICE_NAME을 실행하세요. DEVICE_NAME을 짧은 이름으로 바꾸고 name과 ip_address를 확인한 뒤, 반환된 전체 tailnet 이름으로 다시 조회해 주소를 대상 기기의 주소와 비교하세요.
점검 중에는 브라우저의 별도 DoH를 끄고 Clash의 nameserver-policy 또는 로컬 도메인 제외 설정을 확인하세요. tailnet 이름을 공용 DNS로 전달하지 마세요.
절전 복귀나 Wi-Fi 전환 뒤 실패하면 재연결 후 경로와 이름 해석 비교
노트북이 절전에서 깨어나거나 유선에서 Wi-Fi로 전환하거나 휴대폰 핫스팟에 연결되면 두 클라이언트가 재연결될 때까지 기다린 뒤 경로와 이름 해석 결과를 비교하세요. 한 도구를 일정한 순서로 다시 시작했을 때 복구된다면 시작 또는 재연결 과정을 확인할 단서입니다. 다만 복구됐다는 사실만으로 원인을 확정할 수는 없으며, 전후 경로와 이름 해석 기록으로 무엇이 바뀌었는지 확인해야 합니다.
두 클라이언트를 업데이트한 뒤에도 반복된다면 자동 시작 시 경쟁을 줄이세요. 시스템 네트워크가 준비된 뒤 필요한 터널을 시작하고 Tailscale exit node를 동시에 자동 선택하지 않도록 합니다. 매번 전체 네트워크 초기화를 실행하면 문제와 무관한 설정까지 더 많이 지워집니다.
Tailscale 내부 네트워크 접속과 Clash의 인터넷 트래픽 라우팅이 모두 정상인가요?
같은 차례에 검증할 항목
tailnet IP 접속
100.x 경로를 여전히 Tailscale이 맡고 있음을 확인합니다.
tailnet 이름으로 접속
MagicDNS 또는 전용 이름 확인을 계속 사용할 수 있음을 확인합니다.
게시된 서브넷에 접속
승인된 subnet route를 Clash가 가져가지 않았는지 확인합니다.
공용 인터넷에 접속하고 Clash 기록 확인
일반 분리 라우팅이 여전히 예상 정책으로 처리됨을 확인합니다.
tailnet IP, 기기 이름, 게시된 서브넷, 인터넷 요청 중 실패한 항목에 맞춰 경로, DNS, 서브넷, 기본 출구를 확인하세요.