트래픽 처리와 아웃바운드 규칙부터 구분하기

시스템 프록시와 TUN은 모두 앱에서 발생한 연결을 Clash 코어로 전달하는 방식을 다룹니다. 코어에 들어온 뒤에는 실행 모드, 라우팅 규칙, 정책 그룹에 따라 직접 연결하거나 프록시를 거치거나 차단합니다. TUN을 켠다고 모든 연결이 프록시를 이용하는 것은 아니며, 시스템 프록시를 켜도 모든 프로세스가 이를 따르는 것은 아닙니다.

이 글에서는 mihomo 코어를 사용하는 Clash 클라이언트를 예로 듭니다. 클라이언트와 코어, 운영체제에 따라 TUN 구현은 다를 수 있으므로 특정 클라이언트의 토글 이름을 모든 소프트웨어에 그대로 적용하면 안 됩니다. 설정 전에 클라이언트의 코어 정보를 확인해 실제로 mihomo가 실행 중인지 확인하고, 지원되는 설정 항목을 살펴보세요.

시스템 프록시: 앱이 로컬 포트에 직접 연결

브라우저는 어떻게 연결을 Clash에 전달할까요?

클라이언트에서 ‘시스템 프록시’를 켜면 일반적으로 운영체제의 HTTP 및 HTTPS 프록시 주소가 로컬 리스닝 주소로 변경됩니다. 예를 들어 설정의 mixed-port: 7890은 하나의 포트에서 HTTP 프록시와 SOCKS 요청을 모두 받는다는 뜻입니다. 여기서 7890은 예시 값이므로 확인할 때는 현재 적용된 설정을 기준으로 하세요.

시스템 프록시를 지원하는 브라우저는 설정을 읽은 뒤 127.0.0.1:7890에 먼저 연결합니다. HTTPS 사이트에 접속할 때는 보통 HTTP CONNECT로 터널을 만든 다음, 그 안에서 TLS 통신을 합니다. 일반 프록시 전달에는 웹사이트 트래픽을 복호화하기 위한 루트 인증서를 브라우저에 설치할 필요가 없습니다.

시스템 프록시를 지원하는 앱
  → 127.0.0.1:7890
  → mihomo 규칙 매칭
  → DIRECT 또는 선택한 프록시 노드

시스템 설정을 모든 프로그램이 사용하는 것은 아닙니다

따라서 ‘브라우저에서는 접속되지만 터미널에서는 안 된다’고 해서 노드가 작동하지 않는다고 단정할 수는 없습니다. 두 앱이 서로 다른 경로로 트래픽을 전달하고 있을 수 있습니다. 마찬가지로 Windows의 WinHTTP 프록시와 사용자 인터페이스의 프록시 설정은 별개이므로, netsh winhttp show proxy 결과만으로 브라우저의 프록시 사용 여부를 판단할 수 없습니다.

TUN: 가상 네트워크 어댑터와 라우팅을 통한 트래픽 처리

TUN은 3계층 가상 네트워크 인터페이스입니다. 활성화하면 클라이언트나 보조 서비스가 가상 네트워크 어댑터를 만들고 설정에 따라 라우팅을 조정합니다. 목적지 주소가 해당 라우트와 일치하는 IP 패킷은 코어로 전달되어 처리되므로, 앱이 HTTP 프록시나 SOCKS 프로토콜을 이해할 필요가 없습니다.

앱에서 IP 패킷 전송
  → 운영체제의 라우팅 결정
  → TUN 가상 네트워크 어댑터
  → mihomo 네트워크 스택 및 규칙 매칭
  → DIRECT 또는 선택한 프록시 노드

이 경로를 사용하면 시스템 프록시를 따르지 않는 앱도 라우팅 규칙을 거칠 수 있습니다. 그렇다고 모든 프로토콜을 어떤 프록시 노드로든 전달할 수 있는 것은 아닙니다. 예를 들어 게임 음성 채팅에는 UDP가 필요하므로 노드 프로토콜과 서버, 관련 설정이 UDP를 지원해야 합니다. ICMP 응답이 예상대로 오는지도 HTTPS 프록시의 정상 작동 여부를 판단하는 기준이 될 수 없습니다.

자주 쓰이는 설정 항목 세 가지의 역할

항목역할확인할 사항
auto-routeTUN으로 연결되는 라우트를 자동 설정회사 VPN이나 다른 가상 네트워크 어댑터와 충돌하는지
auto-detect-interface아웃바운드에 사용할 네트워크 인터페이스 자동 감지Wi-Fi와 유선 네트워크를 전환할 때 올바른 인터페이스를 선택하는지
stackTUN에서 사용할 네트워크 스택 선택코어 지원 여부와 시스템 호환성을 고려해 선택

