먼저 계층부터 확인하기: 프록시 설정과 가상 네트워크 인터페이스

시스템 프록시와 TUN 모드는 모두 트래픽을 Clash로 보낼 수 있지만, 진입점이 위치한 네트워크 계층은 다릅니다. 시스템 프록시는 운영체제에 HTTP, HTTPS 또는 SOCKS 프록시 주소를 등록하고, 애플리케이션이 해당 설정을 읽은 뒤 요청을 Clash의 수신 포트로 직접 전달하는 방식입니다. 반면 TUN 모드는 가상 네트워크 인터페이스를 만들고 시스템 라우팅과 함께 IP 패킷을 Clash 코어로 전달합니다. 전자는 애플리케이션이 프록시 설정을 따르는지에 좌우되고, 후자는 라우팅이 대상 트래픽을 포함하는지가 핵심입니다.

이 차이가 실제 적용 범위를 결정합니다. 브라우저, 일부 데스크톱 메신저와 시스템 네트워크 인터페이스를 따르는 프로그램은 대체로 시스템 프록시를 바로 사용할 수 있습니다. 반면 명령줄 도구, 게임, 독립 업데이트 프로그램, 자체 네트워크 스택을 사용하는 소프트웨어와 UDP만 전송하는 프로그램은 시스템 프록시를 무시할 수 있습니다. TUN은 더 낮은 계층에 위치하므로 이러한 프로그램이 생성한 TCP 또는 UDP 트래픽도 대체로 받아들인 뒤, mihomo 같은 코어가 규칙에 따라 프록시, 직접 연결 또는 차단을 선택할 수 있습니다.

두 모드는 속도 단계도 아닙니다. TUN을 켠다고 노드 대역폭이 자동으로 늘어나지 않으며, 시스템 프록시를 사용한다고 연결 성능이 반드시 떨어지는 것도 아닙니다. 속도는 로컬 네트워크, 노드 부하, 회선 품질, 전송 프로토콜, 대상 사이트와 DNS 결과에 좌우됩니다. 모드 선택은 주로 “어떤 트래픽을 코어로 보낼지”와 “도메인 정보를 연결과 어떻게 연결할지”를 결정하는 문제입니다.

비교 항목 시스템 프록시 TUN 모드
가로채기 진입점 애플리케이션이 운영체제 프록시 설정을 읽음 가상 인터페이스와 시스템 라우팅
애플리케이션 적용 범위 애플리케이션의 프록시 지원 여부에 따라 달라짐 더 많은 TCP 및 UDP 프로그램에 적용 가능
권한 요구 사항 일반적으로 현재 사용자 프록시 설정만 변경하면 됨 일반적으로 관리자 권한 또는 시스템 네트워크 확장 기능이 필요함
DNS 연동 일부 요청은 도메인 정보를 직접 전달할 수 있음 대개 DNS 하이재킹 및 fake-ip와 함께 사용
문제 해결 난이도 진입점이 적고 끈 뒤 확인하기 쉬움 라우팅, 인터페이스, DNS와 방화벽을 함께 확인해야 함

시스템 프록시: 애플리케이션이 로컬 포트에 직접 연결

Clash 그래픽 클라이언트의 “시스템 프록시” 스위치는 일반적으로 운영체제의 HTTP 및 HTTPS 프록시 주소를 로컬 루프백 주소와 코어 수신 포트로 설정합니다. 예를 들어 127.0.0.1:7890을 사용할 수 있습니다. 클라이언트가 mixed-port를 사용하면 해당 포트에서 HTTP와 SOCKS 연결을 동시에 받을 수 있습니다. 애플리케이션이 프록시 설정을 가져오면 먼저 이 로컬 포트에 연결하고, Clash가 대상 주소를 읽어 규칙을 매칭합니다.

