먼저 트래픽 처리 방식을 선택하고, 그다음 라우팅 규칙을 확인하세요

브라우저에서는 웹페이지가 열리는데 터미널은 연결 시간 초과가 발생하거나, 시스템 프록시를 켰는데도 게임이 기존 연결 경로를 사용하는 경우가 있습니다. 이런 현상이 반드시 노드 장애를 뜻하지는 않습니다. 앱이 시스템 프록시 설정을 따르지 않는 것이 흔한 원인입니다. 시스템 프록시와 TUN의 핵심 차이는 노드 속도나 구독 품질이 아니라 트래픽이 Clash 코어로 들어오는 방식입니다.

  • 주로 브라우저를 사용한다면: 먼저 시스템 프록시를 켜세요. 설정이 간단하고 문제가 생겨도 쉽게 원래대로 되돌릴 수 있습니다.
  • 명령줄 작업 하나만 프록시로 연결하려면: 명령에 HTTP 또는 SOCKS 프록시를 직접 지정하세요. 바로 TUN을 켤 필요는 없습니다.
  • 앱이 프록시 설정을 지원하지 않거나 일부 UDP 트래픽을 처리해야 한다면: TUN을 고려하고 라우팅, DNS, 노드 프로토콜을 확인하세요.
  • 회사 VPN에 연결 중이라면: 먼저 회사 네트워크 정책을 확인하세요. 두 도구가 기본 경로를 동시에 변경하지 않도록 주의해야 합니다.

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

시스템 프록시는 운영체제의 프록시 설정에 로컬 프록시 주소를 등록합니다. 이 설정을 지원하는 앱은 해당 주소를 읽어 요청을 클라이언트로 전달합니다. 예를 들어 클라이언트가 127.0.0.1:7890에서 연결을 수신하면 브라우저는 이 로컬 포트를 통해 프록시 연결을 만들 수 있습니다. 실제 포트 번호는 클라이언트에 표시된 값을 기준으로 하세요. 7890은 이 문서의 예시일 뿐입니다.

시스템 프록시로 처리되는 연결은 무엇인가요?

Edge, Chrome 등의 브라우저는 대체로 시스템 프록시 설정을 따르지만, 조직 정책이나 확장 프로그램, 실행 옵션에 따라 동작이 달라질 수 있습니다. Firefox는 시스템 프록시를 사용하거나 연결 방식을 따로 설정할 수 있습니다. 다운로드 관리자, 개발 도구, 게임은 저마다 구현 방식이 다릅니다. 작업 표시줄에 ‘시스템 프록시 사용’으로 표시된다고 해서 모든 앱의 연결이 처리되는 것은 아닙니다.

  • HTTP 프록시는 웹 요청에 주로 사용되며, HTTPS는 보통 HTTP CONNECT로 터널을 만듭니다. 그렇다고 클라이언트가 HTTPS 콘텐츠를 복호화하는 것은 아닙니다.
  • SOCKS5는 TCP를 처리할 수 있습니다. UDP를 사용할 수 있는지는 앱, 클라이언트, 노드 연결 경로가 모두 지원하는지에 달려 있습니다.
  • mixed-port를 사용하면 하나의 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받을 수 있지만, 프록시 설정을 읽지 않는 앱의 연결 경로까지 자동으로 바뀌지는 않습니다.

시스템 설정에서 주소 확인하기

Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’로 이동해 수동 프록시나 설정 스크립트 상태를 확인할 수 있습니다. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’에서 확인하세요. 이 메뉴는 시스템 설정을 점검할 때 사용하고, 일상적인 켜기·끄기는 클라이언트에서 하는 편이 좋습니다. 양쪽에서 설정을 반복해 덮어쓰지 않도록 하세요.

앱의 프록시 서버 주소로 0.0.0.0을 입력하지 마세요. 이 주소는 모든 IPv4 인터페이스에서 수신한다는 의미로 자주 쓰입니다. 같은 컴퓨터의 앱은 일반적으로 127.0.0.1에 연결해야 합니다. LAN에서 공유해야 할 때만 수신 주소와 방화벽, 접근 제한을 별도로 검토하세요.

TUN 모드: 가상 네트워크 인터페이스로 IP 트래픽 받기

