시스템 프록시와 TUN 모드 비교: 프록시를 사용하지 않는 프로그램이 있는 이유

먼저 구분할 점: 트래픽을 가져오는 것과 출구를 선택하는 것은 별개입니다

브라우저에서는 웹페이지가 열리는데 게임은 연결되지 않거나, Clash를 ‘전역’으로 바꿨는데도 터미널의 다운로드가 직접 연결되는 경우가 있습니다. 이런 현상은 대개 버튼이 작동하지 않는 문제가 아니라 트래픽이 프록시 코어에 들어오지 않은 탓입니다. 문제를 찾을 때는 먼저 ‘연결이 들어왔는지’를 확인하고, 그다음 ‘들어온 연결이 어떤 규칙을 따라갔는지’를 살펴보세요.

시스템 프록시와 TUN: 앱 트래픽을 코어로 전달하는 방식을 결정합니다.
규칙, 전역, 직접 연결: 코어가 연결을 받은 뒤 어떤 출구를 사용할지 결정합니다.
정책 그룹과 노드: 최종적으로 어떤 프록시 서버를 이용할지, 아니면 대상에 직접 연결할지 결정합니다.

따라서 TUN을 켰다고 해서 모든 연결이 프록시를 통과하는 것은 아닙니다. TUN으로 트래픽을 받아도 규칙에 따라 DIRECT로 직접 연결할 수 있습니다. 반대로 ‘전역’으로 전환하기만 해서는 시스템 프록시를 무시하는 프로그램의 트래픽을 강제로 가져올 수 없습니다.

시스템 프록시: 앱이 로컬 포트로 연결을 전달하는 방식

HTTP 및 HTTPS 요청은 어떻게 Clash로 전달될까요?

클라이언트에서 ‘시스템 프록시’를 켜면 보통 운영체제의 프록시 설정이 변경되고, 해당 설정을 지원하는 앱이 로컬 프록시 포트에 연결합니다. 흐름을 간단히 나타내면 다음과 같습니다. 앱 → 127.0.0.1:7890 → 코어의 규칙 매칭 → 직접 연결 또는 프록시 출구.

HTTP 요청은 HTTP 프록시를 통해 전달할 수 있습니다. HTTPS는 보통 CONNECT로 터널을 만든 다음 그 안에서 TLS 통신을 합니다. 일반적인 HTTPS 프록시 터널에는 복호화 인증서를 설치할 필요가 없으며, 시스템 프록시를 켰다고 Clash가 암호화된 웹페이지 내용을 읽는 것도 아닙니다.

일부 프로그램에는 왜 아무 영향이 없을까요?

시스템 프록시는 앱이 참조하는 설정이지, 모든 네트워크 연결에 강제로 적용되는 스위치가 아닙니다. 브라우저는 이 설정을 읽기도 하지만 확장 프로그램이나 자체 프록시 옵션을 사용하기도 합니다. 명령줄 도구는 환경 변수나 전용 설정을 참조하는 경우가 많고, 게임은 TCP 또는 UDP 연결을 직접 만드는 일이 흔합니다.

Windows: ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 사용자 프록시 설정을 확인하세요. 일부 서비스는 별도의 WinHTTP 설정을 사용하므로 이 화면만 보고 상태를 판단하면 안 됩니다.
macOS: ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’에서 확인하세요. 네트워크 서비스마다 설정이 다를 수 있습니다.
Linux: 데스크톱 환경의 프록시 옵션, 셸 환경 변수, 앱 자체 설정은 서로 연동되지 않을 수 있으므로 각각 확인해야 합니다.

시스템 프록시는 변경 범위가 비교적 작아 앱별로 문제를 살펴보기 편합니다. 평소 브라우저와 프록시를 지원하는 개발 도구만 사용한다면 우선 이 방식으로 시작하는 편이 문제를 파악하기 쉽습니다.

TUN 모드: 가상 네트워크 어댑터로 IP 패킷을 받는 방식

TUN은 3계층 가상 네트워크 인터페이스입니다. TUN을 지원하는 코어는 운영체제의 라우팅을 이용해 조건에 맞는 IP 패킷을 가상 네트워크 어댑터로 전달한 다음, 패킷에 포함된 연결을 식별해 규칙 엔진으로 보냅니다. 앱이 HTTP나 SOCKS 프록시 프로토콜을 직접 이해할 필요는 없습니다.

여기에도 전제 조건이 있습니다. 패킷이 실제로 TUN 인터페이스로 라우팅되어야 합니다. 자동 라우팅, 제외할 네트워크 대역, 인터페이스 바인딩, 다른 VPN의 라우팅 우선순위에 따라 적용 범위가 달라집니다. ‘TUN 사용 중’이라는 이유만으로 모든 프로세스와 인터페이스의 트래픽이 반드시 처리된다고 볼 수는 없습니다.

