v2rayN 시스템 프록시가 작동하지 않을 때: 브라우저 우회와 터미널 프록시 환경 변수 점검

1. 시스템 프록시는 연결 지점일 뿐, 모든 트래픽을 처리하지 않습니다

v2rayN에서 ‘시스템 프록시 설정’을 선택하면 운영체제에 프록시 설정을 기록합니다. 하지만 앱이 이를 사용하는지는 앱 자체의 설정에 달려 있습니다. 브라우저는 시스템 설정을 따를 수도 있고, 확장 프로그램·실행 옵션·기업 정책에 의해 설정이 바뀔 수도 있습니다. 명령줄 도구는 대개 별도의 프록시 옵션과 환경 변수를 사용합니다. 브라우저에서 사이트가 열린다고 해서 터미널도 프록시를 사용한다고 단정할 수는 없습니다.

두 단계의 선택을 구분해야 합니다. 먼저 앱이 로컬 프록시에 연결할지 결정하고, 그다음 코어가 해당 연결을 프록시 아웃바운드로 보낼지 직접 연결할지 결정합니다. 앱이 v2rayN에 연결되더라도 라우팅 규칙에 따라 직접 연결될 수 있습니다. VMess와 VLESS는 원격 연결에 사용하는 프로토콜 설정이며, 브라우저나 터미널이 시스템 프록시를 자동으로 사용하도록 해 주지는 않습니다.

• 앱이 프록시를 우회함: 앱이 로컬 리스너에 연결하지 않습니다. 시스템 설정, 확장 프로그램, 환경 변수, 우회 목록을 확인하세요.
• 라우팅에 따른 직접 연결: 로컬 프록시가 요청을 받았지만 규칙에 따라 직접 연결합니다. 현재 라우팅 모드와 규칙 순서를 확인하세요.
• 아웃바운드 연결 실패: 요청이 코어에 전달됐지만 원격 노드나 대상 서비스에 연결하지 못했습니다. 노드, DNS, 인증, 전송 설정을 점검하세요.

2. 프록시를 명시해 로컬 연결부터 확인하기

먼저 v2rayN에 표시된 현재 로컬 리스너 주소와 포트, 프로토콜을 확인하세요. ‘설정’ → ‘매개변수 설정’에서 로컬 리스너 관련 항목을 살펴보고, 실제로 실행 중인 코어 설정을 기준으로 판단합니다. 화면 구성에 따라 항목 위치는 다를 수 있습니다. 아래에서는 HTTP를 지원하는 로컬 주소 127.0.0.1:10808을 예시로 사용합니다. 모든 설치 환경의 기본값이라는 뜻은 아닙니다. 실제로 SOCKS 리스너만 있다면 해당 SOCKS 테스트 명령을 사용하세요.

Windows PowerShell에서는 curl.exe를 사용하세요. 이전 버전의 Windows PowerShell에서는 curl 별칭이 다른 명령으로 해석될 수 있습니다. macOS와 Linux에서는 curl을 사용하면 됩니다. 테스트 주소는 예시이므로 확인하려는 실제 HTTPS 사이트로 바꿔도 됩니다. 공용 인터넷 프록시 상태를 확인할 때 로컬 주소를 대상으로 삼지는 마세요.

# Windows PowerShell: HTTP 또는 혼합 리스너
curl.exe -v --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 15 https://example.com/ -o NUL

# macOS / Linux: HTTP 또는 혼합 리스너
curl -v --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 15 https://example.com/ -o /dev/null

# 해당 포트가 SOCKS5를 지원할 때만 사용; 대상 도메인은 프록시 측에서 조회
curl -v --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 https://example.com/ -o /dev/null

--noproxy ""는 이번 테스트에서 우회 목록을 비우는 옵션입니다. 상세 출력에서 먼저 127.0.0.1에 연결하는지 확인하세요. HTTP 프록시로 HTTPS 사이트에 접속하면 CONNECT 터널 협상도 표시됩니다. 대상 사이트의 HTTP 응답을 받았다면 적어도 서버 응답 단계까지 도달한 것입니다. 상태 코드가 200이 아니더라도 이를 곧바로 ‘시스템 프록시가 작동하지 않음’으로 분류할 수는 없습니다.

3. 브라우저가 프록시를 우회할 때: 설정 덮어쓰기 확인

점검하는 동안 같은 대상 주소와 같은 노드를 유지하세요. 노드, DNS, 라우팅을 한꺼번에 바꾸지 마세요. 웹페이지가 열리는지만으로 판단하면 정확하지 않습니다. 캐시된 페이지, 기존 연결, 사이트의 직접 접속 허용 여부가 실제 연결 경로를 가릴 수 있습니다. 요청 시점의 코어 연결 기록을 함께 확인해 트래픽이 로컬 프록시로 들어왔는지 살펴보세요. 액세스 로그가 꺼져 있다면 로그가 없다는 사실만으로 요청이 없었다고 단정할 수 없습니다.

