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

핵심 내용

시스템 프록시는 해당 설정을 읽는 앱에만 적용되며, 모든 트래픽이 v2rayN을 거치는 것은 아닙니다. 먼저 로컬 프록시 연결을 확인한 다음 브라우저의 시스템 설정, 확장 프로그램, PAC와 터미널의 환경 변수 및 도구 설정을 각각 점검합니다. 순서대로 테스트하면 로컬 리스너, 앱 연결, 라우팅 또는 노드의 외부 연결 중 어디에서 문제가 생겼는지 파악할 수 있어 처음부터 클라이언트를 재설치할 필요가 없습니다.

1. 시스템 프록시, 앱 프록시, 노드 연결 구분하기

v2rayN은 설정을 관리하고 프록시 코어를 실행하는 데스크톱 클라이언트입니다. 시스템 프록시 설정은 이를 따르는 앱에 요청을 전달할 로컬 주소와 포트를 알려줍니다. 앱이 이 설정을 읽지 않거나 자체 설정으로 덮어쓰면 요청이 대상에 직접 연결될 수 있습니다. 터미널의 curl, 패키지 관리자, 개발 도구도 브라우저에서 사용하는 시스템 프록시를 반드시 따르는 것은 아닙니다.

앱 프록시 설정 로컬 리스너 연결 라우팅 규칙 적용 노드 또는 직접 연결 대상 사이트 응답

문제를 확인할 때는 테스트 주소 하나와 연결된 노드 하나를 정해 두세요. 우선 TUN을 끄고 기존 시스템 프록시 모드와 라우팅 모드를 기록해 두면 두 연결 방식이 겹쳐 원인을 파악하기 어려워지는 일을 막을 수 있습니다. 네트워크 사용에 TUN이 꼭 필요한 환경이라면 그 조건을 먼저 기록하세요. 테스트 결과만으로 시스템 프록시가 정상이라고 판단해서는 안 됩니다.

로컬 연결: 앱이 127.0.0.1에서 실제로 대기 중인 프록시 포트에 연결할 수 있는지 확인합니다.
앱 연결: 브라우저와 터미널이 이전 포트나 직접 연결이 아닌 해당 프록시 연결을 실제로 사용하는지 확인합니다.
노드 연결: 요청이 코어에 들어온 뒤 규칙에 따라 예상한 노드를 사용해 대상에 연결하는지 확인합니다.

2. 명시적 프록시로 로컬 포트 확인하기

v2rayN에서 「설정」→「파라미터 설정」을 열어 로컬 리스너 포트를 확인하세요. 일부 버전에서는 「Core: 기본 설정」 페이지에 관련 항목이 표시됩니다. 항목 이름과 화면 배치는 버전에 따라 다를 수 있으므로 현재 화면과 시작 로그를 기준으로 확인하세요. 여기서는 10808이 HTTP를 지원하는 혼합 연결 포트라고 가정합니다. 별도의 HTTP 포트를 사용한다면 아래 예시의 포트를 모두 실제 포트로 바꾸세요.

10808

이 문서에서 사용하는 로컬 프록시 포트

10초

명령에서 지정한 연결 시간 제한

20초

명령에서 지정한 전체 시간 제한

Windows PowerShell에서는 curl.exe를 사용하세요. 일부 PowerShell 버전에서는 curl이 다른 명령으로 해석될 수 있습니다. 아래 명령으로 먼저 리스너를 확인한 다음 프록시를 직접 지정해 테스트합니다. 브라우저가 시스템 프록시를 읽는지와는 무관한 테스트입니다.

Get-NetTCPConnection -State Listen -LocalPort 10808
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com

macOS와 Linux에서는 아래 curl 명령으로 같은 방식의 명시적 프록시 테스트를 할 수 있습니다. 테스트 전에 현재 세션의 NO_PROXY와 no_proxy를 확인해 테스트 도메인이나 와일드카드 *가 포함되지 않았는지 살펴보세요. 포함되어 있으면 프록시를 우회할 수 있습니다.

curl --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com

