가상 네트워크 인터페이스(TUN)와 시스템 프록시 비교: 트래픽 유입 방식과 작동 원리

트래픽 유입 방식과 아웃바운드 모드 구분하기

시스템 프록시와 TUN 모드는 ‘트래픽을 어떻게 클라이언트로 전달할지’를 결정하고, 규칙·전역·직접 연결은 ‘클라이언트에 들어온 트래픽을 어떻게 전달할지’를 결정합니다. 서로 다른 계층의 설정입니다. TUN을 켠다고 모든 연결이 원격 노드를 거치는 것은 아니며, 전역 모드를 선택해도 모든 앱의 트래픽이 자동으로 클라이언트에 들어오는 것은 아닙니다.

연결 과정은 다음 순서로 이해할 수 있습니다. 프록시 그룹 선택이나 구독 노드의 사용 가능 여부는 트래픽이 유입된 다음에 영향을 줍니다. 연결이 커널에 들어오지 않는다면 노드를 계속 바꿔도 결과가 달라지지 않는 경우가 많습니다.

앱에서 연결 시작
  → 시스템 프록시 포트 또는 TUN 가상 네트워크 인터페이스
  → Clash / mihomo 커널
  → 아웃바운드 모드 및 규칙 판정
  → DIRECT, 프록시 노드 또는 REJECT

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

시스템 프록시는 앱이 참조하는 네트워크 설정입니다. 예를 들어 클라이언트가 로컬에서 혼합 포트 127.0.0.1:7890을 수신 대기한 뒤, 이 주소를 시스템 프록시로 설정합니다. 해당 설정을 지원하는 앱은 로컬 포트에 연결하고, 커널이 이어서 대상 서버에 접속합니다. 여기서 7890은 예시일 뿐이며 실제 포트는 클라이언트 설정을 따릅니다.

HTTP, HTTPS, SOCKS 프록시의 차이

HTTP 프록시: 앱이 HTTP 요청을 프록시 서버에 전달해 처리합니다.
HTTP 프록시를 통한 HTTPS: 일반적으로 먼저 CONNECT 요청을 보내 터널을 만든 다음, 터널 안에서 TLS 핸드셰이크를 진행합니다. 클라이언트가 HTTPS 내용을 복호화한다는 뜻은 아닙니다.
SOCKS5: 앱이 SOCKS 협상을 통해 대상 주소를 전달합니다. 도메인 이름을 프록시에서 조회할지는 앱과 연결 방식에 따라 달라집니다.
혼합 포트: 하나의 수신 대기 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받습니다. 그렇다고 시스템이 모든 프로그램에 해당 포트 사용을 강제하는 것은 아닙니다.

macOS에서 확인하는 방법

macOS 13 이상에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스(예: ‘Wi-Fi’) → ‘세부사항’ → ‘프록시’로 이동해 웹 프록시, 보안 웹 프록시, SOCKS 프록시의 서버와 포트를 확인할 수 있습니다. 시스템 버전에 따라 메뉴 이름이 조금 다를 수 있습니다. Wi-Fi, 이더넷 또는 다른 네트워크 서비스로 전환했다면 이전에 사용한 서비스가 아니라 현재 서비스의 설정을 확인하세요.

브라우저, 터미널, 데스크톱 앱이 같은 프록시 설정을 사용한다고 볼 수는 없습니다. 일부 앱은 시스템 설정을 읽고, 일부는 자체 프록시 옵션을 사용합니다. 명령줄 도구는 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY 환경 변수를 참조하기도 합니다. 따라서 “브라우저에서는 되는데 터미널에서는 안 된다”는 현상은 먼저 유입 경로가 다른지 살펴볼 단서이지, 노드 장애의 증거는 아닙니다.

TUN 모드: 가상 네트워크 인터페이스와 라우팅으로 IP 트래픽 수신

