V2Ray 시스템 프록시가 작동하지 않을 때: 브라우저와 터미널별 점검 방법

1. 시스템 프록시, 로컬 수신 포트, 프록시 연결을 구분하기

v2rayN에 ‘시스템 프록시 자동 설정’이 표시된다고 해서 클라이언트가 시스템 프록시 설정을 기록하는 모드를 선택했다는 점만 확인할 수 있습니다. 모든 앱이 해당 설정을 사용한다거나 노드 연결이 성공했다는 뜻은 아닙니다. v2rayN은 설정을 관리하는 데스크톱 클라이언트이며, 실제 연결은 실행 중인 V2Ray 또는 Xray 등의 코어가 처리합니다. 앱 요청이 로컬 포트로 들어오는지와 코어가 외부로 연결되는지를 나눠 확인해야, 문제와 무관한 구독 갱신을 반복하지 않을 수 있습니다.

시스템 프록시는 컴퓨터 전체 트래픽을 가로채는 스위치가 아닙니다. 브라우저는 시스템 프록시를 사용할 수도 있고, 확장 프로그램이나 자체 설정의 영향을 받을 수도 있습니다. 명령줄 프로그램은 대개 자체 옵션과 환경 변수를 사용합니다. 요청이 코어에 도달했더라도 라우팅 규칙에 따라 직접 연결될 수 있으므로, ‘로컬 로그에 연결이 표시됨’과 ‘대상에 프록시를 통해 연결됨’은 서로 다른 상태입니다.

• 브라우저와 터미널 모두 실패: 먼저 수신 포트를 확인한 다음 같은 대상으로 노드와 외부 연결을 테스트하세요.
• 프록시를 명시한 요청은 성공하지만 브라우저는 실패: 시스템 설정, 확장 프로그램의 설정 덮어쓰기, 브라우저 정책을 먼저 확인하세요.
• 브라우저는 되지만 터미널은 실패: 프로그램 옵션, 프록시 변수, 우회 목록을 먼저 확인하세요.
• 클라이언트를 종료한 뒤 실패: 시스템 프록시가 더 이상 수신하지 않는 로컬 포트를 가리키는지 먼저 확인하세요.

2. 10808 수신 여부를 확인하고 프록시를 지정해 테스트하기

여기서는 로컬 혼합 수신 주소의 예로 127.0.0.1:10808을 사용합니다. 모든 설치 환경에서 이 값을 사용한다는 뜻은 아닙니다. v2rayN의 ‘설정’ → ‘매개변수 설정’에서 ‘로컬 혼합 수신 포트’를 확인하세요. 일부 버전에서는 ‘Core: 기본 설정’ 탭에 있습니다. 화면에 HTTP와 SOCKS 포트가 따로 표시된다면 아래 HTTP 테스트에는 실제 HTTP 포트를 입력해야 합니다. 혼합 포트 예시를 그대로 사용하지 마세요.

Windows PowerShell에서 다음 두 명령을 실행하세요. 첫 번째 명령은 수신 중인 프로세스를 확인하고, 두 번째 명령은 시스템 프록시 자동 검색을 건너뛰고 로컬 HTTP 프록시에 직접 연결합니다. 여기서는 curl.exe를 사용합니다. 구버전 Windows PowerShell에서 curl이 다른 명령의 별칭으로 해석되는 일을 방지하기 위해서입니다. -q는 첫 번째 인수 위치에 두어 curl의 기본 설정 파일을 건너뜁니다.

Get-NetTCPConnection -State Listen -LocalPort 10808 |
  Select-Object LocalAddress, LocalPort, OwningProcess

curl.exe -q --proxy http://127.0.0.1:10808 --noproxy "localhost,127.0.0.1" --connect-timeout 10 --max-time 30 --head https://example.com/

