TUN 모드 설정 방법: 가상 네트워크 어댑터로 전체 트래픽을 처리하는 원리와 설정 단계

TUN 모드는 ‘노드 연결 여부’를 해결하는 기능이 아닙니다

일반 시스템 프록시는 운영체제에 HTTP 또는 SOCKS 프록시 주소를 등록합니다. 시스템 프록시 설정을 따르는 브라우저와 앱은 요청을 로컬 인바운드 포트로 보내지만, 해당 설정을 무시하거나 자체 네트워크 스택을 사용하거나 UDP 연결을 직접 생성하는 프로그램은 기본 네트워크 어댑터를 통해 계속 직접 연결할 수 있습니다. 이때 노드 자체는 정상적으로 작동해도 프로그램의 트래픽이 클라이언트로 전달되지 않습니다.

TUN 모드가 바꾸는 것은 트래픽의 진입점입니다. 클라이언트는 가상 3계층 네트워크 어댑터를 만들고 시스템 라우팅 테이블에 트래픽을 넘길 규칙을 기록합니다. 앱이 보낸 IP 패킷은 먼저 가상 네트워크 어댑터로 들어간 다음 v2rayN 또는 v2rayNG를 거쳐 Xray 코어에서 처리됩니다. 코어는 도메인, 대상 IP, 포트와 프로토콜에 따라 라우팅 규칙을 적용하고 최종적으로 직접 연결, 프록시 또는 차단 출구를 선택합니다.

‘전체 트래픽 처리’가 모든 데이터를 조건 없이 원격 노드로 보낸다는 뜻은 아닙니다. LAN 주소, 클라이언트 자체 연결, 시스템 예약 대역과 명시적으로 설정한 직접 연결 규칙은 프록시를 우회해야 합니다. 올바른 TUN 설정에서는 프록시 루프도 피해야 합니다. 코어가 서버에 연결할 때 발생하는 트래픽이 다시 같은 프록시 경로로 들어가면 연결 시간 초과, CPU 사용량 증가 또는 네트워크 전체 중단이 발생할 수 있습니다.

• 시스템 프록시: 설정이 간단하며 프록시 설정을 따르는 브라우저와 일반 데스크톱 앱에 적합합니다.
• TUN 모드: 적용 범위가 더 넓어 시스템 프록시를 읽지 않는 TCP 및 대부분의 UDP 프로그램도 처리할 수 있습니다.
• 분할 라우팅: 코어에 들어온 트래픽의 경로를 결정하며, TUN 활성화 여부와는 서로 다른 계층의 설정입니다.
• 노드 프로토콜: VMess, VLESS 등은 클라이언트와 서버 사이의 전송을 담당하며, 로컬 앱이 프록시를 사용하도록 만드는 기능은 아닙니다.

시작 전 권한, 코어와 기존 네트워크 구성 확인

가상 네트워크 어댑터를 만들고 시스템 라우팅 테이블을 수정하려면 높은 수준의 권한이 필요합니다. Windows의 v2rayN은 일반적으로 관리자 권한으로 실행해야 TUN을 사용할 수 있습니다. macOS와 Linux에서는 네트워크 인터페이스를 처음 만들거나 라우팅을 기록할 때 시스템 권한을 요청합니다. Android의 v2rayNG는 시스템이 제공하는 VPN 서비스로 가상 인터페이스를 만들며, 처음 시작할 때 연결 권한 확인 창이 표시됩니다.

아래 버전은 이 글의 참고 환경을 표시하기 위한 예시이며 프로토콜 호환성을 보장하는 최소 버전이 아닙니다. 버전에 따라 메뉴 이름은 달라질 수 있지만 확인 순서는 같습니다. 먼저 코어가 실행되는지 확인하고, 다음으로 가상 네트워크 어댑터가 존재하는지 확인한 뒤, 기본 라우팅과 DNS가 전환되었는지 점검하세요.

