Clash TUN 모드와 시스템 프록시 차이: 트래픽 처리 범위와 사용 사례

먼저 트래픽 처리 방식을 선택하고 분기 규칙을 확인하세요

웹 브라우저를 주로 사용한다면 시스템 프록시부터 적용하세요. 프록시 설정을 따르지 않는 앱이나 UDP 트래픽까지 처리해야 하거나 여러 앱의 연결을 한 번에 다루려면 TUN 모드를 고려하세요.두 방식의 차이는 트래픽이 mihomo 코어에 들어오는 경로에 있으며, 최종적으로 직접 연결할지 프록시 노드를 거칠지는 별도의 규칙이 결정합니다.

mihomo 코어를 사용할 때 연결은 세 단계로 나눠 볼 수 있습니다. 프록시 포트나 TUN 가상 네트워크 인터페이스로 들어온 뒤 규칙을 적용하고, 마지막으로 직접 연결하거나 프록시 노드로 전달합니다. 진입 경로·규칙·출구는 각각 독립된 단계이므로 진입 경로만 바꿔도 적용되는 규칙은 달라지지 않을 수 있습니다.

‘모든 트래픽 처리’는 TUN의 사용 목적을 요약한 말이지, 예외 없이 보장된다는 뜻은 아닙니다. 라우팅 제외 설정, 다른 가상 네트워크 인터페이스, IPv6 구성, 앱의 네트워크 인터페이스 지정, 클라이언트 구현 방식에 따라 실제 처리 범위가 달라집니다. 노드 연결이 TUN을 다시 거쳐 루프가 생기지 않도록 우회 경로도 올바르게 설정해야 합니다.

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

시스템 프록시의 작동 방식

클라이언트에서 ‘시스템 프록시’를 켜면 대개 운영체제의 프록시 설정이 127.0.0.1:7890 같은 로컬 주소를 가리키도록 변경됩니다. 이 설정을 읽는 앱은 해당 주소로 요청을 보내지만, 설정을 무시하는 앱은 기존 네트워크 경로로 연결합니다.

여기서 7890은 설정 예시일 뿐이며 모든 클라이언트의 고정 포트가 아닙니다. 클라이언트 설정에서 ‘혼합 포트’ 또는 ‘HTTP 포트’를 확인하세요. 다른 포트가 표시된다면 명령어와 앱의 프록시 설정에도 같은 값을 입력해야 합니다. 컨트롤러 포트를 프록시 포트로 착각하지 마세요.

• 브라우저: 대개 시스템 프록시 설정을 따르지만, 브라우저에 별도로 설정한 프록시가 시스템 설정을 덮어쓸 수 있습니다.
• 명령줄 도구: 데스크톱 시스템 프록시를 따른다고 보장할 수 없습니다. 프록시 옵션이나 환경 변수를 따로 지정해야 할 수 있습니다.
• 게임 및 실시간 통신: 기본 UDP 통신은 HTTP 시스템 프록시를 켜도 자동으로 코어에 들어오지 않습니다.
• 자체 네트워크 연결을 구현한 앱: 시스템 프록시를 우회하거나 로그인 화면만 프록시를 사용하고 실제 연결은 직접 연결할 수 있습니다.

명시적 프록시 설정으로 포트 확인하기

아래 명령은 요청을 로컬 HTTP 프록시를 거치도록 명시적으로 지정합니다. Windows 터미널에서는 이름이 같은 명령과 혼동되지 않도록 curl.exe를 사용하세요. 다른 운영체제에서는 보통 curl을 사용합니다.

curl --head --proxy http://127.0.0.1:7890 https://clash67.com/

실행한 뒤 클라이언트의 연결 기록을 확인하세요. 대상 도메인과 적용된 규칙이 보여야 요청이 실제로 코어에 들어간 것입니다. 응답 상태 코드는 해당 시점에 대상 사이트가 반환한 결과일 뿐, 모든 사이트에 접속할 수 있다는 뜻은 아닙니다. 이 테스트는 프록시를 명시적으로 지정하므로 운영체제에 시스템 프록시 설정이 올바르게 적용됐는지도 확인할 수 없습니다.

TUN 모드: 가상 네트워크 인터페이스와 라우팅으로 연결 처리

TUN은 3계층 가상 네트워크 인터페이스입니다. 클라이언트가 인터페이스를 만들고 라우팅을 설정하면 조건에 맞는 IP 패킷이 코어에서 처리됩니다. 앱이 HTTP 또는 SOCKS 프록시를 직접 지원하지 않아도 되므로, 시스템 프록시 설정을 따르지 않는 프로그램의 트래픽을 처리하는 데 적합합니다.