TUN은 가상 3계층 네트워크 인터페이스를 제공합니다. 앱은 평소처럼 연결을 시작하고, 운영체제는 라우팅 규칙에 따라 조건에 맞는 IP 패킷을 가상 인터페이스로 전달합니다. 커널은 전달받은 패킷을 처리합니다. 앱이 HTTP 또는 SOCKS 프록시를 직접 지원할 필요가 없어 시스템 프록시 설정을 읽지 않는 프로그램에도 자주 사용됩니다.

macOS에서 가상 인터페이스는 보통 utun 계열 장치로 나타납니다. 다만 시스템 VPN이나 다른 네트워크 서비스도 같은 종류의 인터페이스를 만들 수 있으므로, utun이 보인다는 이유만으로 클라이언트가 트래픽을 정상적으로 가로챘다고 판단할 수는 없습니다. 클라이언트 로그, 라우팅 정보, 연결 기록도 함께 확인해야 합니다.

활성화 조건과 기능상 한계

권한: 인터페이스 생성이나 라우팅 설정에는 보통 관리자 권한 또는 클라이언트의 서비스 구성 요소가 필요합니다. 권한 승인이 완료되어도 이후 라우팅이 올바르다는 보장은 없습니다.
커널: TUN 제공 여부와 지원하는 네트워크 스택 및 필드는 실제 사용 중인 커널을 기준으로 확인해야 합니다. 클라이언트 이름에 Clash가 들어간다고 해서 반드시 mihomo를 사용하는 것은 아닙니다.
UDP: TUN으로 조건에 맞는 UDP 트래픽을 커널에 전달할 수 있지만, 원격 노드와 프로토콜도 UDP 전달을 지원해야 합니다. 스위치를 켜는 것만으로 노드의 기능이 추가되지는 않습니다.
적용 범위: IPv6, 로컬 네트워크, 제외 라우팅, 다른 VPN이 트래픽 가로채기 범위에 영향을 줄 수 있습니다. TUN이 모든 2계층 브로드캐스트 트래픽을 완전히 가로채는 것도 아닙니다.

mihomo의 auto-route는 관련 라우팅을 자동으로 설정하고, auto-detect-interface는 아웃바운드 인터페이스를 자동으로 감지합니다. 일반적인 네트워크 환경에서는 설정에 도움이 되지만, 회사 VPN·가상 머신 네트워크·다중 네트워크 인터페이스 구성과 완벽하게 호환된다는 보장은 없습니다.

시스템 프록시와 TUN의 실제 차이

확인 항목	시스템 프록시	TUN 모드
트래픽 유입 방식	앱이 로컬 프록시 포트에 직접 연결	라우팅을 통해 IP 패킷을 가상 네트워크 인터페이스로 전달
앱 호환 조건	앱이 시스템 설정을 읽거나 프록시를 직접 설정해야 함	대체로 앱에서 프록시 옵션을 제공할 필요 없음
UDP 사용 조건	앱과 프록시 프로토콜에 따라 다름. 일반 HTTP 프록시만으로 모든 UDP 트래픽을 처리할 수는 없음	라우팅, 커널, 노드의 UDP 지원 여부에 따라 다름
권한 및 영향 범위	주로 네트워크 서비스의 프록시 설정을 변경	가상 인터페이스와 라우팅을 설정하며 DNS 트래픽도 가로챌 수 있음
주요 문제 해결 지점	포트 수신 대기 상태, 앱의 프록시 설정, 우회 목록	권한 상태, 라우팅, DNS, IPv6, VPN 충돌

두 방식 사이에 정해진 속도 순위는 없습니다. 같은 요청이 같은 노드를 사용한다면 체감 속도는 보통 노드 부하, 연결 품질, 대상 서비스의 영향을 더 많이 받습니다. TUN은 트래픽 처리 단계가 하나 더 있지만 반드시 느리다고 단정할 수는 없습니다. 시스템 프록시 경로가 더 직접적이어도 앱이 기대한 대로 설정을 사용하는 것은 아닙니다.

DNS: 조회 위치에 따라 도메인 규칙에 전달되는 정보가 달라집니다