1. 먼저 일반 시스템 프록시 모드에서 같은 노드에 연결해 서버 주소, 포트, 사용자 식별자, TLS 또는 REALITY 매개변수가 유효한지 확인하세요.
2. 가상 네트워크 어댑터를 만들거나 기본 라우팅을 수정하거나 DNS를 처리하는 다른 네트워크 프로그램을 종료해 두 규칙이 동시에 적용되지 않도록 하세요.
3. 현재 사용하는 LAN 대역을 기록하세요. 예를 들어 가정용 라우터에서 흔히 사용하는 주소는 192.168.1.0/24이며, 이 대역은 일반적으로 직접 연결로 유지해야 합니다.
4. 로컬 포트 충돌 여부를 확인하세요. 10808이 다른 프로세스에서 사용 중이라면 클라이언트 매개변수 설정에서 포트를 바꾼 뒤 코어를 다시 시작하세요.
5. 정상적으로 작동하는 노드 하나를 기준으로 유지하세요. 구독에 여러 노드가 있어도 TUN 문제를 점검하는 동안 노드를 계속 바꾸지 마세요.

v2rayN 데스크톱에서 TUN을 활성화하는 전체 단계

먼저 구독을 업데이트하고 일반 프록시로 이미 검증한 노드를 선택하세요. VMess와 VLESS 모두 TUN의 프록시 출구로 사용할 수 있습니다. TUN은 노드 필드를 변경하지 않으며 구독을 다시 생성할 필요도 없습니다. 가져온 노드가 일반 모드에서 연결되지 않는다면 먼저 노드 설정을 수정한 후 가상 네트워크 어댑터를 점검하세요.

1. 실행 권한: v2rayN을 완전히 종료하세요. Windows에서는 관리자 권한으로 다시 실행하고, macOS 또는 Linux에서는 시스템 안내가 표시될 때 네트워크 설정 변경을 승인하세요.
2. 인바운드 매개변수 확인: 「설정」→「매개변수 설정」을 열고 로컬 혼합 포트가 사용 중이 아닌지 확인하세요. 이 글의 예시는 10808입니다.
3. TUN 매개변수 확인: 「설정」→「매개변수 설정」→「TUN 모드 설정」으로 이동하세요. 먼저 기본 스택과 기본 MTU를 유지하고 여러 고급 항목을 동시에 변경하지 마세요.
4. 라우팅 모드 선택: 메인 화면에서 필요한 라우팅 규칙을 선택하세요. 처음 검증할 때는 프록시 적용 범위가 넓은 규칙을 사용하고, 처리가 정상임을 확인한 뒤 도메인과 IP 기준의 분할 라우팅으로 되돌리는 것이 좋습니다.
5. TUN 켜기: 메인 화면의 「TUN 모드」스위치를 활성화하세요. 상태 표시줄에 코어 실행 상태가 나타나고 시스템 네트워크 목록에 새 가상 인터페이스가 표시되어야 합니다.
6. 연결 확인: 브라우저, 명령줄 프로그램과 이전에 프록시를 사용하지 못했던 앱을 각각 테스트하세요. 브라우저만 성공한다면 시스템 프록시 스위치만 확인하지 말고 라우팅 테이블과 DNS를 계속 점검해야 합니다.

활성화한 뒤 웹페이지 하나만으로 결과를 판단하지 마세요. 터미널에서 도메인 조회를 한 번 실행하고, IP 규칙에 따라 분할 라우팅되는 대상을 방문하면서 v2rayN 로그의 인바운드 기록도 확인하세요. 로그에 TUN에서 들어온 새 연결이 표시되면 데이터가 코어에 진입한 것입니다. 로그가 전혀 없다면 문제는 권한, 가상 인터페이스 또는 시스템 라우팅에 있을 가능성이 높습니다.

Android에서 v2rayNG로 트래픽을 처리하는 단계

v2rayNG는 Android의 VPN 서비스로 가상 네트워크 인터페이스를 만들므로 연결 버튼으로 시작되는 것은 단순한 로컬 HTTP 프록시가 아닙니다. Xray 코어를 사용할 때 앱 트래픽은 가상 인터페이스로 들어간 뒤 라우팅 모듈로 전달되므로 시스템 프록시 설정을 읽지 않는 앱도 규칙에 따라 처리할 수 있습니다.