네트워크 어댑터 생성과 라우트 변경에는 보통 관리자 권한, 시스템 서비스 또는 플랫폼 권한이 필요합니다. 클라이언트의 ‘서비스 모드’는 보조 서비스가 이런 작업을 맡도록 하는 기능이지, 프록시 서버를 뜻하거나 서비스 설치만으로 노드가 작동한다는 의미는 아닙니다. TUN 스위치가 바로 꺼진다면 노드부터 바꾸지 말고 권한, 서비스, 어댑터 생성 로그를 먼저 확인하세요.

DNS와 fake-ip: 도메인은 라우팅에 어떻게 쓰일까요?

시스템 프록시를 사용하는 경우 앱은 도메인을 로컬 프록시에 전달할 수도 있고, 먼저 로컬에서 도메인을 조회할 수도 있습니다. 동작 방식은 앱과 프록시 프로토콜에 따라 다릅니다. TUN이 받는 것은 IP 패킷이므로, 코어에 도메인 매핑이 없으면 목적지 IP만으로 앱이 원래 접속하려던 도메인을 항상 정확하게 알아낼 수는 없습니다.

fake-ip 모드는 도메인에 합성 주소를 반환하고 도메인과 주소의 대응 관계를 저장합니다. 예를 들어 mihomo에서 자주 사용하는 198.18.0.0/16 범위는 이런 매핑에 쓰이며, 웹사이트의 실제 접속 주소를 뜻하지 않습니다. 앱이 합성 주소에 연결하면 코어가 도메인을 찾아내고, DOMAIN-SUFFIX 같은 규칙을 매칭에 사용할 수 있습니다.

기존 Profile에 설정 조각을 병합하세요

아래는 설정 항목 간 관계를 설명하기 위한 mihomo YAML 예시입니다. 노드와 정책 그룹이 포함되어 있지 않으므로 완전한 구독 설정으로 사용할 수 없습니다. IPv4 DNS 예시를 사용하므로 기존 Profile을 그대로 덮어쓰지 말고 최상위 dns 또는 tun 항목을 중복으로 추가하지 마세요. 클라이언트에서 오버라이드나 병합을 사용한다면 최종 적용된 설정을 확인하세요.

mixed-port: 7890
mode: rule

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5

dns-hijack의 any:53은 TUN이 캡처한 해당 기존 DNS 요청을 가로챈다는 뜻이며 기본적으로 UDP에 적용됩니다. TCP DNS도 처리하려면 코어 문서를 참고해 tcp://any:53을 추가할 수 있습니다. 모든 DNS 프로토콜을 강제로 로컬 조회로 바꾸는 설정은 아닙니다. 브라우저 내장 DoH는 보통 HTTPS를 사용하므로 포트 53 규칙만으로 처리할 수 없습니다.

선택 방법: 먼저 앱의 필요에 따라 판단하세요

사용 사례우선 시도할 방식확인 방법
브라우저 및 시스템 프록시를 읽는 데스크톱 앱시스템 프록시웹페이지를 열고 클라이언트 연결 기록에 해당 도메인이 표시되는지 확인
단일 명령줄 도구도구 자체의 프록시 옵션로컬 포트를 명시적으로 지정하고 프록시를 지정하지 않은 경우와 결과 비교
시스템 프록시를 무시하는 앱TUN시스템 프록시를 끈 뒤 앱의 새 연결이 계속 코어로 들어오는지 확인
게임, 음성 채팅 등 UDP 앱TUN 및 UDP를 지원하는 노드UDP 연결, 정책 그룹 선택, 실제 세션이 정상인지 확인
회사 VPN을 함께 사용하는 경우기존 네트워크 구성을 우선 유지내부망 라우트, 도메인 조회, 주소 제외 항목을 확인한 뒤 하나씩 활성화

두 방식을 동시에 켤 수도 있지만, 처음 문제를 진단할 때는 권장하지 않습니다. 시스템 프록시를 지원하는 앱은 로컬 프록시 포트에 연결하고, 다른 앱은 TUN을 사용할 수 있습니다. 연결 기록이 모두 정상으로 보여도 실제로 어떤 경로가 적용됐는지 구분하기 어려워집니다. 먼저 한 가지 경로를 검증한 뒤 필요에 따라 조합하세요.

