시스템 프록시가 작동하지 않을 때: 브라우저는 프록시를 쓰지만 터미널은 직접 연결될 때 단계별 점검

“웹페이지는 열리는데 터미널 명령은 계속 직접 연결되는” 현상은 대개 노드 자체의 문제가 아니라 애플리케이션마다 프록시 설정을 읽는 방식이 다르기 때문에 발생합니다. v2rayN은 코어를 실행한 뒤 로컬에서 SOCKS, HTTP 또는 혼합 프록시 포트를 수신 대기합니다. 시스템 프록시를 켜면 그중 하나의 진입점을 운영체제 설정에 등록할 뿐, 모든 프로세스의 트래픽을 해당 포트로 강제하지는 않습니다.

브라우저, 데스크톱 애플리케이션, PowerShell, 명령 프롬프트, Linux 셸은 시스템 프록시를 처리하는 방식이 서로 다릅니다. 문제를 점검할 때는 로컬 수신 포트가 존재하는지, 애플리케이션이 프록시 주소를 알고 있는지, 프록시 요청이 올바른 아웃바운드로 라우팅되는지 세 단계로 나눠야 합니다. 노드 지연 시간만 확인해서는 이 세 가지를 모두 점검할 수 없습니다.

시스템 프록시, 로컬 포트, TUN부터 구분하기

v2rayN의 동작은 “코어 수신”과 “애플리케이션 연결”의 두 단계로 나눌 수 있습니다. 노드를 선택하고 서비스를 시작하면 Xray 또는 v2fly 코어가 먼저 로컬에 인바운드 포트를 만듭니다. 브라우저나 터미널이 이 포트로 요청을 보내야 이후 VMess, VLESS 등의 프로토콜 연결이 이루어집니다. 노드 프로토콜과 로컬 프록시 프로토콜은 같은 개념이 아닙니다. 원격 서버가 VLESS를 사용하더라도 터미널이 VLESS를 이해해야 하는 것은 아니며, 터미널은 보통 로컬 HTTP 또는 SOCKS 진입점에 연결합니다.

시스템 프록시는 운영체제의 프록시 설정을 적극적으로 읽는 애플리케이션에 주로 영향을 줍니다. 일반적인 브라우저는 이 설정을 읽기 때문에 v2rayN의 시스템 프록시를 켜면 웹페이지가 바로 정상화됩니다. 반면 많은 명령줄 도구는 자체 설정 파일이나 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 환경 변수만 읽으므로 터미널이 대상 주소에 직접 연결할 수 있습니다.

v2rayN 시스템 프록시와 수신 포트 확인

먼저 v2rayN 메인 화면에서 현재 서버가 활성 노드로 설정되어 있고 하단 실행 상태에 지속적인 오류가 없는지 확인하세요. 그런 다음 로그를 열어 코어가 정상적으로 시작되었는지 확인합니다. 구독을 가져오거나 목록에서 행을 선택한 것만으로 프록시가 활성화된 것은 아닙니다. 구독은 노드 설정을 제공하고, 시스템 프록시는 해당 설정을 지원하는 애플리케이션을 로컬 진입점으로 연결합니다.

1. 활성 노드 확인

   서버 목록에서 노드를 하나 선택한 뒤 마우스 오른쪽 버튼 메뉴에서 활성 서버로 설정하세요. 메인 화면 하단에 코어가 실행 중이라고 표시되는지 확인하고, 시작 실패나 설정 구문 분석 오류 상태에 머물러 있지 않은지 살펴보세요.

2. 로컬 포트 확인

   「설정」→「매개변수 설정」→「기본 설정」을 열고 로컬 수신 주소, SOCKS 포트, HTTP 포트 또는 혼합 포트를 기록하세요. 이후 명령에는 이 화면에 표시된 실제 값을 사용해야 합니다.

3. 프록시 모드 설정

   「시스템 프록시」를 열고 “시스템 프록시 자동 설정” 또는 현재 버전에 해당하는 활성화 항목을 선택하세요. 이전 수동 프록시 설정이 남아 있다면 먼저 “시스템 프록시 지우기”를 선택한 후 다시 활성화하세요.