브라우저로 HTTPS 웹사이트에 접속하는 경우를 예로 들면, 브라우저는 일반적으로 대상 도메인과 포트가 포함된 CONNECT 요청을 HTTP 프록시에 보냅니다. Clash는 이 도메인을 DOMAIN, DOMAIN-SUFFIX 또는 규칙 세트와 매칭할 수 있습니다. 터널이 구성된 뒤에도 HTTPS 콘텐츠는 종단 간 암호화 상태로 유지되며, 트래픽을 가로챈다고 해서 웹페이지 내용이 복호화되는 것은 아닙니다. 일반 HTTP 요청에서는 프록시가 요청 대상에서 도메인 정보를 얻을 수 있습니다.

시스템 프록시의 장점은 변경 범위가 명확하다는 것입니다. 프로그램이 시스템 설정을 따르면 시스템 라우팅을 수정하거나 가상 네트워크 인터페이스를 만들 필요가 없습니다. 처음 설정할 때, 브라우저 접속, 문서 다운로드와 일반적인 데스크톱 애플리케이션에는 우선 이 방식을 사용할 수 있습니다. 스위치를 끄면 클라이언트가 기존 시스템 프록시 상태를 복원해야 하므로, 문제가 프록시 경로에서 발생했는지 로컬 직접 연결에서 발생했는지 빠르게 판단하는 데도 적합합니다.

시스템 프록시의 일반적인 적용 누락 사례

  • 애플리케이션이 시스템 설정을 무시함: 일부 프로그램은 자체 프록시 옵션을 내장하고 있어, 설정하지 않으면 네트워크에 직접 연결합니다.
  • 명령줄 환경에 프록시가 전달되지 않음: 터미널 도구는 HTTP_PROXY, HTTPS_PROXY 또는 자체 설정 파일만 읽을 수 있습니다.
  • UDP 트래픽은 HTTP 프록시를 통과하지 않음: 게임, 음성 통화와 일부 실시간 통신 기능은 계속 직접 연결될 수 있습니다.
  • 백그라운드 서비스가 다른 계정으로 실행됨: 시스템 서비스가 현재 데스크톱 사용자의 프록시 설정을 읽는다는 보장은 없습니다.
  • 애플리케이션이 자체 DNS 및 연결 정책을 고정해 사용함: 도메인 확인과 이후 연결이 시스템 프록시 진입점을 우회할 수 있습니다.

따라서 “브라우저는 정상인데 특정 프로그램만 연결되지 않는” 상황에서 곧바로 노드를 바꿀 필요는 없습니다. 먼저 해당 프로그램에 프록시 옵션이 있는지 확인한 다음 HTTP 또는 SOCKS5를 지원하는지 살펴보세요. 프로그램이 프록시를 전혀 지원하지 않거나 UDP까지 함께 가로채야 할 때 TUN 모드를 고려하면 됩니다.

TUN 모드: 라우팅으로 IP 패킷을 코어에 전달

TUN은 3계층 가상 네트워크 인터페이스입니다. 활성화하면 클라이언트 또는 mihomo 코어가 가상 네트워크 인터페이스를 만들고, 설정에 따라 라우팅을 추가해 지정된 범위의 IP 패킷을 해당 인터페이스로 보냅니다. 코어는 패킷에서 출발지 주소, 대상 주소와 프로토콜 유형을 읽고 DNS 매핑, 연결 스니핑 및 규칙을 함께 적용합니다. 프록시 노드로 전달해야 할 때는 원래 연결을 해당 프록시 프로토콜 연결로 변환하고, 규칙이 DIRECT에 매칭되면 실제 네트워크 인터페이스를 통해 대상에 직접 연결합니다.

가상 인터페이스, 라우팅 테이블과 네트워크 스택을 다루므로 TUN에는 일반적으로 더 높은 권한이 필요합니다. Windows 클라이언트는 관리자 권한으로 설치하거나 서비스를 시작해야 할 수 있고, macOS는 네트워크 확장 승인 또는 시스템 자격 증명 입력을 요구할 수 있습니다. Linux에서는 보통 /dev/net/tun에 접근하고 라우팅 설정에 필요한 권한을 갖추거나, 시스템 서비스가 이러한 작업을 수행해야 합니다. 구체적인 방식은 클라이언트 구현에 따라 다르므로, 화면에 스위치가 표시되는지만으로 TUN이 실제로 작동한다고 판단해서는 안 됩니다.