여기서 example.com은 일반적인 HTTPS 연결 테스트 대상일 뿐, 실제 서비스 사이트를 뜻하지 않습니다. 다시 테스트할 때는 문제가 발생하는 전체 URL로 바꾸고 같은 대상을 계속 사용하세요. 대상이 HEAD 요청을 지원하지 않으면 --head를 빼고, Windows에서는 응답 본문을 버리도록 --output NUL을 추가하세요. 현재 네트워크에서 특정 웹페이지에 직접 접속되는지만 보고 프록시가 정상이라고 판단하지 마세요.

3. 브라우저가 연결되지 않을 때: 확장 프로그램, 시스템 설정, PAC 순으로 확인하기

프록시를 지정한 테스트는 정상인데 브라우저에 ERR_PROXY_CONNECTION_FAILED가 표시된다면, 브라우저가 실제로 어떤 연결 지점을 사용하는지 먼저 확인하세요. 시크릿 창을 ‘확장 프로그램이 없는 환경’으로 간주하지 마세요. 일부 확장 프로그램은 시크릿 모드에서도 실행되도록 허용되며, 조직 정책이 프록시 설정을 제공할 수도 있습니다. 문제를 확인할 때는 프록시 확장 프로그램을 명시적으로 일시 중지한 뒤 브라우저를 완전히 종료하고 다시 여세요.

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

   Chrome에서는 ‘확장 프로그램’ → ‘확장 프로그램 관리’를, Edge에서는 ‘확장’ → ‘확장 관리’를 열고 프록시 설정을 변경하는 확장 프로그램을 일시 중지하세요. 확장 프로그램을 계속 사용해야 한다면 현재 모드와 포트를 기록한 뒤 나중에 별도로 다시 테스트하세요.

2. 시스템 프록시 다시 설정하기

   알림 영역의 v2rayN 아이콘을 마우스 오른쪽 버튼으로 클릭하고 ‘시스템 프록시’에서 ‘시스템 프록시 해제’를 선택한 다음 ‘시스템 프록시 자동 설정’을 선택하세요. 클라이언트를 실행한 상태에서 알림 메뉴의 선택 여부만 보지 말고 시스템에 실제로 기록된 값을 확인하세요.

3. 주소와 포트 확인하기

   Windows 11에서 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’를 열고 ‘수동 프록시 설정’의 ‘프록시 서버 사용’을 확인하세요. 시스템 프록시 자동 설정에 쓰이는 일반적인 로컬 연결 지점은 클라이언트의 실제 수신 주소 및 포트와 일치해야 합니다. 예를 들어 127.0.0.1과 10808이 이에 해당합니다.

4. PAC 충돌 확인하기

   같은 화면에서 ‘설정 스크립트 사용’을 확인하세요. 이전 PAC 주소가 있다면 먼저 출처를 기록합니다. 개인 기기이고 조직 정책으로 관리되지 않는 경우에는 스크립트를 잠시 끄고 프록시 선택 방식을 하나만 남겨 테스트하세요. 업무용 기기라면 조직 설정을 덮어쓰지 않도록 관리 정책부터 확인하세요.

5. 브라우저 자체 설정 확인하기

   Firefox에서 ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’을 열고 ‘시스템 프록시 설정 사용’을 선택한 뒤 다시 테스트하세요. 수동 설정을 선택했다면 HTTP 프록시와 포트, HTTPS 요청의 프록시 설정을 확인해야 합니다. 브라우저 설정이 시스템 설정을 자동으로 따라간다고 가정하지 마세요.

‘시스템 프록시 자동 설정’과 ‘설정 스크립트 사용’은 서로 다른 기능입니다. 전자는 일반적으로 클라이언트가 로컬 프록시 연결 정보를 입력합니다. 후자는 브라우저가 PAC 스크립트를 읽고 대상별로 프록시를 사용할지 직접 연결할지 결정합니다. PAC 규칙에서 도메인이 빠지면 해당 도메인만 실패할 수 있습니다. 이 경우 스크립트의 반환 결과와 캐시를 확인하고, 구독 주소와 로컬 포트를 동시에 바꾸지 마세요.