‘TUN을 켠 뒤 지연 시간이 줄었다’는 이유만으로 일반적인 결론을 내려서도 안 됩니다. TUN은 로컬에서 트래픽을 처리하는 경로를 바꾸지만, 원격 출구의 위치와 회선 부하, 서버 상태는 여전히 노드에 따라 달라집니다. 비교할 때는 대상 사이트, 노드, 규칙 모드, 테스트 도구를 고정해 가상 네트워크 어댑터가 아닌 노드 변경의 영향을 구분하세요.

전환 절차: 한 번에 한 가지씩 변경하세요

  1. 현재 설정을 저장합니다. Profile 이름, 로컬 포트, 실행 모드, 정책 그룹 선택을 기록하세요. 구독 업데이트 후에도 복구할 수 있도록 사용자 지정 오버라이드도 복사해 두세요.
  2. 먼저 로컬 프록시 연결을 확인합니다. TUN을 잠시 끄고 코어는 실행한 상태에서 프록시를 명시하는 명령으로 테스트 주소에 접속하세요. 실패하면 포트, 노드 또는 규칙 문제부터 확인합니다.
  3. 시스템 프록시를 확인합니다. 시스템 프록시를 켜고 브라우저에서 같은 주소를 연 뒤 클라이언트의 연결 화면에서 도메인, 적용된 규칙, 실제 아웃바운드를 확인하세요. 테스트가 끝나면 시스템 프록시를 끕니다.
  4. TUN만 따로 활성화합니다. 클라이언트 안내에 따라 권한을 허용하거나 서비스를 시작하세요. 네트워크 어댑터 생성 또는 라우트 설정 실패 로그가 없는지 확인한 뒤 프록시를 설정하지 않은 앱으로 테스트합니다.
  5. 업무 외 연결도 확인합니다. LAN 기기, 회사 내부망, 음성 채팅, 절전 모드 해제 후 네트워크를 테스트하세요. 직접 연결로 유지해야 할 트래픽이 원격 노드로 잘못 전달되지 않는지 확인합니다.

명령어로 포트 문제와 라우팅 문제 구분하기

아래 주소는 테스트용 예시입니다. Windows에서는 curl.exe, macOS와 Linux에서는 curl을 사용할 수 있습니다. 예시 포트를 현재 설정의 실제 값으로 바꾸세요. 두 번째 명령은 해당 요청에 명시한 프록시의 영향을 제거하지만, TUN이 켜져 있으면 패킷이 여전히 가상 네트워크 어댑터를 통해 전달될 수 있습니다.

# 로컬 HTTP 프록시 연결 테스트
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com/

# curl 프록시를 사용하지 않고 시스템 라우팅 경로 확인
curl --proxy "" --noproxy "*" --connect-timeout 10 -I https://example.com/

HTTP 상태 코드를 받았다는 사실은 해당 요청에 응답이 왔다는 뜻일 뿐, 프록시를 거쳤다는 것을 단독으로 증명하지는 않습니다. 클라이언트의 연결 화면에서 요청이 표시되는지, 어떤 규칙이 적용됐는지, 최종 아웃바운드가 DIRECT인지 프록시 노드인지 확인하세요. 브라우저가 기존 연결을 재사용할 수 있으므로 전환 후에는 기존 연결을 닫거나 테스트 앱을 다시 시작하세요.

자주 발생하는 문제: 연결 경로, DNS, 라우팅 순서로 확인

시스템 프록시는 되지만 TUN은 연결되지 않는 경우

웹은 되지만 게임이나 음성 채팅이 연결되지 않는 경우

먼저 앱의 연결이 TUN으로 들어오는지 확인한 다음, 해당 정책 그룹에서 실제 선택된 노드가 UDP를 지원하는지 확인하세요. 웹페이지는 주로 TCP 또는 브라우저 자체의 연결 경로를 테스트하므로 게임의 UDP 연결을 보장하지 않습니다. 노드 지연 시간 테스트 결과만 확인해서도 안 됩니다. 테스트 URL 접속 성공과 실제 서비스 프로토콜의 정상 작동은 별개입니다.

클라이언트를 종료한 뒤에도 인터넷에 연결되지 않는 경우

먼저 시스템 프록시가 더 이상 실행되지 않는 127.0.0.1 포트를 가리키는지 확인한 뒤, 클라이언트에서 TUN을 정상적으로 끄고 라우트와 DNS 설정이 복구됐는지 살펴보세요. 클라이언트가 비정상 종료됐다면 다시 실행한 다음 정상 종료를 시도하세요. 그래도 문제가 해결되지 않으면 로그를 저장하고 운영체제의 네트워크 설정을 하나씩 복구하세요. 네트워크 어댑터나 라우트를 무작정 전부 삭제하지 마세요.