1. 시스템 프록시 다시 설정

   v2rayN 트레이 메뉴의 ‘시스템 프록시’에서 먼저 ‘시스템 프록시 지우기’를 선택한 다음 ‘시스템 프록시 자동 설정’을 선택하세요. 현재 버전에서 메뉴가 기본 창 하단에 있다면 같은 이름의 항목을 사용하면 됩니다. 그런 다음 시스템에 저장된 주소와 포트를 확인하세요.

2. 프록시 확장 프로그램 일시 중지

   Chrome 또는 Edge에서 ‘확장 프로그램’ → ‘확장 프로그램 관리’를 열고 프록시를 변경할 수 있는 확장 프로그램을 잠시 사용 중지하세요. 일반 시크릿 창에서도 프록시 설정이 모두 분리되는 것은 아닙니다. 브라우저 프로세스를 전부 종료한 뒤 다시 실행해 테스트하는 편이 좋습니다.

3. 브라우저의 프록시 설정 출처 확인

   Chrome에서 ‘설정’ → ‘시스템’ → ‘컴퓨터의 프록시 설정 열기’를 선택하세요. Firefox에서는 ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’을 열고, ‘프록시 사용 안 함’이나 오래된 수동 프록시가 아니라 시스템 프록시를 사용하도록 설정되어 있는지 확인하세요.

4. 우회 목록 확인

   시스템 프록시 예외, 자동 구성 스크립트, 브라우저 규칙을 확인하세요. 목록에 대상 도메인, 지나치게 넓은 도메인 접미사 또는 와일드카드가 있다면 기존 값을 기록한 뒤 범위를 좁혀 보세요. 내부망과 루프백 주소는 흔히 제외되므로 테스트 대상으로만 사용해서는 안 됩니다.

5. 정책에 의한 설정 덮어쓰기 확인

   Chrome에서는 chrome://policy, Edge에서는 edge://policy를 열어 프록시 정책이 있는지 확인하세요. 관리 대상 기기의 강제 설정은 관리자에게 문의하세요. 정책으로 덮어쓴 시스템 설정을 반복해서 변경하지 마세요.

특정 브라우저에서만 문제가 발생한다면 실행 바로 가기에 프록시 관련 옵션이 있는지도 확인하세요. 브라우저의 보안 DNS 설정은 ‘프록시 사용’ 옵션이 아닙니다. 일부 DNS 조회 방식에 영향을 줄 뿐, HTTP 또는 SOCKS 연결 설정을 대신하지 않습니다. 먼저 프록시 설정 출처를 확인한 뒤 DNS 문제를 별도로 살펴보세요. 두 설정을 한꺼번에 바꾸지 않는 것이 좋습니다.

4. 운영체제별로 현재 시스템 프록시 확인하기

시스템 설정 화면과 명령 출력 결과를 함께 확인하세요. 아래 명령은 설정을 읽기 위한 것으로, 시스템 프록시를 변경하지 않습니다. 서버 주소와 포트, 사용 여부, 자동 구성 스크립트, 예외 목록이 v2rayN의 현재 연결 주소와 일치하는지 살펴보세요.

Windows: 현재 사용자 설정과 WinHTTP 설정은 별도로 확인

# PowerShell: 현재 사용자 프록시 설정 읽기
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
  Select-Object ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL

# 별도의 WinHTTP 프록시 설정 확인
netsh winhttp show proxy

ProxyEnable이 1이면 정적 프록시가 활성화된 것입니다. 실제 주소는 ProxyServer 값에서 확인해야 합니다. 자동 구성 스크립트는 별도의 설정 경로입니다. netsh winhttp show proxy 결과가 직접 연결이라고 해서 브라우저도 프록시를 사용하지 않는다는 뜻은 아닙니다. WinHTTP와 현재 사용자의 인터넷 설정은 서로 다른 설정이므로, 두 결과를 일치시키려고 설정을 무작정 가져오지 마세요.

macOS: 현재 적용 중인 프록시 설정 확인

scutil --proxy

HTTPEnable, HTTPSEnable과 서버 및 포트 항목을 확인하고, ProxyAutoConfigEnable과 예외 목록도 살펴보세요. Wi-Fi, 유선 네트워크 또는 다른 네트워크 서비스로 전환한 뒤에는 다시 확인해야 합니다. 이전 네트워크 서비스의 프록시 설정이 현재 연결에 적용된다는 보장은 없습니다.

Linux GNOME: 데스크톱 프록시 설정 확인

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy.http host
gsettings get org.gnome.system.proxy.http port
gsettings get org.gnome.system.proxy.https host
gsettings get org.gnome.system.proxy.https port
gsettings get org.gnome.system.proxy ignore-hosts

아래 명령은 해당 설정 구조를 사용하는 GNOME 세션에서만 쓸 수 있으며, 모든 Linux 환경에 적용되는 공통 인터페이스는 아닙니다. SSH 세션, 컨테이너, 백그라운드 서비스는 일반적으로 데스크톱 프록시를 자동으로 상속하지 않습니다. 데스크톱 설정이 올바르더라도 명령줄 프로그램의 환경 변수는 별도로 확인해야 합니다.

5. 터미널의 http_proxy와 https_proxy는 별도로 설정

