TUN 모드와 시스템 프록시 차이: macOS 트래픽 처리 방식 비교

먼저 구분할 것: 트래픽 진입 경로와 프록시 규칙

브라우저는 접속되는데 터미널에서는 연결 시간이 초과된다면, 노드를 바꾸기 전에 트래픽이 클라이언트로 들어오는지부터 확인하세요. 시스템 프록시와 TUN은 트래픽의 진입 경로를 정하고, 규칙 모드와 전역 모드는 트래픽이 커널에 들어온 뒤 어떤 경로로 나갈지를 결정합니다. 서로 다른 문제를 다루는 설정입니다.

시스템 프록시는 macOS 네트워크 설정에 로컬 프록시 주소를 등록합니다. 앱이 해당 설정을 읽고 사용해야 요청을 프록시로 보냅니다. TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 설정해, 처리 범위에 포함된 IP 패킷을 커널로 전달합니다. mihomo는 Clash 설정 생태계와 호환되는 프록시 커널이며, 클라이언트는 인터페이스와 설정 관리, 권한 서비스를 제공합니다.

비교 항목	시스템 프록시	TUN 모드
트래픽 진입 경로	앱이 프록시 설정을 읽고 로컬 포트에 직접 연결	가상 네트워크 인터페이스와 라우팅을 통해 IP 패킷을 커널로 전달
주요 대상	시스템 설정을 따르는 브라우저와 데스크톱 앱	시스템 프록시를 사용하지 않는 프로그램, 일부 UDP 앱
터미널 명령	대개 프록시 옵션이나 환경 변수를 지정해야 함	라우팅이 적용되면 명령마다 설정할 필요가 없는 경우가 많음
권한 요구 사항	대개 TUN 보조 서비스를 설치할 필요 없음	인터페이스와 라우팅 설정을 위해 보조 서비스 권한이 필요한 경우가 많음
DNS 처리	앱과 프록시 프로토콜에 따라 다름	DNS 하이재킹과 커널 DNS를 함께 사용할 수 있지만 적용 범위에는 한계가 있음

시스템 프록시: 설정과 로컬 포트 확인

macOS에 프록시 설정이 적용됐는지 확인하기

macOS 13 이상을 기준으로 ‘시스템 설정’ → ‘네트워크’ → ‘Wi-Fi’ → ‘세부사항’ → ‘프록시’를 엽니다. 유선 연결은 현재 사용 중인 이더넷 서비스를 확인하세요. 클라이언트에서 시스템 프록시를 켠 뒤 웹 프록시, 보안 웹 프록시 또는 SOCKS 프록시의 주소와 포트를 확인합니다. 실제로 어떤 항목이 설정되는지는 클라이언트에 따라 다릅니다.

주소는 보통 127.0.0.1이며, 이는 현재 Mac을 가리킵니다. 포트는 클라이언트가 실제로 수신 대기 중인 포트와 일치해야 합니다. 아래 명령에서는 HTTP와 SOCKS가 함께 사용하는 혼합 포트 7890을 예로 들었으며, 모든 클라이언트의 기본값이라는 뜻은 아닙니다. 먼저 클라이언트의 포트 설정을 확인한 다음 명령을 실행하세요.

# macOS의 현재 통합 프록시 설정 확인
scutil --proxy

# 예시 포트에서 TCP 수신 대기 중인 프로세스 확인
lsof -nP -iTCP:7890 -sTCP:LISTEN

scutil --proxy에서 HTTPEnable, HTTPSEnable 또는 SOCKSEnable을 확인하고 해당 포트도 대조하세요.
lsof에 출력이 없다면 포트 번호를 잘못 입력했는지, 커널이 실행 중인지, 포트가 다른 값으로 변경됐는지부터 확인하세요.
수신 대기 중인 프로세스가 현재 클라이언트가 아니라면 포트 충돌을 먼저 확인하세요. 같은 주소를 두 클라이언트가 동시에 사용하지 않도록 합니다.

시스템 프록시를 켰다고 모든 앱이 즉시 전환되는 것은 아닙니다. 앱이 자체 네트워크 스택이나 기존 연결, 별도 프록시 설정을 사용할 수 있습니다. 설정을 바꾼 뒤 새 요청을 보내고, 필요하면 대상 앱을 재시작한 다음 클라이언트의 연결 기록을 확인하세요. 메뉴 막대의 스위치만 보고 성공 여부를 판단하지 마세요.