mihomo 설정의 TUN 섹션에는 일반적으로 스택 유형, 자동 라우팅, 인터페이스 탐지와 DNS 하이재킹 옵션이 포함됩니다. 다음 예시는 필드 간 관계를 설명하기 위한 것이며, 실제 사용 시에는 클라이언트가 생성한 설정과 현재 코어 문서를 기준으로 해야 합니다.

mixed-port: 7890
mode: rule

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

auto-route는 트래픽 가로채기 라우팅을 자동으로 설정하고, auto-detect-interface는 실제 아웃바운드 인터페이스를 식별해 프록시 노드 자체의 연결이 다시 TUN으로 들어가는 것을 방지합니다. 운영체제와 코어 버전에 따라 지원되는 스택 유형이 다를 수 있으며, 흔히 system, gvisor와 mixed를 사용합니다. 스택 유형은 로컬에서 패킷이 처리되는 경로에 영향을 주지만, 노드 품질이나 규칙 설정을 대신할 수는 없습니다.

프록시 루프 방지

TUN의 가로채기 범위가 너무 넓을 때는 Clash에서 프록시 서버로 연결하는 트래픽이 실제 인터페이스를 통해 나가도록 해야 합니다. 이 연결이 다시 가상 네트워크 인터페이스로 라우팅되면 프록시 루프가 발생합니다. TUN을 켠 뒤 모든 연결이 시간 초과되거나, 로그에 같은 대상에 대한 연결이 반복해서 생성되거나, 잠시 동안 시스템 네트워크를 전혀 사용할 수 없는 현상으로 나타날 수 있습니다. 자동 라우팅과 인터페이스 탐지가 보통 이 문제를 처리하지만, 여러 네트워크 인터페이스, VPN, 가상 머신, 컨테이너와 수동 라우팅 환경에서는 명시적인 제외 설정이 필요할 수 있습니다.

DNS 처리: 도메인 규칙이 정확히 매칭되는가

프록시 규칙은 도메인을 기준으로 작성되는 경우가 많지만, TUN이 받는 원시 데이터 패킷에는 주로 대상 IP만 포함됩니다. DOMAIN-SUFFIX 같은 규칙이 제대로 작동하려면 코어가 “DNS 조회 결과와 이후 연결” 사이의 대응 관계를 만들어야 합니다. DNS 하이재킹, fake-ip와 연결 스니핑은 이를 해결하는 방법이지만, 세 기능의 역할은 서로 다릅니다.

fake-ip 모드에서는 Clash DNS가 도메인에 예약 주소 범위의 임시 주소를 반환하고, 도메인과 해당 주소의 매핑을 저장합니다. 이후 애플리케이션이 이 임시 주소에 연결하면 코어가 원래 도메인을 복원한 뒤 도메인 규칙을 적용하고 원격 서버와 실제 연결을 구성할 수 있습니다. 흔히 사용되는 기본 대역은 벤치마크 용도의 예약 주소 범위에 속하며 공용 서버 주소가 아닙니다. 이 방식은 “로컬에서 특정 IP로 먼저 확인한 뒤 IP 규칙에 따라 잘못 판단하는” 상황을 줄일 수 있습니다.

일부 LAN 장치 검색, 프린터 서비스, 게임 플랫폼 또는 실제 DNS 응답에 의존하는 프로그램은 fake-ip와 잘 맞지 않습니다. 이 경우 fake-ip-filter로 해당 도메인을 제외해 실제 확인 결과를 받도록 할 수 있습니다. 필터 항목을 무작정 늘려서는 안 됩니다. 일반 도메인을 대량으로 제외하면 도메인과 연결 간의 연관성이 약해져 규칙 매칭이 IP 기준으로 되돌아갈 수 있습니다.