TUN은 가상 네트워크 인터페이스를 만들거나 기존 인터페이스를 사용한 뒤, 라우팅 등의 방식으로 조건에 맞는 IP 패킷을 코어에 전달합니다. 앱에서 HTTP 프록시 옵션을 제공하지 않아도 되므로 프록시를 직접 설정할 수 없는 프로그램에 적합합니다. Clash Meta에서 발전한 mihomo 코어가 관련 기능을 제공하지만, 클라이언트마다 사용하는 코어와 서비스 설치 방식, 설정 화면은 다를 수 있습니다.

‘TUN 사용’이 ‘모든 네트워크 트래픽 가로채기’를 보장하는 것은 아닙니다. 실제 처리 범위는 IPv4·IPv6 라우팅, 인터페이스 제외 설정, LAN 우회, 다른 VPN, 시스템 방화벽에 따라 달라집니다. 가상 머신, 컨테이너, WSL의 트래픽은 별도의 네트워크 경로를 거치므로 호스트에서 실행되는 앱과 동일하게 볼 수 없습니다.

비교 항목 시스템 프록시 TUN 모드
트래픽 진입 경로 앱이 프록시 수신 포트에 직접 연결 가상 인터페이스와 라우팅으로 IP 트래픽 수신
앱 요구 사항 시스템 설정을 따르거나 프록시를 별도로 설정 일반적으로 앱의 프록시 프로토콜 지원이 필요하지 않음
UDP 처리 일반 HTTP 시스템 프록시는 보통 UDP를 처리하지 않음 처리 대상으로 지정된 UDP를 전달할 수 있지만 노드 지원이 필요함
권한 및 서비스 일반적으로 가상 인터페이스 생성이 필요하지 않음 대개 관리자 권한 또는 사전 설치된 권한 서비스 필요
문제 해결 시 확인할 항목 주소, 포트, 앱의 프록시 설정 사용 여부 라우팅, DNS, 서비스 권한, 인터페이스 충돌

TUN에는 왜 관리자 권한이 필요한가요?

인터페이스를 만들고 라우팅을 변경하는 작업은 시스템 네트워크 권한이 필요합니다. Windows 클라이언트는 서비스 모드로 실행할 수 있고, macOS는 보조 프로그램을 승인해야 할 수 있습니다. Linux에서는 보통 /dev/net/tun과 관련 네트워크 관리 권한이 필요합니다. 권한 서비스가 설치되어 있다면 그래픽 인터페이스를 매번 관리자 권한으로 실행하지 않아도 됩니다.

로그에 권한 부족이 표시되면 TUN을 계속 껐다 켜기보다 사용하는 클라이언트의 안내에 따라 서비스를 설치하거나 복구하세요. 문제를 해결하는 동안 시스템 방화벽을 장시간 꺼두는 것도 피해야 합니다. 먼저 서비스 상태를 확인한 다음 차단된 프로그램과 규칙을 살펴보세요.

명령줄과 게임: 설정 상태를 짐작하지 말고 앱별로 확인하기

명령줄 연결이 안 되면 프록시를 직접 지정해 테스트하세요

터미널에서 실행하는 도구가 운영체제의 프록시 설정을 따르지 않을 수 있습니다. 일부 도구는 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY를 인식하지만 지원 범위와 대소문자 처리 방식은 제각각입니다. 문제를 확인할 때는 전역 환경 변수를 바꾸는 것보다 명령에 프록시를 직접 지정하는 편이 영향 범위를 파악하기 쉽습니다.

# Windows PowerShell에서는 이전 별칭의 간섭을 피하려면 curl.exe를 사용
curl.exe --proxy http://127.0.0.1:7890 --noproxy "" -I https://example.com

# macOS / Linux에서는 curl 사용
curl --proxy http://127.0.0.1:7890 --noproxy "" -I https://example.com

# SOCKS5를 사용하고 프록시 서버에서 대상 도메인을 조회
curl --proxy socks5h://127.0.0.1:7890 --noproxy "" -I https://example.com

아래 명령은 7890이 해당 프로토콜을 지원하는 혼합 포트라고 가정합니다. HTTP 응답이 오면 이번 프록시 요청이 성공적으로 연결된 것입니다. 단, 상태 코드만으로 어떤 공인 IP를 통해 나갔는지는 알 수 없습니다. 프록시를 직접 지정하면 성공하지만 일반 명령은 실패하는 경우, 먼저 해당 도구의 프록시 옵션이나 환경 변수를 확인하세요. 구독을 먼저 바꿀 필요는 없습니다.