터미널 명령: 프록시를 직접 지정해 진입 경로 확인

명령줄 도구가 macOS 시스템 프록시를 사용하는지는 각 도구의 구현에 따라 다릅니다. 흔히 사용하는 curl은 프록시 환경 변수를 읽지만, 시스템 프록시 설정을 자동으로 따른다고 단정할 수는 없습니다. 먼저 프록시 옵션을 직접 지정해 테스트하면 ‘프록시 진입 경로 문제’와 ‘사이트 연결 문제’를 구분할 수 있습니다.

먼저 HTTP 프록시를 지정한 뒤 SOCKS를 테스트하세요

# 로컬 HTTP 프록시로 HTTPS 요청을 보내고 최대 15초 대기
curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 15 -I https://example.com

# SOCKS5를 사용하고 대상 도메인 이름은 프록시에서 조회
curl --proxy socks5h://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 15 -I https://example.com

두 번째 명령은 해당 포트가 SOCKS를 지원할 때만 사용할 수 있습니다. socks5h의 h는 대상 호스트 이름을 프록시에서 조회한다는 뜻입니다. socks5를 사용하면 curl은 일반적으로 로컬에서 먼저 이름을 조회합니다. 두 방식의 차이는 DNS 문제를 진단할 때 결과에 직접 영향을 줍니다.

연속해서 사용할 때는 임시 환경 변수를 설정하세요

# 현재 터미널 세션과 이후 실행되는 하위 프로세스에만 적용
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

# 테스트가 끝나면 이후 오용을 막기 위해 삭제
unset http_proxy https_proxy

https_proxy 값을 http://로 지정해도 모순이 아닙니다. 이는 로컬 프록시 진입 경로의 프로토콜을 나타내며, HTTPS 대상은 보통 HTTP CONNECT 터널을 통해 연결됩니다. 대상 사이트와의 TLS 암호화가 자동으로 해제되는 것은 아닙니다.

환경 변수를 바로 셸 시작 파일에 추가하지 마세요. 현재 터미널에서 테스트가 성공한 뒤 ~/.zshrc에 추가할지 결정하세요. GUI 앱은 터미널의 환경 변수를 보통 상속하지 않습니다. 도구마다 지원하는 변수명과 대소문자, 우회 목록도 다를 수 있습니다.

TUN 모드: 권한, 라우팅, 규칙 기반 트래픽 분기

TUN은 IP 패킷을 처리하는 3계층 가상 네트워크 인터페이스입니다. macOS에서 클라이언트는 보통 특권 보조 서비스를 통해 인터페이스를 만들거나 관리하고 라우팅을 설정합니다. 켜기 전에 유효한 설정을 선택하고 커널이 정상적으로 시작되는지 확인한 다음, 클라이언트 안내에 따라 보조 서비스를 설치하고 시스템 권한을 부여하세요. 시스템 로그인 암호를 구독 페이지나 설정 파일에 입력하지 마세요.

최소 설정에서 주요 항목 이해하기

아래는 mihomo 설정 예시로, 자주 쓰이는 항목을 설명하기 위한 것이며 완전한 구독 설정은 아닙니다. 클라이언트에 따라 인터페이스에서 해당 항목을 생성하거나 구독 설정의 값을 덮어쓸 수 있습니다. 수정하기 전에 설정을 백업하고 최종 적용된 설정을 확인하세요. 구독 설정 전체를 그대로 덮어쓰지 마세요.

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

dns:
  enable: true
  enhanced-mode: fake-ip

enable은 TUN을 활성화합니다. 충분한 시스템 권한이 있고 커널이 정상적으로 시작되어야 합니다.
stack은 네트워크 스택 구현을 선택합니다. 예시는 mixed를 사용하지만 모든 Mac과 네트워크 환경에서 다른 옵션보다 낫다는 뜻은 아닙니다.
auto-route는 라우팅 자동 설정을 요청하고, auto-detect-interface는 아웃바운드 인터페이스를 자동으로 식별합니다. Wi-Fi, 유선 네트워크 또는 핫스팟을 전환한 뒤에는 트래픽이 나가는 경로를 다시 확인하세요.
dns-hijack은 하이재킹 대상을 지정합니다. any:53은 해당 처리 경로로 들어오는 기존 53번 포트 DNS 요청에 적용되며, 모든 암호화 DNS를 가로채지는 않습니다.