비교 항목	시스템 프록시	TUN 모드
앱 지원	앱이 시스템 프록시를 읽거나 프록시를 직접 설정해야 함	일반적으로 앱에서 프록시 프로토콜을 지원할 필요가 없음
주요 연결 지점	로컬 HTTP·SOCKS 수신 포트 등	가상 네트워크 어댑터와 운영체제 라우팅
UDP 트래픽	일반 HTTP 시스템 프록시로는 대개 처리할 수 없음. SOCKS5도 앱에서 UDP 릴레이를 지원해야 함	라우팅된 UDP를 받을 수 있지만 출구에서도 지원해야 함
실행 권한	일반적으로 현재 사용자의 프록시 설정만 변경하면 됨	일반적으로 서비스 모드 또는 관리자·네트워크 관리 권한이 필요함
흔한 문제	앱이 설정을 무시함, 포트 입력 오류, 프록시 설정 잔존	라우팅 충돌, DNS 오류, 권한 부족, 출구의 UDP 미지원

mihomo 설정 항목 이해하기

Clash는 클라이언트와 코어 생태계를 가리키는 일반적인 명칭이며, Clash Meta는 이후 mihomo라는 이름으로 개발을 이어가고 있습니다. 코어마다 지원 기능은 다를 수 있습니다. 아래는 mihomo TUN 설정의 일부로, 항목 간 관계를 설명하기 위한 예시입니다. 기존 설정에 병합해야 하며 구독 설정 전체를 이 내용으로 바꾸면 안 됩니다.

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

enable: TUN을 활성화합니다. 단, 운영체제 권한은 별도로 충족해야 합니다.
stack: 네트워크 스택 구현을 선택합니다. mihomo는 system, gvisor, mixed 등을 제공하며, 실제 지원 여부는 사용 중인 코어에 따라 다릅니다. 모든 기기에서 가장 빠른 단일 옵션은 없습니다.
auto-route: 트래픽을 가져오는 데 필요한 경로를 자동으로 추가합니다. 모든 라우팅 예외를 무시한다는 뜻은 아닙니다.
auto-detect-interface: 아웃바운드 인터페이스를 자동으로 감지합니다. 회사 VPN을 함께 사용한다면 실제 출구도 확인해야 합니다.
dns-hijack: 여기서 any:53은 조건에 맞는 UDP 53 DNS 요청을 가로채는 설정입니다. 요청이 해당 트래픽 처리 경로에 먼저 들어와야 합니다.

데스크톱 클라이언트는 UI 설정으로 이 항목을 생성할 수 있으며, 구독을 새로고침하면 직접 수정한 내용이 덮어써질 수도 있습니다. 클라이언트의 TUN 설정, 설정 덮어쓰기 또는 병합 기능을 우선 사용하고 최종 적용된 설정을 확인하세요.

DNS 처리 차이: 웹페이지가 프록시를 거쳐도 DNS가 같은 경로를 이용한다고 볼 수 없습니다

시스템 프록시 사용 시 도메인은 어디서 조회될까요?

DNS 처리 방식은 앱과 프록시 프로토콜에 따라 다릅니다. HTTPS의 CONNECT 요청은 대상 도메인을 전달해 프록시 측에서 처리하게 할 수 있지만, 앱이 먼저 시스템 DNS를 호출할 수도 있습니다. SOCKS5도 도메인을 전달하거나 이미 조회된 IP를 전달할 수 있으므로, 앱이 어떤 방식을 선택하는지가 중요합니다.

같은 SOCKS5 포트를 사용해도 명령줄에서 socks5://와 socks5h://를 테스트한 결과가 다를 수 있는 이유입니다. curl에서는 후자가 프록시 측에서 대상 도메인을 조회하도록 명시합니다. 외부 IP 주소가 바뀌었다는 사실만으로 모든 DNS 요청이 Clash를 거쳤다고 판단할 수는 없습니다.

TUN의 DNS 가로채기와 Fake-IP는 서로 다른 기능입니다

DNS 가로채기는 조건에 맞는 DNS 요청을 코어의 DNS 모듈로 전달합니다. Fake-IP는 응답 방식 중 하나로, 먼저 앱에 매핑 주소를 반환한 뒤 코어가 후속 연결을 원래 도메인에 연결합니다. mihomo에서 흔히 사용하는 Fake-IP 주소 풀은 198.18.0.1/16이며 실제 값은 설정에 따릅니다. 이는 프록시 서버의 공인 IP 주소가 아닙니다.