redir-host 모드는 일반적으로 실제 IP를 반환하고 코어가 확인 관계를 기록합니다. 일부 애플리케이션과의 호환 방식은 더 직접적이지만, 하나의 IP에 여러 도메인이 연결되거나 DNS 캐시가 다른 리졸버에서 제공되거나 애플리케이션이 Clash DNS를 우회하면 도메인 매핑이 불안정할 수 있습니다. 연결 스니핑은 TLS ClientHello의 SNI 또는 HTTP Host 같은 정보로 도메인을 보완할 수 있지만, 모든 프로토콜에서 도메인을 얻을 수 있는 것은 아니며 HTTPS 콘텐츠를 복호화하지도 않습니다.

DNS 요청이 가로채기를 우회하지 않도록 확인

  1. Clash DNS가 활성화되어 있는지 확인하고 클라이언트에 표시되는 수신 주소를 확인합니다.
  2. TUN을 사용할 때 DNS 하이재킹 규칙이 일반적인 53번 포트 조회를 포함하는지 확인합니다.
  3. 암호화 DNS를 사용하는 애플리케이션은 지정된 서버에 직접 접속할 수 있으므로, 라우팅과 도메인 규칙을 통해 해당 연결을 계속 가로채야 합니다.
  4. 문제를 확인할 때 운영체제와 브라우저의 DNS 캐시를 삭제해 이전 결과가 판단에 영향을 주지 않도록 합니다.
  5. LAN 도메인 확인에 문제가 생기면 모든 규칙을 바로 비활성화하지 말고 nameserver-policy, fallback과 fake-ip-filter를 확인합니다.

시스템 프록시 모드에서 브라우저가 CONNECT를 통해 도메인을 제출하면 Clash가 대상 이름을 직접 얻을 수 있으므로 fake-ip 의존도는 대체로 낮습니다. 하지만 애플리케이션이 먼저 자체적으로 도메인을 확인한 뒤 IP만 SOCKS 프록시에 전달하면 도메인 정보가 사라질 수 있습니다. SOCKS5는 도메인 전달을 지원하지만, 이 방식을 사용할지는 애플리케이션이 결정합니다.

사용 사례: 필요한 적용 범위에 따라 진입점 선택

일반적인 웹 탐색과 시스템 프록시를 지원하는 데스크톱 소프트웨어에는 우선 시스템 프록시를 활성화할 수 있습니다. 네트워크 변경이 적고 문제가 생겼을 때 스위치를 꺼서 직접 연결로 복원하기도 쉽습니다. 구독을 처음 가져온 사용자라면 이 방식으로 먼저 노드, 정책 그룹과 규칙이 정상인지 확인한 뒤 TUN 계층을 추가할지 결정하는 것이 편리합니다.

프록시 설정을 지원하지 않는 소프트웨어, UDP 애플리케이션, 게임 플랫폼, 백그라운드 업데이트 프로그램 또는 여러 명령줄 프로그램을 가로채야 한다면 TUN이 더 적합합니다. 애플리케이션마다 프록시 주소를 입력하는 작업을 줄이고, 서로 다른 네트워크 스택의 연결을 하나의 규칙 시스템으로 처리할 수 있습니다. 사용하기 전에 클라이언트에 TUN을 지원하는 코어가 포함되어 있는지 확인해야 합니다. 현재는 Clash Meta의 계보를 잇는 프로젝트인 mihomo가 널리 사용되며, 클라이언트마다 옵션 이름과 권한 관리 방식은 다를 수 있습니다.

서버와 개발 환경에서는 컨테이너, 원격 연결과 관리 경로도 고려해야 합니다. SSH로 원격 접속해 기본 라우팅을 수정할 때 TUN 라우팅 설정이 잘못되면 관리 연결이 즉시 끊길 수 있습니다. 이런 환경에서는 별도의 터미널을 유지하고 자동 롤백 작업을 설정하며 관리 네트워크 대역을 명확히 제외해야 합니다. 컨테이너 트래픽이 TUN으로 들어가는지는 호스트 라우팅, 네트워크 네임스페이스와 포워딩 규칙에 따라 결정되므로 호스트 브라우저의 프록시가 정상인지 만으로는 판단할 수 없습니다.