1. 구성 가져오기: 구독 링크로 서버 목록을 업데이트하거나 완전한 VMess, VLESS 구성을 가져오세요. 노드를 선택한 뒤 실제 연결 지연 테스트를 한 번 실행하세요.
2. 실행 모드 확인: 「설정」→「모드」를 열고 로컬 프록시 포트만 LAN에 제공하는 방식이 아니라 VPN 처리 방식을 사용하도록 설정되어 있는지 확인하세요.
3. VPN 매개변수 확인: 「설정」→「VPN 설정」으로 이동해 먼저 기본 MTU를 유지하세요. 현재 네트워크에서 일부 페이지 로딩이 멈출 때만 조금씩 낮추세요.
4. 앱별 규칙 설정: 모든 앱이 같은 라우팅을 따라야 한다면 불필요한 앱 제외 항목을 끄세요. 특정 프로그램만 처리하려면 포함 모드 또는 우회 모드를 명확히 선택하세요.
5. 연결 시작: 메인 화면으로 돌아가 연결을 누르고 시스템 네트워크 연결 권한을 승인하세요. 상태 표시줄에 연결 상태가 나타난 뒤 대상 앱을 테스트하세요.
6. 로그 확인: 메인 메뉴에서 로그를 열고 DNS 조회, 라우팅 적중과 프록시 출구를 확인하세요. 계속 재연결된다면 앱이 목록에 포함되지 않은 것이 아니라 노드 실패 또는 하위 네트워크 전환일 가능성이 큽니다.

Android 시스템에서는 일반적으로 하나의 VPN 서비스만 활성 상태로 유지할 수 있습니다. 다른 네트워크 도구가 연결된 상태라면 v2rayNG가 가상 인터페이스를 만들지 못하거나 연결 직후 시스템에 의해 종료될 수 있습니다. 배터리 절전 정책이 화면이 꺼진 뒤 백그라운드 프로세스를 제한할 수도 있으므로, 화면 잠금 후 연결이 끊긴다면 v2rayNG의 백그라운드 실행과 배터리 사용 설정을 확인하세요.

• 하나의 앱만 실패하는 경우: 앱별 프록시 목록과 해당 앱이 독립 DNS 또는 특수 UDP 채널을 사용하는지 확인하세요.
• 모든 앱이 실패하는 경우: 먼저 노드, 시스템 권한과 현재 Wi-Fi 또는 모바일 네트워크가 정상인지 확인하세요.
• 연결 후 LAN 기기에 접근할 수 없는 경우: 사설 주소가 잘못 프록시 출구로 전달되지 않았는지 확인하세요.
• 모바일 네트워크는 정상인데 Wi-Fi만 이상한 경우: Wi-Fi의 DNS, IPv6와 MTU 차이를 중점적으로 확인하세요.

라우팅, DNS와 MTU가 TUN 처리 결과를 좌우합니다

TUN은 데이터를 처리 경로로 전달할 뿐이며 최종 결과는 라우팅 규칙이 결정합니다. 일반적인 규칙은 도메인, 대상 IP, 포트 또는 네트워크 유형에 따라 적용됩니다. 사설 주소와 로컬 주소는 보통 직접 연결하고, 프록시가 필요한 도메인은 프록시 출구로 보내며, 광고나 위험 도메인은 차단 출구로 보낼 수 있습니다. 규칙 순서는 매우 중요합니다. 범위가 지나치게 넓은 앞쪽 규칙이 뒤의 정밀한 규칙을 가릴 수 있습니다.

DNS는 TUN 문제를 점검할 때 가장 자주 놓치는 부분입니다. 앱이 도메인을 요청하면 클라이언트는 라우팅 판단에 사용할 도메인 또는 IP 정보를 얻어야 합니다. 조회가 다른 로컬 서비스에 가로채이거나 접근할 수 없는 주소가 반환되거나, DNS 결과의 주소 체계가 라우팅 규칙에서 사용하는 주소 체계와 다르면 ‘클라이언트는 연결되었지만 일부 도메인이 열리지 않는’ 현상이 발생합니다.