4. 라우팅 모드 확인

   「설정」→「라우팅 설정」에서 현재 규칙 집합을 확인하세요. 테스트 단계에서는 대상 도메인이 잘못된 직접 연결 아웃바운드로 전송되는 상황을 먼저 배제한 뒤, 확인이 끝나면 필요한 분기 설정을 복원할 수 있습니다.

5. 대상 애플리케이션 재시작

   브라우저나 데스크톱 애플리케이션을 완전히 종료한 뒤 다시 실행하세요. 일부 프로그램은 시작할 때만 시스템 프록시를 읽으므로 실행 중에 v2rayN 스위치를 바꿔도 기존 연결이 즉시 갱신되지 않습니다.

Windows에서는 PowerShell로 포트가 수신 대기 중인지 확인할 수 있습니다. 예시의 포트를 v2rayN 화면에 표시된 값으로 바꾸세요:

Test-NetConnection 127.0.0.1 -Port 10808
Test-NetConnection 127.0.0.1 -Port 10809

결과의 TcpTestSucceeded가 True이면 적어도 하나의 프로세스가 해당 포트의 연결을 수락하고 있다는 뜻입니다. 원격 노드가 반드시 정상이라는 의미는 아닙니다. 결과가 False라면 v2rayN으로 돌아가 코어 시작 상태, 포트 충돌, 보안 프로그램 규칙을 확인하세요. 터미널 환경 변수를 계속 설정하는 것은 다음 단계입니다.

• 포트를 다른 프로그램이 사용 중이면 로그에 수신 실패 또는 주소가 이미 사용 중이라는 메시지가 나타나는 경우가 많습니다.
• 수신 주소가 127.0.0.1이면 로컬 애플리케이션만 연결할 수 있으며, 같은 네트워크의 다른 기기에서는 직접 사용할 수 없습니다.
• 포트를 변경한 뒤에는 코어를 재시작해야 하며, 이전 터미널 창의 환경 변수도 함께 업데이트해야 합니다.
• 시스템 프록시에 기록된 포트는 현재 HTTP 또는 혼합 진입점과 일치해야 합니다. SOCKS만 지원하는 진입점을 HTTP 프록시로 입력해서는 안 됩니다.

브라우저는 정상인데 터미널이 직접 연결될 때의 해결 방법

터미널은 명령을 실행하는 환경일 뿐이며, 실제로 프록시를 읽는지는 각 프로그램이 결정합니다. curl, 패키지 관리자, 스크립트 런타임, 원격 다운로드 도구는 서로 다른 변수를 사용할 수 있습니다. 가장 확실한 방법은 먼저 단일 명령에 프록시를 명시하는 것입니다. 정상 작동을 확인한 뒤 현재 세션, 사용자 환경 또는 도구 자체 설정 파일에 저장할지 결정하세요.

먼저 curl에 프록시를 명시하세요

로컬 진입점이 HTTP 또는 혼합 프록시라면 다음 명령을 실행할 수 있습니다. --connect-timeout 5는 연결 단계의 대기 시간을 5초로 제한해 포트 거부와 원격 응답 지연을 구분하는 데 도움이 됩니다:

curl --proxy http://127.0.0.1:10809 --connect-timeout 5 https://example.com/

화면에서 10808이 SOCKS5 진입점임을 확인했다면 socks5h를 사용하세요. 끝의 h는 도메인 이름 해석도 프록시 측에서 처리한다는 뜻으로, 로컬 DNS 결과와 프록시 경로가 달라지는 문제를 피할 수 있습니다:

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 https://example.com/

현재 터미널 세션에 변수 설정

PowerShell에서 환경 변수는 현재 창과 해당 창에서 시작한 자식 프로세스에만 적용됩니다. 창을 닫으면 설정이 사라지므로 문제 해결이나 임시 작업에 적합합니다:

$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
$env:ALL_PROXY="socks5h://127.0.0.1:10808"

curl --connect-timeout 5 https://example.com/