이 설정만으로는 노드, 정책 그룹, 규칙, 적절한 상위 DNS 등이 부족합니다. 우선 클라이언트가 지원하는 방식으로 설정하세요. 커널에서 필드 오류가 발생하면 먼저 실제 커널 종류와 버전을 확인한 뒤 해당 문서에 맞춰 수정합니다.

TUN 스위치와 전역 모드 구분하기

TUN을 켜면 트래픽이 mihomo로 들어오지만 규칙 모드에서는 도메인, IP 또는 다른 조건에 따라 계속 규칙을 적용할 수 있습니다. 직접 연결 규칙에 해당하면 직접 연결되고, 프록시 그룹에 해당하면 그룹에서 선택한 출구를 사용합니다. 전역 모드는 보통 트래픽을 전역 정책 그룹으로 보내지만, 진입 범위와 라우팅 제외의 영향을 받습니다. 트래픽 처리 범위를 넓히려면 TUN을 켜고, 출구 선택을 바꾸려면 규칙과 정책 그룹을 확인하세요.

DNS: 웹이 열린다고 같은 경로로 조회되는 것은 아닙니다

DNS는 도메인 이름을 IP 주소로 변환합니다. 시스템 프록시는 앱이 프록시에 연결하는 방식을 바꿀 뿐, 모든 앱의 도메인 조회를 통합 제어하지는 않습니다. 브라우저는 도메인 이름을 프록시로 보낼 수도 있고 자체 보안 DNS를 사용할 수도 있습니다. 다른 프로그램은 시스템 DNS로 먼저 조회한 다음 결과 IP에 연결할 수 있습니다.

TUN은 커널 DNS와 함께 더 많은 DNS 요청을 처리할 수 있습니다. fake-ip를 활성화하면 커널이 도메인에 매핑용 가상 주소를 할당하고, 연결 단계에서 실제 대상과 연결합니다. 198.18.0.0/15 범위의 주소가 보이더라도 반드시 오류인 것은 아닙니다. 실제 설정된 fake-ip 주소 범위를 기준으로 판단하세요.

DNS 조회 문제를 세 단계로 확인하기

시스템 진입 경로를 확인합니다. scutil --dns를 실행해 현재 리졸버를 확인하세요. 시스템 설정을 보여주는 명령이며, 모든 앱이 해당 리졸버를 사용한다는 뜻은 아닙니다.
커널 로그를 확인합니다. 클라이언트의 연결 및 로그 화면을 열고 같은 도메인으로 새 요청을 보낸 뒤 DNS 요청, 규칙 적용, 출구 선택이 기록되는지 확인하세요.
앱 자체 설정을 확인합니다. 브라우저의 보안 DNS, 앱 내 프록시 및 암호화된 DNS 설정을 살펴보세요. DoH는 HTTPS로 전송되고 DoT는 보통 853번 포트를 사용하므로, 53번 포트 하이재킹만으로는 모두 처리할 수 없습니다.

dig를 한 번 실행한 결과만으로 시스템 전체의 DNS 경로를 단정하지 마세요. macOS의 도메인별 조회, VPN 리졸버, 앱 캐시로 결과가 달라질 수 있습니다. 또한 dig의 조회 경로는 앱이 시스템 조회 서비스를 호출하는 방식과 완전히 같지 않습니다. 문제를 진단할 때는 대상 도메인, 시간, 사용한 도구를 기록하고 서로 다른 테스트 결과를 혼동하지 마세요.

게임과 UDP: 트래픽 처리 후에도 노드 확인 필요

게임은 TCP와 UDP를 함께 사용하는 경우가 많습니다. 기존 HTTP 시스템 프록시는 게임이 직접 보내는 UDP 패킷을 처리하지 못하는 경우가 일반적입니다. SOCKS 프로토콜에는 UDP 릴레이 기능이 있지만, 앱도 이를 지원하고 사용해야 합니다. TUN은 이런 트래픽을 더 많이 커널로 전달할 수 있어 시스템 프록시를 따르지 않는 게임 연결을 진단할 때 유용합니다.