• 설정을 저장해도 바로 원래대로 돌아옴: 다른 프록시 도구, 시작 작업, 조직 정책이 설정을 계속 덮어쓰는지 확인하세요.
• 특정 브라우저에서만 문제 발생: 임시 브라우저 프로필을 만들어 비교하고, 해당 브라우저의 확장 프로그램과 독립 설정을 집중적으로 확인하세요.
• 특정 사이트에서만 문제 발생: 라우팅 규칙, 사이트 상태, 전체 도메인을 확인하세요. 다른 사이트가 열린다고 해서 모든 분기 경로가 정상인 것은 아닙니다.

4. 터미널이 연결되지 않을 때: 환경 변수와 프로그램 자체 옵션 확인하기

브라우저에서는 웹페이지가 열리지만 PowerShell이나 다른 터미널에서는 시간 초과가 발생할 수 있습니다. 터미널은 프로그램을 실행하는 셸일 뿐이며, 프로그램이 시스템 프록시를 읽는지는 구현에 따라 다릅니다. 환경 변수는 보통 프로세스가 시작될 때 상속됩니다. 한 터미널 창에서 변수를 설정해도 이미 열려 있는 다른 창에는 자동으로 적용되지 않으며, 시스템 브라우저 프록시 설정도 바뀌지 않습니다.

먼저 PowerShell에서 현재 프록시 변수를 확인한 다음 현재 세션에 HTTP 프록시를 설정하세요. 여기서 HTTPS_PROXY는 HTTPS 대상에 접속할 때 사용할 프록시를 지정합니다. 로컬 프록시 주소를 반드시 https://로 적어야 한다는 뜻은 아닙니다. 일반적인 로컬 HTTP CONNECT 연결에는 http://127.0.0.1:10808을 사용하세요.

Get-ChildItem Env: |
  Where-Object Name -Match '^(http_proxy|https_proxy|all_proxy|no_proxy)$'

$env:http_proxy = "http://127.0.0.1:10808"
$env:https_proxy = "http://127.0.0.1:10808"
$env:no_proxy = "localhost,127.0.0.1,::1"

curl.exe -q --connect-timeout 10 --max-time 30 --head https://example.com/

Windows에서는 환경 변수 이름의 대소문자를 구분하지 않지만, macOS와 Linux에서는 대소문자 차이에 주의해야 합니다. curl은 보안상의 이유로 대문자 HTTP_PROXY를 HTTP 프록시 변수로 사용하지 않습니다. 따라서 여러 플랫폼에서 쓰는 예제에는 소문자 이름을 사용합니다. 다른 명령줄 도구는 지원 방식이 다를 수 있으므로 curl의 동작이 모든 프로그램에 적용된다고 가정하지 마세요.

# macOS / Linux: 현재 셸과 이후에 시작되는 하위 프로세스에만 적용
export http_proxy='http://127.0.0.1:10808'
export https_proxy='http://127.0.0.1:10808'
export no_proxy='localhost,127.0.0.1,::1'

curl -q --connect-timeout 10 --max-time 30 --head https://example.com/

컨테이너, 가상 머신, WSL의 서로 다른 네트워크 모드에서 명령을 실행하면 127.0.0.1은 데스크톱 호스트가 아니라 해당 환경 자체를 가리킬 수 있습니다. 먼저 호스트의 연결 지점에 접근할 수 있는지 확인한 다음 수신 주소를 변경할 필요가 있는지 판단하세요. 편의를 위해 프록시를 모든 네트워크 어댑터에 무작정 공개하지 마세요. 환경 간 접근이 꼭 필요하다면 허용할 출발지 주소를 제한하고 방화벽 규칙을 확인하세요.

5. HTTP, SOCKS, DNS 오류 구분하기

로컬 혼합 연결 지점은 보통 HTTP와 SOCKS 요청을 모두 받을 수 있지만, 예전 설정에서는 포트 두 개를 따로 사용하기도 합니다. SOCKS 전용 포트에 HTTP CONNECT를 보내면 핸드셰이크 실패나 빈 응답이 발생할 수 있습니다. 이는 VMess, VLESS 노드 프로토콜과는 별개의 문제입니다. 먼저 로컬 인바운드 프로토콜을 확인한 뒤 원격 노드 설정을 점검하세요.