권장하는 단계별 설정 순서

  1. 유효한 구독을 가져온 뒤 연결 가능한 노드 또는 정책 그룹을 선택합니다.
  2. 규칙 모드에서 시스템 프록시를 활성화하고 브라우저와 일반적인 애플리케이션을 확인합니다.
  3. 연결 로그를 확인해 도메인 규칙, 직접 연결 규칙과 프록시 규칙이 예상대로 적용되는지 확인합니다.
  4. 실제로 적용 누락이 있을 때만 TUN을 활성화하고 클라이언트에 필요한 시스템 권한을 부여합니다.
  5. TCP, UDP, LAN 접속, DNS 확인과 시스템 절전 모드 복귀를 각각 테스트합니다.
  6. 작동하는 기존 설정을 보존하고 라우팅 또는 DNS 옵션을 변경한 뒤 항목별로 다시 테스트합니다.

“더 철저하게” 적용하기 위해 두 진입점을 항상 함께 사용할 필요는 없습니다. 많은 데스크톱 클라이언트는 TUN을 켠 뒤에도 시스템 프록시 스위치를 유지하는데, 이것이 반드시 오류를 일으키는 것은 아니지만 일부 애플리케이션은 명시적 프록시를 먼저 사용하고 다른 애플리케이션은 TUN을 사용하게 되어 문제 해결 시 실제 진입점을 판단하기 어려워집니다. 클라이언트 문서에 특별한 요구 사항이 없다면 먼저 한 가지 가로채기 방식만 활성화해 안정성을 확인한 뒤 조합이 필요한지 검토하는 것이 좋습니다.

문제 해결: 진입점부터 아웃바운드까지 단계별 확인

모드를 전환한 뒤 인터넷에 연결되지 않으면 여러 DNS, 노드와 규칙 옵션을 한꺼번에 바꾸지 말고 데이터 경로를 따라 확인해야 합니다. 첫 단계로 Clash 코어가 실행 중인지, 로컬 mixed-port 또는 다른 수신 포트가 사용 중이지 않은지 확인합니다. 두 번째로 현재 진입점을 확인합니다. 시스템 프록시 주소가 올바른 포트를 가리키는지, 또는 TUN 가상 인터페이스가 생성되었는지 살펴봅니다. 세 번째로 요청이 연결 기록에 표시되는지 확인합니다.

시스템 프록시를 켠 뒤 브라우저는 되는데 터미널 명령은 계속 직접 연결될 때는 어떻게 하나요?

먼저 명령줄 도구가 시스템 프록시를 읽는지 확인합니다. 도구 문서에 따라 HTTP, HTTPS 또는 SOCKS 프록시를 설정하거나, 많은 터미널 프로그램을 한꺼번에 가로채야 한다면 TUN을 사용할 수 있습니다. 프록시 환경 변수를 모든 셸 설정에 영구적으로 기록한 뒤 정리하지 않으면, Clash를 종료한 뒤에도 명령이 이미 닫힌 로컬 포트에 계속 연결을 시도할 수 있으므로 주의하세요.

TUN을 활성화한 뒤 LAN 장치에 접근할 수 없을 때는 어떻게 하나요?

LAN 대역이 잘못 프록시로 전달되고 있지 않은지 확인하고, 사설 주소 규칙이 DIRECT로 유지되는지 살펴보며, fake-ip-filter가 LAN 도메인을 어떻게 처리하는지 확인합니다. 프린터, NAS와 라우터 관리 페이지는 대개 로컬 확인과 직접 연결이 필요합니다. 네트워크 인터페이스가 여러 개인 장치에서는 실제 LAN 인터페이스가 자동 라우팅에 의해 잘못 식별되지 않았는지도 확인해야 합니다.

TUN은 켜져 있는데 특정 UDP 프로그램이 여전히 연결되지 않는 이유는 무엇인가요?