다만 가상 네트워크 인터페이스가 원격 노드에 UDP 기능을 추가해 주는 것은 아닙니다. 노드 프로토콜, 서버 설정, 정책 그룹에서 선택한 출구, 로컬 네트워크에 따라 UDP가 제한될 수 있습니다. 먼저 클라이언트 연결 목록에 게임 연결이 표시되는지 확인하고, DIRECT와 프록시 그룹 중 어떤 규칙이 적용됐는지 살펴본 뒤, 선택한 노드가 필요한 트래픽을 지원하는지 확인하세요.

로그인은 되지만 게임에 접속할 수 없음: 로그인 단계의 TCP 요청과 게임 단계의 UDP 연결을 따로 확인하세요. 로그인 화면만 테스트해서는 부족합니다.
연결은 되지만 지연 시간이 김: 같은 서버와 같은 시간대에 게임 내 지연 시간과 패킷 손실을 비교하세요. 노드 목록의 HTTP 속도 테스트 결과가 게임 지연 시간과 같지는 않습니다.
로컬 네트워크 게임이나 기기 검색에 문제가 있음: 로컬 서브넷 우회 정책을 확인하세요. 브로드캐스트, 멀티캐스트, 검색 프로토콜은 일반적인 원격 유니캐스트 연결처럼 처리하면 안 됩니다.

앱이 특정 네트워크 인터페이스, 안티치트 구성 요소 또는 특수한 전송 방식을 필요로 한다면 TUN에서도 호환성을 보장할 수 없습니다. 기존 네트워크 설정과 복구 방법을 유지하고 한 번에 하나씩 변경해야 문제가 트래픽 처리 방식, 규칙 또는 출구 중 어디에서 비롯됐는지 판단할 수 있습니다.

Mac에서 설정 선택 및 연결 문제 복구 순서

앱 사용 방식에 맞춰 진입 경로 선택하기

주로 브라우저와 시스템 프록시를 따르는 앱을 사용: 먼저 시스템 프록시를 켜세요. 설정이 직관적이고 로컬 포트도 확인하기 쉽습니다.
터미널을 가끔 사용: 명령에 --proxy를 지정하거나 현재 세션에 환경 변수를 설정해 영향 범위를 분명히 하세요.
여러 프로그램이 프록시를 무시하거나 UDP 처리가 필요: TUN을 고려하되 보조 서비스, DNS, 라우팅도 함께 확인하세요.
회사 VPN에 연결 중: 먼저 조직의 네트워크 지침을 따르세요. 두 도구 모두 라우팅과 DNS를 변경할 수 있으므로 바로 함께 사용하지 말고 각각 테스트하세요.

TUN을 켠 뒤 인터넷이 끊기면 먼저 복구한 다음 원인 확인

TUN을 끄되 클라이언트는 실행 상태로 두고 일반 네트워크 연결이 복구되는지 확인하세요. 여러 구독을 번갈아 가져오지는 마세요.
시스템 프록시를 끄고 테스트용 터미널의 프록시 환경 변수도 지운 다음 직접 연결되는지 확인하세요. all_proxy나 대문자 변수도 설정했다면 해당 항목도 삭제해야 합니다.
scutil --proxy를 실행해 남아 있는 프록시 설정을 확인하고, route -n get default로 기본 경로를 살펴보세요. TUN은 더 구체적인 분할 라우트를 사용할 수 있으므로 기본 경로만으로 전체 처리 결과를 판단할 수 없습니다.
netstat -rn -f inet으로 IPv4 라우팅을 확인하고, IPv6도 확인해야 한다면 netstat -rn -f inet6을 실행하세요. utun 인터페이스가 보여도 현재 클라이언트가 만든 것이라고 단정할 수 없습니다. 다른 VPN도 이 인터페이스를 사용할 수 있습니다.
연결이 복구된 것을 확인한 뒤 진입 방식을 하나만 켜고 다시 테스트하세요. TUN에서만 문제가 발생한다면 서비스 권한, 라우팅 충돌, DNS 로그를 확인하세요.

시스템 프록시와 TUN 중 어느 쪽이 항상 더 낫다고 할 수는 없습니다. 시스템 프록시는 프록시를 직접 사용하는 앱에 적합하고, TUN은 트래픽 처리 범위를 넓히는 대신 라우팅·권한·DNS 관련 점검 항목이 늘어납니다. 모든 옵션을 한꺼번에 켜기보다 현재 작업에 필요한 최소 설정부터 적용한 뒤 범위를 넓혀야 관리하기 쉽습니다.