판단 기준: 명시적 프록시 테스트가 실패하면 브라우저 설정은 나중에 확인하세요

먼저 리스너 포트나 코어의 외부 연결 문제를 해결하세요. 로그에 대상이 직접 연결 규칙에 일치한 것으로 표시된다면, 로컬 프록시를 직접 지정했다는 사실만으로 트래픽이 원격 노드를 거쳤다고 볼 수 없습니다. 라우팅 결과도 함께 확인해야 합니다.

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

아래 절차는 주로 Windows 데스크톱을 기준으로 합니다. macOS에서는 「시스템 설정」→「네트워크」→현재 네트워크 서비스→「세부사항」→「프록시」에서 시스템 프록시를 확인할 수 있습니다. Linux 데스크톱은 환경마다 설정 위치가 다르며, 터미널에는 보통 프록시 환경 변수가 자동으로 적용되지 않습니다.

시스템 프록시 설정

v2rayN 트레이 메뉴에서 「시스템 프록시」→「시스템 프록시 자동 설정」을 선택하세요. 「시스템 프록시 지우기」는 프록시를 활성화하는 기능이 아닙니다. 「시스템 프록시 변경 안 함」은 현재 시스템 값을 그대로 유지하므로, 그 값이 이번에 실행한 포트를 가리킨다고 보장할 수 없습니다.
시스템 주소 확인

Windows에서 「설정」→「네트워크 및 인터넷」→「프록시」로 이동해 수동 프록시 주소와 포트가 v2rayN의 현재 리스너 설정과 일치하는지 확인하세요. 「설정 스크립트 사용」 상태도 기록해 두세요. 남아 있는 PAC 설정과 수동 설정이 번갈아 영향을 주지 않도록 합니다.
프록시 확장 프로그램 끄기

프록시를 관리하는 브라우저 확장 프로그램을 잠시 끈 다음 브라우저를 완전히 종료하고 다시 실행하세요. Chrome과 Edge는 대체로 시스템 프록시를 사용하지만 확장 프로그램이나 시작 매개변수가 설정을 덮어쓸 수 있습니다. 관리 대상 기기라면 브라우저 정책도 확인하세요.
별도 설정 확인

Firefox에서는 「설정」→「일반」→「네트워크 설정」→「설정」에서 연결 방식을 확인할 수 있습니다. 시스템 프록시를 테스트하려면 「시스템 프록시 설정 사용」을 선택하세요. 수동 프록시를 선택했다면 주소, 포트, 예외 목록을 각각 확인해야 합니다.
PAC 규칙 다시 확인

평소 PAC를 사용한다면 스크립트를 다시 적용한 뒤 같은 주소를 테스트하세요. 스크립트 주소에 접속할 수 있는지, 응답 내용이 프록시 자동 설정 스크립트인지 확인하고 대상 도메인에 DIRECT가 반환되는지도 살펴보세요. 스크립트에 지정된 로컬 포트도 현재 연결 포트와 일치해야 합니다.

PAC는 앱이 연결을 프록시로 보낼지 결정하고, v2rayN 라우팅 규칙은 요청이 코어에 들어온 뒤 어떤 경로로 나갈지 결정합니다. 두 설정은 서로 다른 단계에서 작동합니다. 「PAC가 프록시를 선택했다」고 해서 「코어가 반드시 원격 노드를 선택한다」는 뜻은 아닙니다. 기존 설정을 기록한 다음 임시로 수동 프록시를 지정해 비교 테스트하고, 완료 후 평소 사용하는 PAC로 되돌리세요.

특정 브라우저 하나에서만 실패: 확장 프로그램, 별도 프록시 설정, 시작 매개변수, 브라우저 정책을 먼저 확인하세요.
모든 브라우저에서 실패하지만 curl 직접 지정 테스트는 성공: 시스템 프록시 주소와 포트, 우회 목록을 먼저 확인하세요.
특정 사이트에서만 실패: 해당 도메인의 PAC 반환값, 라우팅 규칙, 사이트 자체의 응답을 확인하세요.