가상 인터페이스가 실제로 UDP 패킷을 받는지 확인한 다음, 선택한 노드 프로토콜과 서버가 해당 UDP 포워딩을 지원하는지 확인합니다. TUN이 UDP를 가로챌 수 있다고 해서 모든 프록시 노드가 해당 트래픽을 성공적으로 전달할 수 있는 것은 아닙니다. 방화벽 제한, 엄격한 NAT, 프로그램의 LAN 브로드캐스트 사용, 대상이 사용할 수 없는 정책 그룹에 잘못 배정된 규칙도 함께 제외해야 합니다.

클라이언트를 종료한 뒤 시스템에는 연결됨으로 표시되지만 웹페이지가 열리지 않을 때는 어떻게 하나요?

시스템 프록시가 아직 수신을 중단한 로컬 포트를 가리키고 있거나 TUN 라우팅이 정상적으로 정리되지 않았을 수 있습니다. 먼저 클라이언트를 다시 시작하고 관련 스위치를 정상적으로 끈 다음, 운영체제 프록시 설정, 가상 네트워크 인터페이스와 기본 라우팅을 확인합니다. 프로세스를 강제 종료하거나 장치가 비정상적으로 종료되면 복구가 필요한 네트워크 상태가 남기 쉽습니다.

규칙 로그에 IP만 표시되고 도메인이 표시되지 않을 때는 어떻게 하나요?

애플리케이션이 Clash DNS를 우회하는지, DNS 하이재킹이 적용되는지와 향상된 모드가 예상대로 실행되는지 확인합니다. 애플리케이션이 자체 리졸버를 사용하거나 고정 IP에 직접 연결하면 코어는 IP-CIDR, GEOIP 같은 규칙만 적용할 수 있습니다. 호환되는 범위에서 스니핑을 활성화해 도메인 정보를 보완할 수 있지만, 먼저 DNS 경로를 바로잡아야 합니다.

마지막으로 노드를 비교하세요. 같은 노드가 시스템 프록시에서는 작동하지만 TUN에서는 작동하지 않는다면 문제는 가상 인터페이스, 라우팅, DNS 또는 권한에 있을 가능성이 큽니다. 두 모드 모두 프록시 연결을 구성하지 못한다면 구독 상태, 정책 선택, 노드 연결 가능 여부와 로컬 네트워크를 확인해야 합니다. 특정 대상에서만 문제가 발생한다면 해당 대상에 적용된 규칙과 정책 그룹을 확인해 단일 사이트 문제를 TUN 기능 전체의 장애로 오해하지 않도록 합니다.

결론: 모드는 이름이 아니라 적용 범위로 결정

시스템 프록시는 애플리케이션 계층의 진입점에 위치하며 설정이 간단하고 문제 해결 경로가 짧아 운영체제 프록시 설정을 따르는 프로그램에 적합합니다. TUN은 IP 라우팅 진입점에 위치해 더 많은 TCP, UDP와 프록시 옵션을 제공하지 않는 애플리케이션까지 적용할 수 있지만, 권한, 가상 인터페이스, 라우팅, DNS 매핑과 프록시 루프를 처리해야 합니다. 두 방식 모두 최종적으로 연결을 Clash 또는 mihomo의 규칙 엔진에 전달하며, 구독 자체의 노드 품질을 바꾸지는 않습니다.

먼저 시스템 프록시로 기본 설정을 확인한 다음, 명확한 애플리케이션 적용 요구가 있을 때 TUN을 활성화하는 순서가 합리적입니다. 문제가 발생하면 애플리케이션 진입점, DNS, 규칙, 정책 그룹, 프록시 아웃바운드와 실제 네트워크 인터페이스를 차례로 확인하세요. 한 번에 하나의 옵션만 변경하면 노드와 네트워크 스택을 계속 바꾸는 것보다 대개 더 빠르게 원인을 찾을 수 있습니다.

플랫폼에 맞는 설치 패키지 선택

다운로드 센터에서 운영체제와 아키텍처를 확인한 뒤, 사용 설명서에 따라 구독 가져오기와 시스템 프록시 또는 TUN 모드를 설정하세요.

다운로드 페이지 사용 가이드 보기