MTU를 한 번에 너무 낮추지 마세요. 1500, 1460, 1400 순서로 테스트하고, 값을 바꿀 때마다 다시 연결하세요. 같은 노드, 같은 네트워크와 같은 다운로드 대상을 사용해야 비교가 정확합니다. MTU가 너무 크면 단편화나 경로 패킷 손실이 발생할 수 있고, 너무 작으면 패킷 수와 처리 오버헤드가 증가합니다.

권장 분할 라우팅 우선순위:
1. 로컬 주소와 클라이언트 프로세스 → 직접 연결
2. LAN 및 사설 주소 → 직접 연결
3. 명시적으로 차단한 도메인 또는 IP → 차단
4. 프록시가 필요한 도메인과 주소 대역 → 프록시
5. 그 밖의 트래픽 → 현재 정책에 따라 처리

현상별로 하나씩 확인하는 일반적인 충돌 해결

TUN 문제를 점검할 때 ‘클라이언트 재설치’부터 시작할 필요는 없습니다. 진입점, DNS 조회, 라우팅, 출구의 네 계층 순서로 로그를 확인하는 편이 효과적입니다. 한 번에 하나의 변수만 변경하고, 변경 전후의 연결 시간, 로그 키워드와 실패 범위를 기록하세요.

TUN을 장기간 사용하기 적합한 환경

TUN은 여러 프로그램을 한 번에 처리하거나 UDP를 사용하거나 앱마다 프록시 주소를 설정하기 어려운 기기에 적합합니다. 각 앱에 SOCKS 포트를 따로 입력하는 수고를 줄일 수 있지만 장애 영향 범위는 넓어집니다. 잘못된 기본 라우팅 하나로 기기 전체의 인터넷이 끊길 수 있고, 지나치게 넓은 프록시 규칙 하나로 LAN 접속이 불필요하게 우회될 수 있습니다.

• 활성화를 권장하는 경우: 프로그램이 시스템 프록시를 읽지 않거나, UDP 프록시가 필요하거나, 여러 앱에 같은 분할 라우팅을 적용해야 하거나, 명령줄 도구를 자주 전환하는 경우.
• 활성화하지 않아도 되는 경우: 브라우저만 프록시가 필요하고 해당 브라우저가 시스템 프록시 설정을 안정적으로 따르는 경우.
• 규칙 기반 분할 라우팅을 권장하는 경우: LAN 기기, 중국 본토 직접 연결 서비스와 프록시 대상에 동시에 접속하면서 출구 범위를 제어하고 싶은 경우.
• 일시 중지를 권장하는 경우: 로컬 네트워크, 라우터 설정 또는 DNS 문제를 점검 중이라 가장 단순한 물리 네트워크 경로부터 복구해야 하는 경우.

유지 관리하기 쉬운 설정은 세 가지 경계를 명확히 유지해야 합니다. 클라이언트 자체 연결은 직접 연결하고, LAN과 예약 주소는 직접 연결하며, 프록시가 필요한 대상은 VMess 또는 VLESS 출구로 보냅니다. 구독 업데이트가 서버 목록만 바꾸는 경우 TUN과 라우팅 규칙을 다시 설정할 필요는 보통 없습니다. 새 구독에서 프로토콜 필드나 코어 요구 사항이 달라졌다면 먼저 일반 프록시 모드에서 노드를 검증하세요.

설정을 완료한 뒤에는 고정 테스트 세트를 유지하는 것이 좋습니다. 브라우저 접속, 터미널에서의 도메인 조회, LAN 기기 접속, UDP 앱 하나와 대용량 파일 다운로드를 테스트하세요. 다섯 가지 결과로 시스템 프록시, DNS, 사설 네트워크 대역, UDP 처리와 MTU를 각각 확인할 수 있습니다. 이후 버전 업그레이드나 라우팅 규칙 변경이 있을 때도 같은 순서로 재테스트하면 됩니다.