이 방식은 대개 높은 시스템 권한이 필요합니다. 데스크톱 클라이언트는 백그라운드 서비스나 권한 상승 프로세스로 네트워크 인터페이스와 라우팅을 설정할 수 있으며, Android 클라이언트는 시스템 VPN 권한을 받아 선택한 앱의 트래픽을 처리하는 경우가 많습니다. 플랫폼마다 구현과 설정 이름이 다르므로 데스크톱 설정을 휴대폰에 그대로 적용하면 안 됩니다.

mihomo TUN 설정 예시

아래 구성은 일반적인 진입 경로 옵션만 보여 주며 노드, 정책 그룹, 전체 DNS 설정은 포함하지 않습니다. 구독 설정 전체를 대체하지 말고 현재 사용 중인 설정에 병합하세요. 이미 tun 또는 같은 이름의 최상위 키가 있다면 중복으로 정의하지 말고 기존 항목을 수정하세요.

mixed-port: 7890
allow-lan: false
mode: rule

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

• mixed-port: 하나의 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받습니다. TUN을 켠 뒤에도 이 진입 경로를 유지할 수 있습니다.
• allow-lan: false: 로컬 네트워크에 프록시 서비스를 공개하지 않습니다. 이 기기에서 TUN을 사용하는 데 LAN 접근을 허용할 필요는 없습니다.
• stack: mixed: mihomo가 지원하는 혼합 프로토콜 스택을 선택합니다. ‘시스템 프록시도 함께 켠다’는 뜻은 아닙니다. 실제 지원 여부는 클라이언트에 포함된 코어를 확인하세요.
• auto-route: 코어가 관련 라우팅을 자동으로 설정합니다. 가상 네트워크 인터페이스만 만들고 라우팅이 올바르지 않으면 대상 트래픽을 처리하지 못할 수 있습니다.
• auto-detect-interface: 아웃바운드 네트워크 인터페이스를 자동으로 찾습니다. 네트워크 인터페이스가 여러 개인 환경에서는 로그와 실제로 선택된 출구를 확인하세요.
• dns-hijack: 조건에 맞는 기존 DNS 요청을 가로챕니다. 여기서는 UDP 53과 TCP 53을 포함하며, 앱 내부의 암호화된 DNS를 직접 복호화하지는 않습니다.

시스템 프록시와 TUN의 사용 사례 비교

게임: UDP를 처리해도 노드가 UDP를 지원하는 것은 아닙니다

TUN을 사용하면 게임 트래픽을 코어로 보낼 수 있지만, 출구도 해당 전송 방식을 지원해야 합니다. 노드나 서버가 UDP를 지원하지 않으면 TUN으로 전환해도 이 기능은 추가되지 않습니다. 연결 패널에서 게임 트래픽을 찾아 네트워크 유형, 대상 주소, 적용 규칙, 선택된 노드를 확인한 다음 문제가 진입 경로에 있는지 출구에 있는지 살펴보세요.

게임 런처, 로그인 서비스, 실제 플레이 연결은 서로 다른 도메인과 주소를 사용할 수 있습니다. 로그인이 성공했다고 해서 게임 트래픽까지 프록시를 거친다는 뜻은 아닙니다. 한 번의 지연 시간 측정만으로 TUN이 더 빠르다고 판단하지 마세요. 지연 시간은 네트워크 경로, 노드 부하, 대상 서버 위치에도 영향을 받습니다.

명령줄: 도구 하나만 쓴다면 프록시를 직접 지정

프록시 옵션을 지원하는 도구 하나만 실행한다면 프록시를 직접 지정하는 편이 추적하기 쉽고 다른 앱의 연결 경로도 바꾸지 않습니다. HTTP_PROXY, HTTPS_PROXY, ALL_PROXY의 적용 여부는 도구 구현에 따라 다릅니다. 변수 이름에 HTTPS가 포함되어 있어도 값에 HTTPS 프록시 프로토콜을 사용해야 한다는 뜻은 아닙니다.

UWP: 프록시 제한과 샌드박스 루프백 제한 구분하기

일부 UWP 앱은 로컬 프록시에 접속할 때 루프백 제한의 영향을 받을 수 있습니다. 이는 노드 사용 가능 여부와는 별개의 문제입니다. 시스템 프록시에서 연결되지 않는다면 먼저 브라우저로 로컬 포트가 정상인지 확인하세요. 그런 다음 앱별 루프백 권한이 필요한지 확인하거나 TUN으로 테스트할 수 있습니다. 앱 하나를 점검하려고 모든 앱의 권한을 한꺼번에 허용하지 마세요.

DNS와 Fake-IP: TUN 연결은 되지만 도메인이 열리지 않을 때

TUN은 연결을 처리하고 DNS는 도메인을 연결 가능한 주소로 변환합니다. 두 경로가 함께 작동해야 합니다. TUN을 켠 뒤 브라우저가 계속 로딩되거나 로그에 이름 확인 시간 초과가 표시되거나 앱마다 같은 도메인의 결과가 다르다면 DNS 문제일 수 있습니다. 이때 노드만 계속 바꿔도 진입 경로의 DNS 문제는 해결되지 않을 수 있습니다.