macOS 또는 Linux 셸에서는 같은 이름의 변수를 사용할 수 있습니다. 일부 도구는 소문자 형식만 인식하므로 문제를 점검할 때는 대소문자 형식을 모두 설정할 수 있습니다:

export HTTP_PROXY="http://127.0.0.1:10809"
export HTTPS_PROXY="http://127.0.0.1:10809"
export ALL_PROXY="socks5h://127.0.0.1:10808"

export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export all_proxy="$ALL_PROXY"

환경 변수가 계속 적용되지 않을 때 항목별 확인

변수 이름이 올바르다고 해서 모든 도구가 해당 변수를 사용하는 것은 아닙니다. 일부 프로그램은 자체 설정을 우선하고, 일부는 HTTP 프록시만 지원하며, 실행 후 변수 값을 캐시하는 프로그램도 있습니다. 같은 터미널 창에서 변수 값을 확인한 직후 요청을 보내야 “새 창에 상속되지 않은 문제”와 “프록시 서버를 사용할 수 없는 문제”를 혼동하지 않을 수 있습니다.

현재 세션에서 읽은 값 확인

# PowerShell
Get-ChildItem Env:HTTP_PROXY
Get-ChildItem Env:HTTPS_PROXY
Get-ChildItem Env:ALL_PROXY

# macOS 또는 Linux 셸
env | grep -i proxy

• 변수 값에 전각 따옴표, 끝부분 주석 또는 줄바꿈이 포함되어서는 안 됩니다.
• NO_PROXY 또는 no_proxy에 대상 도메인이 포함되어 있으면 해당 요청은 프록시를 우회합니다.
• 바탕 화면 바로 가기로 실행한 터미널은 다른 터미널에서 방금 설정한 변수를 상속하지 않을 수 있습니다.
• 이미 실행 중인 개발 도구는 나중에 변경한 시스템 환경을 자동으로 읽지 않는 경우가 많으므로 완전히 종료한 뒤 다시 시작해야 합니다.
• HTTP 프록시 주소는 HTTPS 대상에 대한 CONNECT 요청을 전달할 수 있으므로 대상이 HTTPS라는 이유만으로 존재하지 않는 TLS 수신 포트로 변수 값을 바꿀 필요는 없습니다.

특정 명령 하나만 작동하지 않고 curl --proxy는 이미 성공했다면 해당 도구의 프록시 설정 우선순위를 확인하세요. 시스템 프록시, 환경 변수, 도구 설정에 서로 다른 포트를 동시에 입력하면 요청이 실제로 어느 진입점으로 들어갔는지 로그에서 판단하기 어려워집니다.

더 많은 프로그램을 가로채야 할 때 TUN 모드 사용

TUN 모드는 가상 네트워크 인터페이스를 통해 더 많은 IP 트래픽을 캡처하므로 각 애플리케이션이 시스템 프록시를 직접 읽을 필요가 없습니다. 따라서 대상 프로그램이 시스템 프록시를 명확히 무시하거나 환경 변수를 설정할 수 없거나 여러 명령줄 프로세스를 한꺼번에 제어해야 할 때는 프로그램마다 설정하는 것보다 TUN이 직접적입니다. 다만 TUN이 바꾸는 것은 트래픽 진입점이며 노드 매개변수, 인증서 도메인, DNS, 라우팅 규칙을 자동으로 수정하지는 않습니다.

1. 먼저 일반 HTTP 또는 SOCKS 진입점이 명시적 프록시 요청을 정상적으로 처리하는지 확인하세요.
2. v2rayN의 TUN 관련 설정에서 가상 네트워크 어댑터 모드를 활성화하고, 시스템 안내에 따라 네트워크 인터페이스 생성에 필요한 권한을 허용하세요.
3. 라우팅 규칙에서 로컬 네트워크, 루프백 주소, 필요한 로컬 서비스가 직접 연결로 유지되는지 확인하세요.
4. 터미널 요청을 다시 테스트하면서 로그의 인바운드 유형, 대상 주소, 아웃바운드 태그를 확인하세요.
5. 전체 네트워크가 끊기면 먼저 TUN을 끄고 시스템 기본 경로가 복구되는지 확인한 뒤 DNS와 가상 인터페이스 상태를 점검하세요.