게임은 UDP를 사용하며, TUN이 지연 시간을 보장하지는 않습니다

게임은 TCP 로그인, UDP 대전, 별도 음성 연결을 함께 사용할 수 있습니다. TUN을 켜도 라우팅 대상에 포함되고 노드가 지원하는 연결만 프록시를 거칠 수 있습니다. 노드 프로토콜, 서버 설정, 규칙 적용 결과, 지역 제한 등이 모두 영향을 줄 수 있습니다.

  1. 먼저 클라이언트의 연결 목록에서 게임 프로세스나 대상 주소를 찾아 연결이 코어에 들어왔는지 확인하세요.
  2. 적용된 규칙과 프록시 그룹을 확인하세요. 로그인 연결은 프록시를 거치지만 대전 연결은 예상하지 못한 직접 연결 규칙을 따르는 상황을 방지할 수 있습니다.
  3. 노드가 UDP 전달을 지원하는지 확인하세요. 웹 속도 측정 결과만으로 판단하지 마세요.
  4. 같은 서버와 시간대에 직접 연결과 프록시 연결을 비교하고, 게임 내 지연 시간과 패킷 손실, 연결 끊김을 기록하세요.

경로가 더 긴 노드는 지연 시간을 늘릴 수 있습니다. TUN은 트래픽을 처리할 수 있는 범위를 넓힐 뿐, 게임을 자동으로 가속하지는 않습니다. 게임 이용 약관과 부정행위 방지 정책도 별도로 확인해야 합니다.

DNS 처리: 프록시를 통한 조회와 시스템 DNS 조회 구분하기

시스템 프록시와 TUN의 또 다른 주요 차이는 도메인 조회가 어떤 경로를 거치는지입니다. HTTP 프록시로 HTTPS 사이트에 접속할 때 앱이 대상 도메인 조회를 프록시에 맡길 수 있습니다. 하지만 앱의 사전 조회, 다른 백그라운드 연결, 보안 DNS 기능은 다른 경로를 사용할 수 있습니다. 따라서 ‘웹페이지가 프록시를 통해 열렸다’고 해서 모든 DNS 조회가 같은 경로를 이용한다고 단정할 수는 없습니다.

TUN은 DNS 트래픽을 처리하도록 설정해 조건에 맞는 53번 포트 조회를 코어의 DNS 모듈로 전달할 수 있습니다. mihomo에서 자주 쓰이는 dns-hijack가 이 기능에 사용됩니다. 하지만 임의의 암호화 DNS를 복호화하는 기능은 아닙니다. 앱이 직접 보내는 DoH는 HTTPS를 사용하고, DoT는 보통 853번 포트를 사용하므로 53번 포트용 설정 하나로 이들을 자동 감지해 변경할 수는 없습니다.

mihomo 설정 조각의 각 항목 읽는 법

tun:
  enable: true
  stack: mixed
  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

이 코드는 각 필드를 설명하기 위한 일부 설정이며, 단독으로 실행할 수 있는 완전한 설정 파일이 아닙니다. auto-route는 관련 라우팅을 자동으로 설정하고, auto-detect-interface는 외부 연결에 사용할 인터페이스를 자동으로 감지합니다. listen의 1053은 로컬 DNS 수신 포트이며 노드 포트가 아닙니다. DNS 트래픽 가로채기와 이 수신 포트도 서로 다른 개념입니다.

Fake-IP 모드는 도메인에 매핑 주소를 할당한 뒤, 이 매핑 정보를 이용해 후속 연결을 처리합니다. 198.18.0.1/16은 여기서 사용하는 주소 풀이지 실제 웹사이트 서버 주소가 아닙니다. 기존 설정에는 적절한 상위 DNS 등의 항목도 필요합니다. 이 조각을 구독 파일에 그대로 덮어쓰지 말고, 같은 계층에 dns 또는 tun 키를 중복해서 추가하지 마세요.

사용 순서: 먼저 기본 연결을 확인한 뒤 TUN 추가하기