4. 터미널에서 프록시가 작동하지 않을 때: 환경 변수와 도구 설정 구분하기

이름이 비슷한 환경 변수도 용도를 혼동해서는 안 됩니다. https_proxy는 HTTPS 대상 요청에 사용할 프록시를 뜻하며, 프록시 연결 자체가 HTTPS 프로토콜이어야 한다는 뜻은 아닙니다. 로컬 연결이 HTTP 프록시라면 값은 http://127.0.0.1:10808로 설정할 수 있습니다. 도구는 CONNECT를 사용해 HTTPS 터널을 만듭니다.

PowerShell에서 먼저 현재 변수를 확인한 뒤 현재 세션에 프록시를 설정하세요. 이 예시는 현재 터미널과 여기서 실행하는 하위 프로세스에만 적용되며, 기기 전체의 지속 설정은 바꾸지 않습니다. HTTP 대상 요청에서 curl은 보통 소문자 http_proxy를 읽으므로 대문자 HTTP_PROXY만 설정하지 마세요.

Get-ChildItem Env: | Where-Object Name -Match '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 --connect-timeout 10 --max-time 20 -I https://example.com

Bash나 Zsh 같은 셸에서는 아래처럼 현재 세션에 설정할 수 있습니다. 대문자로 된 우회 변수가 이미 있다면 도구마다 대소문자 변수를 선택하는 순서가 다를 수 있으니 먼저 내용을 확인하세요. 셸 설정 파일을 수정해도 이미 열려 있는 다른 터미널에는 변경 사항이 자동으로 적용되지 않습니다.

env | grep -i proxy
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 --connect-timeout 10 --max-time 20 -I https://example.com

설정 위치	확인할 내용	흔한 오해
명령줄 옵션	curl의 `--proxy`, `--noproxy`	직접 지정한 옵션이나 우회 조건이 환경 변수의 적용을 바꿉니다.
환경 변수	`http_proxy`、`https_proxy`、`ALL_PROXY`	변수 하나만 설정해도 모든 도구가 이를 사용한다고 생각합니다.
우회 목록	`no_proxy`、`NO_PROXY`	`*` 또는 대상 도메인이 요청을 프록시에서 제외합니다.
도구별 설정	예: `npm config get proxy` 및 `npm config get https-proxy`	도구에 이전 포트가 남아 있어 예상한 설정을 덮어씁니다.
독립 실행 환경	컨테이너, 원격 터미널, 하위 시스템의 네트워크와 환경 변수	그 환경 안의 `127.0.0.1`은 호스트의 프록시 연결 주소가 아닐 수 있습니다.

5. 실제 오류 메시지로 실패 단계 찾기

아래는 자주 보이는 원본 오류 메시지 일부입니다. 같은 오류가 여러 원인으로 발생할 수 있으므로 요청 시각과 v2rayN 로그를 함께 확인하세요. 로그를 공유하기 전에는 구독 주소, 노드 인증 정보, 개인 접속 기록을 삭제하고 필요한 오류 줄과 포트 정보만 남기세요.

오류: curl: (7) Failed to connect to 127.0.0.1 port 10808

원인 및 해결 방법: 로컬 연결이 이루어지지 않은 상태입니다. 코어가 실행되지 않았거나 포트를 잘못 입력했거나 연결 포트에 접근할 수 없는 경우가 흔합니다. 리스너 상태와 코어 시작 로그를 확인한 다음 실제 포트로 다시 시도하세요. 원격 DNS부터 바꾸지는 마세요.

오류: ERR_PROXY_CONNECTION_FAILED

원인 및 해결 방법: 브라우저가 설정된 프록시 연결에 정상적으로 접속하지 못했습니다. 시스템 주소, 확장 프로그램 설정, PAC가 반환하는 포트를 확인한 뒤 같은 주소를 지정해 curl 테스트를 실행하세요.

오류: curl: (5) Could not resolve proxy