시스템 프록시를 사용할 때 앱은 도메인 이름을 프록시에 전달할 수도 있고, 로컬에서 먼저 조회할 수도 있습니다. 예를 들어 curl의 socks5://는 일반적으로 대상 도메인을 로컬에서 조회하고, socks5h://는 도메인 이름을 SOCKS 프록시에 전달합니다. 포트가 같아도 DNS 조회 경로는 다를 수 있습니다.

TUN이 받는 데이터는 주로 IP 패킷입니다. 앱이 도메인을 실제 IP 주소로 이미 변환했다면 커널이 원래 도메인을 자동으로 알아내지 못할 수 있습니다. DNS 가로채기, Fake-IP 매핑, 트래픽 스니핑은 도메인 규칙에 필요한 정보를 제공할 수 있지만 각각의 역할은 다릅니다.

DNS 가로채기: 조건에 맞는 DNS 요청을 커널의 DNS 모듈로 전달합니다. 흔히 사용하는 53번 포트 가로채기만으로는 앱에 내장된 DoH나 DoT를 직접 복호화할 수 없습니다.
Fake-IP: 커널이 매핑된 주소를 반환하고 도메인과 주소의 대응 관계를 저장합니다. 자주 사용하는 주소 대역은 198.18.0.0/16이며, 이 주소는 원격 노드 주소가 아닙니다.
스니핑: 일부 TLS ClientHello의 SNI처럼 확인 가능한 프로토콜 특성에서 대상 도메인을 알아내려고 시도합니다. HTTPS를 복호화하는 기능은 아니며, 암호화된 클라이언트 헬로 등에는 한계가 있습니다.

mihomo 설정 일부를 확인하는 방법

아래 내용은 관련 필드만 보여 주는 예시이며 전체 설정이 아닙니다. 사용하기 전에 클라이언트가 해당 필드를 지원하는 mihomo를 실제로 실행하는지 확인하고, 기존 DNS 업스트림, 프록시 노드, 규칙 설정을 유지하세요. 클라이언트에서 그래픽 설정으로 구성을 생성한다면 해당 설정 화면을 사용하는 것이 좋습니다. 구독을 새로고침할 때 수동 변경 사항이 덮어써질 수 있습니다.

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

여러 설정을 한꺼번에 바꾸지 말고 유입 경로별로 확인하세요

1단계: 로컬 프록시 포트만 따로 테스트

먼저 TUN을 끄고 커널은 실행 상태로 둔 다음, 프록시를 명시한 명령으로 테스트하세요. 아래 예시는 혼합 포트가 7890인 경우입니다. 클라이언트에 다른 포트가 표시된다면 명령도 같은 값으로 바꾸세요. 명령에 15초 제한 시간을 설정하고 연결 단계 정보를 출력해 포트 연결 거부, TLS 오류, 대상 서버 응답 시간 초과를 구분할 수 있습니다.

curl -I -v --max-time 15 \
  --proxy http://127.0.0.1:7890 \
  https://example.com/

curl -I -v --max-time 15 \
  --proxy socks5h://127.0.0.1:7890 \
  https://example.com/

127.0.0.1:7890 연결이 거부되면 먼저 커널이 실행 중인지, 포트 번호가 일치하는지, 다른 프로그램이 포트를 사용 중인지 확인하세요. 프록시 핸드셰이크는 성공했지만 대상 서버 응답이 시간 초과되면 노드와 아웃바운드 규칙을 확인합니다. 테스트 주소 하나에 연결되었다고 해서 모든 사이트가 정상이라는 뜻은 아닙니다.

2단계: 앱이 시스템 프록시를 사용하는지 확인

시스템 프록시를 켜고 macOS 터미널에서 scutil --proxy를 실행해 현재 프록시 설정을 확인한 다음, 해당 앱의 독립 프록시 설정과 우회 목록을 살펴보세요. 터미널에서는 env | grep -i proxy로 설정된 프록시 환경 변수를 확인할 수 있습니다. 시스템 프록시 설정이 올바른지와 앱이 실제로 그 설정을 사용하는지는 각각 따로 확인해야 합니다.

3단계: TUN만 따로 테스트