앞서 소개한 DNS 가로채기 설정을 사용할 때는 기존 dns.enable, 업스트림 리졸버, 관련 라우팅도 확인해야 합니다. DNS 모듈이 비활성화된 상태가 되지 않도록 주의하세요.
any:53은 브라우저의 DoH를 자동으로 복호화하지 않으며, TLS로 암호화된 DoT 요청도 일반 DNS 조회로 처리하지 않습니다.
도메인 규칙을 적용하려면 코어가 도메인 정보를 알아야 합니다. 대상 IP만 확인할 수 있는 경우 규칙 매칭 결과가 예상과 다를 수 있습니다.
LAN 기기 검색, 사내 도메인 또는 Fake-IP와 호환되지 않는 특수 앱이 있다면 관련 필터와 DNS 규칙만 조정하세요. 모든 DNS 설정을 바로 지우는 것은 바람직하지 않습니다.

앱별 설정: 브라우저·명령줄·게임에는 어떤 방식을 써야 할까요?

브라우저: 자체 프록시 설정부터 확인하세요

브라우저는 보통 시스템 프록시를 사용할 수 있습니다. 특정 브라우저에서만 적용되지 않는다면 프록시 확장 프로그램, 별도 프록시 설정, 보안 DNS, 설정을 바꾸기 전에 만든 연결의 재사용 여부를 확인하세요. Firefox에서는 ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’에서 ‘시스템 프록시 설정 사용’이 선택되어 있는지 확인할 수 있습니다.

명령줄: 포트를 명시하고 재현 가능한 테스트부터 진행하세요

아래 명령은 직접 연결, HTTP 프록시, 프록시 측에서 도메인을 조회하는 SOCKS5를 비교합니다. Windows PowerShell에서는 curl이 다른 명령 별칭으로 처리되는 구형 환경을 피하려면 curl.exe를 사용하세요. 테스트 사이트에 접속할 수 있다는 사실만으로 프록시가 정상이라고 단정할 수는 없습니다. 클라이언트의 연결 기록도 함께 확인하세요.

curl --noproxy "*" -I --connect-timeout 10 https://example.com
curl --noproxy "" -x http://127.0.0.1:7890 -I --connect-timeout 10 https://example.com
curl --noproxy "" --proxy socks5h://127.0.0.1:7890 -I --connect-timeout 10 https://example.com

첫 번째 명령은 명시적 프록시를 우회하지만, TUN이 트래픽을 처리 중이라면 여전히 TUN을 통과할 수 있습니다. 시스템 프록시를 확인할 때는 TUN을 끄고, TUN을 확인할 때는 명시적 프록시 매개변수를 제거해 두 경로가 섞이지 않도록 하세요.

현재 셸에서 환경 변수를 지원하는 도구에 프록시를 적용하려면 다음 변수를 임시로 설정할 수 있습니다. 이 변수는 이를 읽는 프로세스에만 영향을 주며 기기 전체의 네트워크 출구를 변경하지는 않습니다.

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1

여기서 https_proxy 값에 http://를 사용하는 것은 HTTP 프록시를 통해 HTTPS 터널을 만든다는 뜻입니다. Git, 패키지 관리자, 컨테이너 도구에는 별도의 프록시 설정이 있을 수도 있습니다. 컨테이너 안의 127.0.0.1은 컨테이너 자체를 가리키므로 호스트 주소로 그대로 사용할 수 없습니다.

게임과 음성 채팅: UDP 출구를 집중적으로 확인하세요

게임 로그인에는 HTTPS를 사용해도 대전과 음성 채팅은 UDP를 사용할 수 있습니다. ‘로그인은 되는데 방에 들어가지 못하는’ 경우 웹페이지 연결만 확인해서는 안 됩니다. TUN으로 관련 UDP 패킷을 받을 수 있지만, 선택한 노드와 프록시 프로토콜, 서버, 네트워크 경로 모두 해당 UDP 릴레이를 지원해야 합니다.

프록시를 사용한다고 지연 시간이 줄어드는 것은 아닙니다. 노드 이름보다 대전 서버의 위치, 우회 경로, 패킷 손실과 지터가 더 유용한 판단 기준입니다. 테스트할 때는 서버와 노드를 고정하고 직접 연결과 프록시 결과를 각각 기록하세요. 속도 측정 사이트에서 한 번 확인한 대역폭 수치만으로 게임 환경을 판단하지 마세요.

프록시가 적용되지 않을 때: 연결 기록에 따라 두 경로로 나눠 확인하기