시스템 프록시와 TUN을 동시에 켠다고 반드시 충돌하는 것은 아니지만, 효과가 두 배가 된다고 볼 수도 없습니다. HTTP 프록시 연결과 가상 인터페이스를 통한 처리가 동시에 이뤄질 수 있으며, 클라이언트는 자체 트래픽과 라우팅 제외 항목을 올바르게 처리해야 합니다. 문제를 해결할 때는 한 가지 진입 방식만 남겨야 어느 단계에서 문제가 생겼는지 파악하기 쉽습니다.

  1. 노드와 설정 확인: 구독을 가져오고 노드 하나를 선택한 다음 Rule 모드에서 시스템 프록시로 웹페이지에 접속해 보세요.
  2. 로컬 포트 확인: 클라이언트에서 HTTP, SOCKS 또는 혼합 포트를 확인하세요. 컨트롤 패널 API 포트를 프록시 포트로 착각하지 않도록 주의하세요.
  3. 서비스 권한 준비: 클라이언트 안내에 따라 서비스를 설치하거나 권한을 승인하고, 네트워크를 처리 중인 다른 프록시 도구는 종료하세요.
  4. TUN만 따로 테스트: 시스템 프록시를 잠시 끄고 TUN을 켠 뒤 대상 앱을 다시 시작해 연결 목록과 로그를 확인하세요.
  5. 자주 쓰는 서비스 확인: 웹페이지, 명령줄, LAN 기기, 회사 내부 사이트에 접속해 직접 연결이 필요한 주소에 규칙이 잘못 적용되지 않았는지 확인하세요.

Android 클라이언트는 보통 시스템 VPN 인터페이스로 트래픽을 처리합니다. 같은 사용자에서는 VPN 서비스를 일반적으로 하나만 활성화할 수 있습니다. 이는 컴퓨터의 HTTP 시스템 프록시 설정과는 다른 방식입니다. iOS의 네트워크 확장도 별도의 메커니즘을 사용하므로 데스크톱 YAML 필드나 스위치 위치를 모바일에 그대로 적용할 수 없습니다.

TUN을 켠 뒤 인터넷이 안 될 때는 증상별로 범위를 좁히세요

시스템 프록시는 정상인데 TUN만 작동하지 않음

  • 서비스가 실행 중인지 확인하고, 로그에 인터페이스 생성이나 라우팅 설정, 권한 오류가 나타나는지 살펴보세요.
  • 다른 VPN, 가상 네트워크 어댑터, 보안 소프트웨어가 동시에 라우팅을 바꾸는지 확인하세요. 한 번에 하나씩 비활성화하고 다시 테스트하세요.
  • IPv6 처리 설정을 확인하세요. IPv4 요청이 성공했다고 해서 모든 연결이 같은 경로를 사용한다고 볼 수는 없습니다.

일부 사이트는 열리지만 특정 앱에서 도메인 오류가 발생함

  • DNS 모듈이 활성화되어 있는지, 상위 DNS에 연결할 수 있는지, 앱에 별도의 DoH가 설정되어 있는지 확인하세요.
  • Fake-IP 필터와 직접 연결 규칙을 확인하세요. 특히 LAN 도메인, 회사 내부 도메인, 실제 주소가 필요한 서비스를 살펴보세요.
  • 연결 로그를 확인해 DNS 조회 실패인지, 규칙 선택 오류인지, 노드 연결 실패인지 구분하세요. 모든 시간 초과의 원인을 DNS로 단정하지 마세요.

클라이언트를 종료한 뒤에도 인터넷에 연결할 수 없음

먼저 TUN과 시스템 프록시를 정상적으로 끈 다음 클라이언트를 종료하세요. 프로그램이 비정상 종료됐다면 시스템 프록시가 더 이상 수신하지 않는 127.0.0.1:7890을 계속 가리키는지, 기존 VPN이나 네트워크 서비스가 복구됐는지 확인하세요. 관련 네트워크 서비스나 시스템을 다시 시작하기 전에 작업 내용을 저장하세요. 기존 설정을 기록하지 않은 채 라우팅을 한꺼번에 삭제하지 마세요.

원인을 찾지 못했다면 인터넷 연결 문제 해결과 설정 파일 확인을 참고하세요. 로그를 제출할 때는 구독 링크, 노드 비밀번호, 액세스 토큰을 가리고 오류 발생 시각, 코어 정보, 오류가 표시된 줄, 재현 절차만 남기세요.