원인 및 해결 방법: 프록시 주소를 확인할 수 없습니다. 포트, 프로토콜, 공백을 잘못된 위치에 입력했을 수 있습니다. 변수가 http://127.0.0.1:10808처럼 완전한 주소인지 확인한 뒤 도구별 설정도 점검하세요.

오류: curl: (6) Could not resolve host

원인 및 해결 방법: 대상 도메인을 확인할 수 없습니다. 요청이 직접 연결되었는지 또는 로컬에서 이름을 조회하는 SOCKS 모드를 사용하는지 먼저 확인하세요. 우회 목록과 실제 프록시 방식을 점검하고, 프록시 측에서 도메인을 조회해야 한다면 사용 가능한 SOCKS5 연결 포트와 socks5h를 조합해 비교 테스트하세요.

오류: curl: (28) Operation timed out

원인 및 해결 방법: 제한 시간 안에 요청이 완료되지 않았습니다. 시간 초과만으로는 문제가 발생한 위치를 알 수 없습니다. 코어가 요청을 받았는지, 어떤 출구 규칙이 적용됐는지 확인한 다음 노드 연결과 대상 사이트를 각각 점검하세요.

HTTP 프록시 테스트에서 200 Connection established가 표시되면 CONNECT 터널이 수락되었다는 뜻일 뿐입니다. 이후 대상의 TLS 핸드셰이크와 최종 HTTP 응답도 확인해야 합니다. 대상에서 403이나 405를 반환해도 프록시가 실패했다고 단정할 수 없습니다. 일부 사이트는 접속 위치나 HEAD 요청을 제한합니다. TLS 오류를 가리기 위해 인증서 검증을 끄지 마세요.

6. 비교 테스트를 마친 뒤 평소 설정으로 복구하기

캐시나 일시적인 네트워크 변화가 영향을 주지 않도록 같은 테스트 도메인을 사용하고 아래 순서대로 결과를 기록하세요. 한 번에 변수 하나만 바꾸고 성공 여부, 오류 내용, 로그에 표시된 실제 출구를 남기세요. 여기서 제시한 시간 제한은 테스트용 설정이며 노드 속도나 네트워크 품질을 측정한 결과가 아닙니다.

명시적 프록시 테스트: --proxy로 확인된 로컬 포트를 지정하고 우회 목록에서 대상이 제외되지 않았는지 확인합니다.
브라우저 테스트: 프록시 확장 프로그램을 끄고 시스템 프록시를 활성화한 뒤 같은 도메인에 접속해 코어 로그를 확인합니다.
터미널 변수 테스트: 명시적 프록시 옵션을 제거하고 현재 세션의 환경 변수만 남긴 다음 요청을 실행합니다.
직접 연결 비교: curl에서 --noproxy '*'를 사용하면 앱 수준 프록시를 우회할 수 있습니다. TUN이 계속 실행 중이라면 네트워크 계층까지 직접 연결된다는 뜻은 아닙니다.
설정 복구: 기존 PAC, 라우팅, TUN 상태를 복구하고 임시 변수를 제거한 뒤 자주 사용하는 앱을 확인합니다.

결론: 로컬 연결을 확인한 뒤 앱 연결 문제를 해결하세요

명시적 프록시 테스트는 성공하지만 브라우저가 실패한다면 시스템 설정, 확장 프로그램, PAC를 집중적으로 확인하세요. 브라우저는 되지만 터미널이 실패한다면 환경 변수, 우회 목록, 도구 설정을 확인하세요. 요청이 코어에 들어온 뒤에도 실패할 때 라우팅, DNS, 노드 연결을 점검하면 됩니다.

PowerShell 현재 세션의 임시 변수를 지우려면 Remove-Item Env:http_proxy, Env:https_proxy, Env:no_proxy -ErrorAction SilentlyContinue를 실행하세요. Bash나 Zsh에서는 unset http_proxy https_proxy no_proxy를 실행할 수 있습니다. 기존 값이 있었다면 바로 삭제하지 말고 기록해 둔 원래 값으로 복구하세요. 설정 개념을 더 알아보려면 이 사이트의 문제 해결 안내 또는 용어집을 참고하세요.