시스템 프록시를 끄고 TUN을 켠 뒤 대상 앱의 연결을 새로 시작하세요. 아래 명령으로 curl에 명시된 프록시 설정의 영향을 제외한 다음, 클라이언트의 연결 화면에서 기록을 확인할 수 있습니다. 이 명령은 curl의 프록시 사용만 제외하며 TUN 라우팅을 우회하지는 않습니다.

curl -I -v --max-time 15 --noproxy '*' https://example.com/

해당 연결 기록이 없다면 TUN 시작 로그, 제외 라우팅, IPv6 경로, 다른 VPN을 중점적으로 확인하세요. 기록이 있다면 적용된 규칙과 최종 아웃바운드를 확인합니다. 설정을 바꾸기 전에 이미 연결된 장시간 연결은 이전 경로를 계속 사용할 수 있으므로, 필요한 경우 대상 앱을 완전히 종료한 뒤 다시 여세요.

사용 사례별 선택: 먼저 시스템 프록시를 쓰고 필요할 때 TUN 추가

주로 브라우저를 사용하는 경우: 시스템 프록시는 적용 범위를 확인하기 쉽습니다. 먼저 브라우저가 시스템 설정을 실제로 따르는지 확인하세요.
터미널 개발 도구: 프록시 매개변수나 환경 변수를 직접 지정하는 방법을 우선 고려하세요. 프록시를 지원하지 않는 여러 프로그램을 한꺼번에 처리해야 할 때 TUN을 검토할 수 있습니다.
게임이나 기타 UDP 앱: 먼저 노드의 UDP 지원 여부를 확인한 다음 TUN 라우팅과 앱 연결 기록을 살펴보세요. 시스템 HTTP 프록시만 켜서는 이런 트래픽을 처리하기 어려운 경우가 많습니다.
회사 VPN 및 사내 네트워크: 사내 도메인, 사설 IP 대역, DNS를 각각 확인하세요. 필요하면 제외 라우팅과 직접 연결 규칙을 조정하되, 회사에서 요구하는 네트워크 설정을 그대로 덮어쓰지 마세요.

시스템 프록시와 TUN을 함께 켤 수는 있지만 문제를 해결할 때는 먼저 각각 따로 검증하는 편이 좋습니다. 앱이 로컬 프록시 포트에 명시적으로 연결하면 해당 프록시 경로를 계속 사용할 수 있고, 다른 연결은 TUN이 받을 수 있습니다. 두 설정을 켠다고 원격 프록시를 반드시 두 번 거치는 것은 아닙니다. 또한 모든 구성에서 커널이 라우팅 충돌을 자동으로 처리한다고 가정해서도 안 됩니다.

끄고 난 뒤에도 인터넷에 연결되지 않을 때 복구 방법

먼저 클라이언트에서 TUN과 시스템 프록시를 끈 다음, 클라이언트를 정상적으로 종료해 설정한 라우팅과 프록시를 되돌릴 수 있도록 하세요.
현재 네트워크 서비스의 프록시 설정을 확인하고, 더 이상 수신 대기하지 않는 로컬 포트를 가리키는 설정을 삭제하세요. 조직에서 관리하는 설정은 관리자에게 문의하세요.
터미널 프록시 환경 변수, 앱별 프록시 설정, 다른 VPN이 여전히 작동 중인지 확인한 뒤 네트워크 연결을 다시 설정하세요.
로컬 네트워크나 도메인 조회에 계속 문제가 있으면 라우팅 및 DNS 상태를 기록하고 해당 클라이언트의 복구 절차를 따르세요. 모든 네트워크 서비스를 무작정 삭제하지 마세요.

최종 판단은 확인 가능한 연결 경로를 기준으로 해야 합니다. 앱 트래픽이 커널에 들어오는지, 도메인이 어떻게 조회되는지, 어떤 아웃바운드 규칙이 적용되는지를 확인하세요. 이 세 가지를 나눠 살펴보면 시스템 프록시와 TUN 스위치를 반복해서 바꾸는 것보다 문제를 찾기 쉽습니다.