TUN은 시스템 프록시를 읽지 않는 프로그램을 처리하는 데 적합하지만, 브라우저와 터미널의 동작이 다르다고 처음부터 켤 필요는 없습니다. 명시적 프록시 명령으로 로컬 포트 연결 여부, 프로토콜 접두사, 노드의 아웃바운드 수립 여부를 더 빠르게 확인할 수 있습니다. 이 기본 항목들이 정상이어야 TUN 문제 해결도 명확한 출발점을 갖습니다.

증상에 따라 라우팅, DNS, 구독 문제 확인

브라우저와 터미널이 모두 v2rayN을 거치는데도 결과가 다르면 도메인 조회와 라우팅 매칭을 계속 확인해야 합니다. 브라우저는 자체 캐시를 사용하고 터미널은 시스템 DNS를 호출할 수 있습니다. 두 환경에서 얻은 대상 주소가 다르면 서로 다른 geoip, 도메인 또는 사설 주소 규칙에 매칭될 수도 있습니다.

구독 링크는 노드 목록을 제공하므로 구독을 업데이트한 뒤에도 활성 서버를 선택해야 합니다. 노드 목록은 정상적으로 갱신되었지만 코어 로그에 설정을 시작할 수 없다고 표시된다면, 시스템 프록시가 켜져 있어도 브라우저 요청을 정상 작동하지 않는 로컬 진입점으로 보낼 뿐입니다. 먼저 시작 로그에 표시된 첫 번째 설정 오류를 해결하세요.

문제 해결 후 검증 및 복구

문제를 해결한 뒤 웹페이지 하나만으로 결과를 판단하지 마세요. 로컬 포트, 명시적 프록시, 일반 터미널 요청, 브라우저의 네 가지를 모두 확인하고 v2rayN을 종료한 후 시스템 프록시가 정상적으로 제거되는지도 확인하세요. 이렇게 해야 현재 창에서는 정상처럼 보이지만 시스템에 이전 포트가 남아 있는 상황을 피할 수 있습니다.

1. 수신 포트 재테스트

   Test-NetConnection 또는 이에 준하는 도구로 현재 포트에 연결할 수 있는지 확인하고, 테스트 포트가 매개변수 설정의 값과 완전히 일치하는지 대조하세요.

2. 명시적 요청 실행

   HTTP 또는 socks5h 진입점을 각각 사용해 curl --proxy를 한 번씩 실행하고, 로컬 진입점과 프록시 경로가 모두 요청을 처리할 수 있는지 확인하세요.

3. 일반 요청 실행

   명령에서 명시적 프록시 매개변수를 제거하고 현재 세션의 환경 변수를 통해 다시 요청하세요. 성공해야 터미널 프록시 설정이 실제로 적용되었다고 판단할 수 있습니다.

4. 분기 로그 확인

   같은 시간대의 액세스 로그를 확인해 대상 도메인이 예상한 규칙에 매칭되고 프록시 또는 직접 연결 아웃바운드로 전송되었는지 확인하세요.

5. 종료 후 복구 테스트

   v2rayN에서 먼저 시스템 프록시를 지운 다음 클라이언트를 종료하세요. 브라우저와 시스템 네트워크가 종료된 127.0.0.1 포트를 계속 가리키지 않는지 확인하세요.

전체 점검 순서는 한 문장으로 줄일 수 있습니다. 먼저 로컬 포트가 수신 중인지 확인하고, 명시적 프록시로 경로를 검증한 다음 터미널 환경 변수를 설정하고, 마지막으로 TUN, DNS, 복잡한 라우팅을 확인하세요. 브라우저가 프록시를 사용한다는 것은 브라우저가 하나의 진입점을 정상적으로 읽었다는 뜻일 뿐, 모든 프로세스가 제어되고 있다는 의미는 아닙니다.

자주 묻는 질문