• DNS 모듈 활성화 여부 확인: 현재 실행 설정의 dns.enable과 클라이언트가 자체 설정으로 DNS 구성을 생성하는지 확인하세요.
• 53번 포트 가로채기 확인: 기존 DNS는 보통 UDP 53을 사용하지만 TCP 53을 사용할 수도 있습니다. 둘 중 하나만 확인하면 충분하지 않습니다.
• 앱 내부 암호화 DNS 확인: 앱이 HTTPS 또는 TLS로 DNS 요청을 보내면 53번 포트 가로채기 설정에 단순히 걸리지 않습니다.
• DNS 업스트림 연결 확인: DNS 업스트림에 연결할 수 있는지 확인하세요. 아직 설정되지 않은 프록시 연결에 업스트림이 의존해 순환 의존성이 생기지 않도록 해야 합니다.

Fake-IP는 조건에 맞는 도메인에 합성 주소를 반환하고, 코어가 도메인과 주소의 매핑을 관리합니다. 흔히 사용하는 주소 풀의 예는 198.18.0.1/16입니다. 이런 주소가 DNS 결과에 표시되어도 반드시 오류인 것은 아닙니다. 다만 해당 연결이 코어로 돌아와야 대상 주소를 올바르게 확인할 수 있습니다.

TUN을 끈 뒤에도 앱이 합성 주소를 캐시하고 있으면 잠시 접속되지 않을 수 있습니다. 앱 연결을 다시 설정하고 운영체제 방식으로 DNS 캐시를 지우세요. Windows에서는 터미널에서 ipconfig /flushdns를 실행할 수 있습니다. 브라우저 자체의 DNS 캐시는 별도로 지워야 할 수 있습니다. 로컬 네트워크 검색, 기기 관리 또는 특정 내부망 도메인에 문제가 있다면 모든 도메인을 필터 목록에 추가하지 말고 실제 필요에 따라 Fake-IP 필터와 직접 연결용 DNS 규칙을 확인하세요.

네 단계로 확인: 진입 경로, 규칙, 출구, 복구

1. 먼저 정상 작동하는 기준 상태를 만드세요.

   TUN을 끄고 구독이 활성화되어 있는지 확인한 다음 사용 가능한 노드를 선택하고, 프록시를 명시한 명령으로 로컬 포트를 테스트하세요. 클라이언트의 연결 패널에서 대상 도메인, 적용 규칙, 정책 그룹을 기록합니다. 기준 상태부터 연결되지 않는다면 TUN을 점검하기 전에 구독, 포트 또는 노드 문제를 해결하세요.

2. TUN의 트래픽 처리를 따로 검증하세요.

   필요한 서비스나 시스템 권한을 활성화하고 TUN을 켠 다음 시스템 프록시는 잠시 끄세요. 테스트 도구가 프록시 환경 변수를 상속하지 않는지도 확인합니다. curl --head --noproxy "*" https://clash67.com/을 실행하고 연결 기록을 확인하세요. 여기서 --noproxy "*"는 curl이 명시적 프록시를 사용하지 않도록 할 뿐, 운영체제의 TUN 라우팅을 우회하지는 않습니다.

3. 규칙과 출구를 확인하세요.

   방금 보낸 요청을 찾아 예상한 규칙에 일치했는지, 최종적으로 직접 연결했는지 프록시 노드를 사용했는지 확인하세요. 웹페이지가 열린다는 것은 연결에 성공했다는 뜻일 뿐입니다. 원래 직접 연결할 수 있는 대상이라면 페이지가 열린 것만으로 프록시 출구가 작동한다고 증명할 수 없습니다.

4. 복구와 특수 네트워크를 테스트하세요.

   TUN을 끈 뒤 다시 연결해 일반 네트워크가 복구되는지 확인하세요. 이어서 로컬 네트워크 기기, 회사 내부망, IPv6 대상, 게임 UDP를 테스트합니다. 한 번에 설정 하나만 바꾸고 변경 전후를 기록하세요. DNS, 라우팅, 정책 그룹을 동시에 조정하면 원인을 파악하기 어렵습니다.

자주 묻는 질문: 동시 사용, 네트워크 끊김, LAN 접근

최종 선택은 연결 기록으로 확인하세요. 시스템 프록시로 충분하다면 단순한 설정을 유지하세요. 더 많은 앱을 처리해야 한다면 TUN을 켜고 권한, 라우팅, DNS, UDP 출구를 하나씩 확인합니다. 코어와 규칙 필드는 사이트의 프로토콜 참고 자료에서 mihomo 코어 설명을 확인하세요.