최소한의 테스트 환경을 구성하세요. 다른 VPN, 게임 가속기, 프록시 확장 프로그램을 잠시 끄고 클라이언트 하나만 남깁니다. 현재 설정을 기록하고, 회사 네트워크에서는 먼저 네트워크 관리 정책을 확인하세요.
코어가 실행 중인지 확인하세요. 혼합 포트가 실제로 7890인지 확인합니다. Windows에서는 netstat -ano | findstr :7890을 실행해 수신 대기 상태를 확인할 수 있습니다. 포트가 열려 있어도 현재 클라이언트가 수신 중이라는 뜻은 아니므로 프로세스도 확인해야 합니다.
시스템 프록시만 테스트하세요. TUN을 끄고 시스템 프록시를 켠 다음, 브라우저나 앞서 소개한 명시적 프록시 명령으로 새 연결을 만듭니다. 이때 ‘연결 / Connections’와 ‘로그 / Logs’를 함께 확인하세요.
그다음 TUN만 따로 테스트하세요. 시스템 프록시를 끄고 클라이언트에서 요구하는 서비스 모드나 관리자 권한을 활성화한 뒤 TUN을 켭니다. Android는 보통 시스템 VPN 권한을 사용하고, Linux는 관련 네트워크 관리 권한이 필요한 경우가 많습니다. Windows와 같은 방식으로 설정할 수는 없습니다.
매칭된 규칙과 실제 출구를 확인하세요. 연결 기록이 있는데 출구가 DIRECT로 표시된다면 규칙 순서, 프로세스 매칭, 정책 그룹 선택부터 확인하세요. 규칙은 순서대로 매칭되므로 앞쪽 규칙이 예상한 규칙보다 먼저 적용될 수 있습니다.
마지막으로 DNS와 호환성을 확인하세요. 로그에 DNS 조회 시간 초과, Fake-IP 매핑 오류, 특정 UDP 연결 실패가 나타날 때 해당 문제에 맞춰 설정을 수정하세요. 한 번에 하나씩만 변경해야 원인을 파악하기 쉽습니다.

확인된 증상	우선 점검할 항목
프로그램을 사용해도 코어에 해당 연결이 표시되지 않음	앱이 시스템 프록시를 무시함, TUN 라우팅 범위에서 제외됨, 프로세스나 인터페이스가 제외됨
연결은 있지만 출구가 DIRECT로 표시됨	규칙 순서, 직접 연결 모드, 현재 선택된 정책 그룹
연결은 있지만 프록시 출구에서 시간 초과 발생	노드 연결 상태, 프로토콜 설정, 서버 상태, 대상 제한
웹페이지는 되지만 게임 음성 채팅은 실패함	UDP 트래픽 처리 및 릴레이 지원, 관련 도메인 조회, 게임 전용 규칙
TUN을 켠 뒤 사내 네트워크에 연결할 수 없음	VPN 라우팅 충돌, 내부 DNS, 사설 네트워크 대역 제외 설정

짧은 연결은 금방 종료되어 연결 패널에 기록이 남지 않을 수 있습니다. 필요한 경우 로그를 켜고 문제를 다시 재현하세요. 로그를 공유하기 전에 구독 주소, 액세스 토큰, 노드 인증 정보, 사설 도메인을 삭제하세요. 화면 공유를 위해 설정 파일 전체를 공개해서는 안 됩니다.

최종 선택: 필요한 범위만 최소한으로 가져오기

브라우저와 프록시를 지원하는 일부 프로그램만 처리하려면 시스템 프록시부터 사용하세요. 개발 도구에서 일관되고 재현 가능한 동작이 필요하다면 도구 자체의 프록시 옵션을 설정하세요. 게임, 음성 채팅, 프록시 설정을 읽지 않는 앱의 트래픽을 처리해야 할 때 TUN을 고려하면 됩니다.

시스템 프록시와 TUN을 동시에 켤 수 있으며 반드시 충돌하는 것은 아닙니다. 다만 문제를 진단할 때는 각각 따로 테스트하는 편이 좋습니다. 인터넷이 끊겨도 바로 재설치할 필요는 없습니다. 먼저 TUN을 끄고 라우팅이 복구되는지 확인한 다음 시스템 프록시를 끄고, 시스템에 종료된 클라이언트의 로컬 포트가 남아 있는지 살펴보세요. TUN이 연결을 받았는데 출구가 작동하지 않는 경우에는 처리 방식을 바꿔도 노드 자체의 문제가 해결되지 않습니다.

다음 순서만 기억하면 됩니다. 트래픽이 들어오는가 → DNS가 올바른가 → 어떤 규칙이 적용됐는가 → 출구에 연결할 수 있는가. 이 네 단계를 따라가면 ‘프록시를 켰는데도 작동하지 않는다’는 문제를 하나씩 검증할 수 있습니다. 규칙 항목은 설정 및 프로토콜 안내서에서 확인하고, 처음 설치한다면 빠른 시작 가이드를 참고하세요.