터미널 창 자체가 프록시를 일괄 적용하는 것은 아닙니다. 실제로 설정을 읽는 것은 터미널에서 실행되는 프로그램입니다. curl, 패키지 관리자, 개발 도구마다 프록시 지원 방식이 다를 수 있습니다. 먼저 curl로 조건을 통제해 확인한 다음 각 도구의 프록시 옵션을 점검하세요. 특정 도구 하나가 성공했다고 해서 터미널 전체가 프록시를 사용한다고 볼 수는 없습니다.

macOS / Linux: 환경 변수 확인 및 임시 설정

# 대소문자 두 가지 변수와 우회 목록 확인
env | grep -iE '^(http_proxy|https_proxy|all_proxy|no_proxy)='

# 현재 셸과 이후에 실행되는 하위 프로세스에만 설정
export http_proxy=http://127.0.0.1:10808
export https_proxy=http://127.0.0.1:10808

# 이번 테스트에서 우회 목록을 비우고, 테스트가 끝나면 기존 설정 복원
curl -v --noproxy "" --connect-timeout 5 --max-time 15 https://example.com/ -o /dev/null

https_proxy에서 https는 대상 URL의 프로토콜을 뜻하며, 변수 값도 반드시 https://로 시작해야 한다는 의미는 아닙니다. 일반적인 로컬 HTTP 프록시는 http://127.0.0.1:10808을 사용해 CONNECT 방식으로 HTTPS 대상에 연결합니다. 프록시 자체가 TLS를 지원하는 경우에만 HTTPS 프록시 주소를 사용하세요.

• http_proxy: HTTP 대상에 프록시를 사용합니다. curl은 이 변수의 소문자 형식만 지원하므로 대문자 HTTP_PROXY만 설정해서는 안 됩니다.
• https_proxy: HTTPS 대상에 프록시를 사용합니다. 다른 프로그램은 대소문자를 다르게 처리할 수 있으니 해당 도구의 문서를 확인하세요.
• all_proxy: 일부 도구에서 사용하는 공통 대체 프록시입니다. SOCKS 주소를 지정할 수 있습니다. 프로토콜별 변수가 우선 적용되는 경우가 많으므로 서로 충돌하는 값을 함께 설정하지 마세요.
• no_proxy: 프록시를 우회할 대상 목록입니다. curl에서는 값이 *이면 모든 대상이 프록시를 우회합니다. ‘변수를 설정했는데도 직접 연결됨’ 문제에서 먼저 확인할 항목입니다.

Windows PowerShell: 현재 프로세스에 환경 변수 설정

# 현재 프로세스의 프록시 환경 변수 확인
Get-ChildItem Env: | Where-Object Name -Match '^(http_proxy|https_proxy|all_proxy|no_proxy)$'

# 현재 PowerShell과 이후에 시작되는 하위 프로세스에 설정
$env:http_proxy = 'http://127.0.0.1:10808'
$env:https_proxy = 'http://127.0.0.1:10808'

curl.exe -v --noproxy "" --connect-timeout 5 --max-time 15 https://example.com/ -o NUL

이 설정은 이미 실행 중인 프로그램을 변경하지 않으며, 새로 연 다른 터미널에도 자동으로 적용되지 않습니다. 장기간 사용하려면 사용자 환경 변수나 셸 설정 파일에 저장하는 방법을 검토하세요. setx로 저장한 값은 주로 이후에 시작되는 프로세스에서 사용되며 현재 PowerShell에는 바로 적용되지 않습니다. 검증이 끝나기 전에 잘못된 포트를 영구 저장하지 마세요.

6. 자주 발생하는 오류로 점검 단계 파악하기

아래는 curl에서 자주 볼 수 있는 오류 문구 예시입니다. 실제 주소와 출력은 운영체제 및 버전에 따라 다를 수 있습니다. 가장 먼저 실패한 단계부터 확인하세요. 로컬 포트에 연결되지 않는데 원격 프로토콜을 바꿔도 해결되지 않습니다. 대상 TLS 오류를 받았다면 문제를 더 이상 ‘시스템 프록시를 설정하지 않음’으로 볼 수도 없습니다.

인증서 검증 오류가 발생해도 검증 기능을 계속 꺼 둔 채 해결하려고 하지 마세요. 시스템 시간, 인증서 신뢰 체인, 네트워크의 HTTPS 검사 장비를 확인하세요. 프록시 터널은 열렸지만 TLS 연결이 실패한 상황은 ‘터미널이 프록시 변수를 전혀 읽지 않음’과 다른 단계의 문제입니다.

7. 비교 결과에 따라 다음 단계를 결정하고, TUN부터 켜지 마세요

TUN은 가상 네트워크 인터페이스를 통해 트래픽을 처리하므로 시스템 프록시를 따르지 않는 앱에 유용할 수 있습니다. 다만 권한, 라우팅, DNS 등 추가로 점검할 항목이 생깁니다. 시스템 프록시를 확인하는 데 TUN이 꼭 필요한 것은 아닙니다. 프록시를 명시한 요청부터 성공하지 않는 상태에서 TUN을 켜면 변수가 늘어날 수 있습니다. 먼저 로컬 연결과 원격 아웃바운드가 정상인지 확인하세요.