# SOCKS를 지원하는 실제 포트에서 테스트하고, 대상 도메인은 프록시 측에서 확인
curl -q --proxy socks5h://127.0.0.1:10808 --noproxy "localhost,127.0.0.1" --connect-timeout 10 --max-time 30 --head https://example.com/

Windows에서 위 명령을 실행할 때는 curl을 curl.exe로 바꾸세요. curl에서 socks5://는 일반적으로 로컬에서 대상 도메인을 확인하고, socks5h://는 SOCKS 프록시에서 대상 도메인을 확인합니다. 두 결과가 다르면 이름 확인 위치에 차이가 있음을 알 수 있지만, 어떤 DNS 서버를 바꿔야 하는지까지 바로 판단할 수는 없습니다.

• HTTP 프록시로 HTTPS 사이트에 접속: curl은 보통 대상 호스트 이름을 프록시에 전달해 CONNECT 터널을 만듭니다. 따라서 로컬 DNS 캐시가 문제의 원인이라고 단정할 수 없습니다.
• 코어 로그에 노드 도메인 이름 확인 실패가 표시됨: 노드 주소와 코어가 사용하는 DNS 경로를 확인하세요. 브라우저 캐시를 지워도 노드 주소 확인 문제는 해결되지 않습니다.
• 같은 대상이 직접 연결로 라우팅됨: 현재 라우팅 모드와 규칙 순서를 확인하세요. 연결이 프록시 포트에 들어갔다고 해서 최종적으로 프록시 아웃바운드가 선택되는 것은 아닙니다.

6. 설정을 복원하고 재현 가능한 점검 결과 남기기

문제 위치를 확인한 뒤에는 임시 변경 사항을 원래대로 되돌리세요. 테스트 설정이 다음 문제의 원인이 되지 않도록 해야 합니다. PowerShell에서 변수를 임시로 설정했다면 현재 창에서 제거할 수 있습니다. 시스템 설정으로 변수를 영구 저장했다면 해당 설정 화면에서도 지우고 영향을 받은 앱을 다시 시작해야 합니다. 아래 명령은 현재 PowerShell 세션의 프록시 변수 네 개만 제거하며, 사용자 또는 시스템 수준의 영구 설정은 변경하지 않습니다.

Remove-Item Env:http_proxy, Env:https_proxy, Env:all_proxy, Env:no_proxy -ErrorAction SilentlyContinue

macOS 또는 Linux의 현재 셸에서는 unset http_proxy https_proxy all_proxy no_proxy를 실행할 수 있습니다. 대문자 변수도 설정했다면 해당 대문자 항목도 확인해 제거하세요. 변수가 셸 시작 파일에서 설정된다면 현재 창에서 unset을 실행하는 것만으로는 다음 실행 때 다시 불러오는 것을 막을 수 없습니다.

1. v2rayN을 종료하기 전에 필요에 따라 ‘시스템 프록시’에서 ‘시스템 프록시 해제’를 선택한 뒤, 브라우저가 원하는 직접 연결 상태로 돌아오는지 확인하세요.
2. 필요한 확장 프로그램이나 TUN을 다시 활성화하되 한 번에 하나씩 복원하세요. 각 항목을 복원할 때마다 같은 대상으로 다시 테스트하세요.
3. 테스트 시간, 실제 수신 포트, 전체 오류 코드, 브라우저 결과, 프록시를 지정한 curl 테스트 결과를 기록하세요. 모든 증상을 ‘인터넷이 전혀 안 됨’으로 뭉뚱그리지 마세요.
4. 문제 해결 지원을 요청할 때는 관련 로그 부분만 공유하세요. 구독 주소, 노드 인증 정보, 토큰이 포함된 요청 링크는 가려야 합니다.