시스템 프록시를 켰는데도 작동하지 않을 때: 브라우저와 터미널을 나누어 점검

“프록시를 켰다”는 말부터 나누어 보기

“시스템 프록시가 켜져 있다”는 말은 운영체제에 프록시 주소가 설정되어 있다는 뜻일 뿐입니다. 프록시 코어가 실행 중이라는 의미도 아니고 모든 앱이 이 설정을 읽는다는 보장도 없습니다. 점검하기 전에 연결 경로를 앱의 요청 발생, 시스템 프록시 사용 여부 판단, 로컬 프록시 포트의 연결 수신, V2Ray 또는 Xray 코어의 라우팅 처리라는 네 단계로 나누어 보세요.

어느 한 단계라도 끊기면 겉으로는 “웹페이지가 열리지 않음” 또는 “터미널이 계속 직접 연결됨”으로 보일 수 있습니다. 예를 들어 v2rayN에서 시스템 프록시를 설정했지만 코어가 실행되지 않으면 브라우저는 아무도 수신하지 않는 로컬 포트로 요청을 보냅니다. 반대로 브라우저는 정상인데 명령줄 프로그램이 시스템 프록시를 읽지 않으면 터미널은 계속 대상 사이트에 직접 연결합니다.

브라우저 연결 경로

대부분의 데스크톱 브라우저는 운영체제의 프록시를 따르지만 자체 프록시 옵션, 확장 프로그램 설정, 보안 DNS 설정을 사용할 수도 있습니다. 먼저 브라우저가 실제로 어느 설정을 적용하는지 확인하세요.

터미널 연결 경로

curl, 패키지 관리자와 개발 도구는 환경 변수나 각자의 설정 파일을 읽는 경우가 많습니다. 시스템 프록시 스위치를 켜도 이런 프로그램에 자동으로 적용되지는 않습니다.

v2rayN과 로컬 수신 포트 정상 여부 확인

브라우저나 터미널 설정을 바꾸기 전에 로컬 프록시 자체가 요청을 받을 수 있는지부터 확인하세요. 데스크톱 v2rayN을 예로 들면 사용 가능한 서버를 선택하고, 코어가 실행 중이며, 로컬 HTTP 또는 SOCKS 포트가 수신 중이어야 합니다. 구독을 가져오는 것만으로는 이 세 단계가 자동으로 완료되지 않습니다.

서버 및 코어 상태 확인

구독을 업데이트한 뒤 서버 목록에서 구성을 하나 선택하고 현재 활성 서버로 지정되었는지 확인하세요.
코어를 시작한 다음 메인 창의 상태 표시줄과 로그 영역을 확인하세요. 시작 직후 종료된다면 포트 충돌, 설정 필드 또는 프로토콜 매개변수 오류부터 처리해야 합니다.
로컬 프록시 설정을 열어 HTTP, SOCKS 또는 혼합 수신 포트를 기록하세요. 버전과 설정 마이그레이션 결과에 따라 값이 다를 수 있으므로 오래된 튜토리얼만 보고 포트를 추측하지 마세요.
수신 주소가 로컬 루프백 주소인지 확인하세요. 현재 컴퓨터에서만 사용할 때 흔히 쓰는 주소는 127.0.0.1입니다.

아래 명령은 v2rayN의 로컬 HTTP 프록시 포트가 10809라고 가정합니다. 화면에 다른 포트가 표시되면 명령의 숫자를 실제 값으로 바꾸세요. 이 테스트는 브라우저 설정을 거치지 않고 curl이 HTTPS 요청을 로컬 HTTP 프록시에 직접 전달하게 합니다:

curl -I --proxy http://127.0.0.1:10809 https://example.com

HTTP 응답 헤더가 반환되면 curl이 로컬 포트에 연결되어 프록시 경로가 최소 한 번 요청을 처리한 것입니다. 127.0.0.1 연결 실패가 표시되면 코어 실행 여부, 포트 오입력, 다른 프로세스의 포트 점유 여부를 우선 확인하세요. 로컬 포트 연결은 성공했지만 이후 핸드셰이크, 시간 초과 또는 서버 거부가 발생한다면 브라우저 스위치를 반복해서 바꾸지 말고 v2rayN 로그와 서버 설정을 확인하세요.

HTTP 포트와 SOCKS 포트 구분하기

HTTP 프록시와 SOCKS 프록시는 서로 다른 진입점입니다. SOCKS 포트를 시스템의 HTTP 프록시 입력란에 넣으면 앱이 TCP 연결은 만들더라도 올바른 프록시 협상을 완료하지 못할 수 있습니다. v2rayN 화면에 두 포트가 따로 표시된다면 유형에 맞게 사용하세요. SOCKS 프록시를 테스트할 때는 curl에 socks5h를 사용할 수 있습니다:

curl -I --proxy socks5h://127.0.0.1:10808 https://example.com

socks5h의 h는 프록시가 대상 도메인을 해석한다는 뜻입니다. 로컬 DNS와 프록시 출구의 해석 결과가 달라 생기는 혼선을 줄이는 데 도움이 됩니다. 여기의 10808도 예시일 뿐이며 실제 값은 클라이언트의 현재 설정을 따르세요.

브라우저가 작동하지 않을 때: 설정 출처를 단계별로 확인하기

대부분의 데스크톱 브라우저는 기본적으로 운영체제 프록시를 따르지만 브라우저 자체 설정, 확장 프로그램 규칙, 기업 정책 또는 완전히 종료되지 않은 이전 프로세스가 이를 바꿀 수 있습니다. 점검을 시작하자마자 모든 설정을 초기화하지 마세요. 먼저 브라우저가 프록시 정보를 어디서 가져오는지 확인하세요.

1단계: 시스템 프록시 주소 확인

운영체제의 프록시 설정을 열고 주소와 포트가 현재 v2rayN에 표시된 값과 같은지 확인하세요. 주소는 보통 구독 서버가 아니라 로컬 컴퓨터를 가리켜야 합니다. 시스템 프록시는 로컬 진입점을 지정하며 원격 서버 정보는 클라이언트 설정과 코어가 처리합니다.

v2rayN의 시스템 프록시 동작에는 보통 설정, 해제 또는 변경하지 않음과 같은 상태가 있습니다. “변경하지 않음”을 선택해도 운영체제의 기존 값을 수정하지 않을 뿐, 그 값이 올바르다는 뜻은 아닙니다. 포트를 바꾸거나 설정 폴더를 전환했거나 다른 프록시 도구를 함께 사용했다면 시스템에 이전 포트가 남아 있을 수 있습니다.

2단계: 브라우저 프로세스 완전히 재시작

보이는 창을 닫아도 브라우저 백그라운드 프로세스가 남아 있을 수 있습니다. 프록시 설정을 바꾼 뒤에는 작업 관리자에서 브라우저를 종료하고 다시 실행하세요. 브라우저에 “시스템 프록시 설정 사용” 옵션이 있다면 수동 프록시나 직접 연결 모드로 바뀌지 않았는지 확인하세요.

캐시와 일부 확장 프로그램의 영향을 배제할 때는 시크릿 창이 유용하지만 프로세스 재시작을 대신할 수는 없습니다. 브라우저 프록시 확장 프로그램이 특정 도메인을 직접 연결로 지정하거나 다른 포트를 사용할 수도 있습니다. 테스트할 때는 프록시 규칙을 바꾸는 확장 프로그램을 잠시 비활성화해 시스템 프록시 경로를 하나로 유지하세요.

3단계: HTTP와 HTTPS를 따로 테스트

일부 시스템 설정에서는 HTTP와 HTTPS 프록시를 각각 입력할 수 있습니다. 한쪽만 입력하면 다른 유형의 주소에 접속할 때 직접 연결되거나 바로 실패할 수 있습니다. 요즘 웹페이지는 HTTPS로 이동하는 경우가 많으므로 “홈페이지는 열리는데 로그인 페이지는 열리지 않음”도 두 프로토콜 입력란의 불일치 때문일 수 있습니다.

로컬 HTTP 프록시에서는 HTTPS 사이트가 보통 HTTP CONNECT 터널을 통해 전달됩니다. 로컬 프록시 주소를 원격 웹사이트의 HTTPS 주소로 적을 필요는 없습니다. 중요한 것은 브라우저가 올바른 프록시 유형을 사용하고 수신 중인 포트에 연결하는지입니다.

4단계: 우회 목록 확인

시스템 프록시에는 보통 “프록시를 사용하지 않을 주소”를 설정할 수 있습니다. 로컬 주소, LAN 도메인과 사내 도메인이 우회 목록에 자주 포함됩니다. 대상 도메인이 직접 추가되었거나 너무 넓은 와일드카드 규칙에 걸리면 브라우저는 직접 연결합니다. 테스트할 때는 목록 전체를 확인하고 첫 줄만 보지 마세요.

로컬 사이트에서 localhost 또는 127.0.0.1로 직접 연결하는 것은 대체로 정상입니다. 로컬 개발 서비스를 디버깅 중이라면 “로컬 주소가 프록시를 거치지 않음”을 장애로 보면 안 됩니다. 실제로 확인할 것은 외부 대상이 우회 규칙에 잘못 추가되었는지 여부입니다.

터미널이 작동하지 않을 때: 프록시 환경 변수를 명시적으로 설정하기

터미널은 명령 해석 환경일 뿐이며 실제로 프록시를 사용할지는 각 프로그램이 결정합니다. curl, 언어 패키지 관리자, 빌드 도구와 다운로드 프로그램은 서로 다른 변수를 읽거나 독립적인 설정을 사용할 수 있습니다. 가장 흔한 공통 진입점은 HTTP_PROXY, HTTPS_PROXY와 ALL_PROXY입니다.

PowerShell 현재 세션

아래 설정은 현재 PowerShell 세션과 여기서 실행되는 하위 프로세스에만 적용됩니다. 창을 닫으면 보통 사라지므로 문제 해결이나 임시 다운로드에 적합합니다:

$env:HTTP_PROXY = "http://127.0.0.1:10809"
$env:HTTPS_PROXY = "http://127.0.0.1:10809"
curl.exe -I https://example.com

대상 주소가 HTTPS여도 HTTPS_PROXY 값은 http://127.0.0.1:10809일 수 있습니다. 이는 앱이 로컬 프록시에 연결할 때 사용하는 프로토콜을 나타내며 대상 웹페이지의 프로토콜을 뜻하지 않습니다. 현재 세션의 변수를 제거하려면 다음을 실행하세요:

Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXY
Remove-Item Env:ALL_PROXY -ErrorAction SilentlyContinue

Windows 명령 프롬프트 현재 세션

set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809
curl -I https://example.com

변수를 지울 때는 등호 뒤를 비워 두세요:

set HTTP_PROXY=
set HTTPS_PROXY=
set ALL_PROXY=

macOS 및 Linux 현재 Shell

export HTTP_PROXY="http://127.0.0.1:10809"
export HTTPS_PROXY="http://127.0.0.1:10809"
curl -I https://example.com

많은 명령줄 도구는 소문자 변수명을 사용합니다. 프로그램별 호환성을 높이려면 현재 세션에서 소문자 형식도 함께 설정하세요:

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

테스트가 끝나면 변수를 제거하세요:

unset HTTP_PROXY HTTPS_PROXY ALL_PROXY
unset http_proxy https_proxy all_proxy

SOCKS 진입점 사용

도구가 SOCKS를 지원한다면 ALL_PROXY로 진입점을 지정할 수 있습니다. 예시는 SOCKS 포트가 10808이라고 가정합니다:

export ALL_PROXY="socks5h://127.0.0.1:10808"
curl -I https://example.com

모든 프로그램이 socks5h를 지원하는 것은 아니며 ALL_PROXY를 읽는 것도 아닙니다. 특정 도구가 환경 변수를 무시한다면 자체 프록시 설정 항목을 확인하세요. curl이 성공했다고 해서 모든 패키지 관리자가 같은 설정을 자동으로 사용한다고 판단하지 마세요.

NO_PROXY로 로컬 주소 우회 설정

개발 환경에서는 로컬 서비스, 컨테이너 진입점과 LAN 인터페이스를 직접 연결해야 하는 경우가 많습니다. NO_PROXY로 우회 범위를 지정할 수 있습니다:

export NO_PROXY="localhost,127.0.0.1,::1"
export no_proxy="$NO_PROXY"

도구마다 도메인 접미사, 와일드카드와 네트워크 대역 표기를 지원하는 방식이 완전히 같지는 않습니다. 먼저 명확한 호스트명과 루프백 주소부터 지정하고 지나치게 넓은 접미사는 바로 사용하지 마세요. 외부 도메인이 계속 직접 연결된다면 NO_PROXY에 잘못 들어갔는지도 확인하세요.

프록시가 요청을 받았다면 라우팅과 DNS도 확인하기

브라우저나 curl이 이미 로컬 포트에 연결되었다면 문제는 “앱이 프록시를 사용하는가”에서 “코어가 요청을 어떻게 처리하는가”로 넘어갑니다. V2Ray과 Xray는 도메인, IP, 포트, 프로토콜 등의 조건에 따라 라우팅을 분기할 수 있습니다. 요청이 코어에 들어간 뒤에도 직접 연결, 프록시 또는 차단 출구로 보내질 수 있습니다.

로그에서 인바운드와 아웃바운드 확인

v2rayN 로그를 열고 대상이 명확한 요청을 한 번 더 보내세요. 로그에 새 연결이 전혀 나타나지 않으면 앱이 트래픽을 로컬 프록시에 넘기지 않았을 가능성이 큽니다. 브라우저 설정이나 환경 변수로 돌아가 계속 확인하세요. 로그에 대상 도메인과 연결 기록이 나타나면 인바운드는 정상이며 일치한 아웃바운드와 오류 정보를 이어서 확인해야 합니다.

구독은 서버 설정 모음만 제공하고, 어떤 요청이 현재 서버를 사용할지는 클라이언트의 라우팅 규칙이 결정합니다. 둘은 서로 다른 계층입니다. 서버를 바꿔도 대상 도메인을 직접 연결로 명시한 로컬 규칙은 고칠 수 없습니다.

라우팅 규칙을 임시로 단순화하기

사용자 지정 규칙이 많다면 먼저 현재 설정을 저장한 뒤 이해하기 쉬운 테스트 규칙으로 검증하세요. 노드, DNS, 시스템 프록시와 라우팅을 동시에 바꾸지 마세요. 성공해도 어느 단계가 원인이었는지 알기 어렵습니다. 기본 프록시 경로를 확인한 다음 도메인 그룹, IP 규칙과 앱별 분기를 하나씩 복원하세요.

VMess와 VLESS는 클라이언트가 서버에 연결할 때 사용하는 프로토콜 설정입니다. 시스템 프록시와 환경 변수는 앱이 로컬 인바운드에 연결하는 방식일 뿐입니다. 브라우저는 VMess나 VLESS를 이해할 필요 없이 HTTP 또는 SOCKS 요청을 로컬 수신 포트에 넘기면 됩니다. 이 두 계층을 분리하면 프로토콜 필드에서 브라우저 프록시 스위치를 찾는 실수를 줄일 수 있습니다.

DNS 경로 차이 파악

브라우저는 자체 보안 DNS를 사용할 수 있고 운영체제에는 로컬 해석 캐시가 있습니다. SOCKS를 사용할 때는 도메인을 로컬에서 해석할 수도, 프록시에서 해석할 수도 있습니다. 경로가 다르면 같은 도메인도 브라우저와 터미널에서 서로 다른 결과가 나올 수 있습니다.

IP로 직접 접속했을 때 응답이 있지만 도메인 사용 시 실패한다면 DNS를 우선 확인하세요. curl로 SOCKS를 테스트할 때 socks5h를 선택하면 프록시가 도메인 해석을 담당하게 할 수 있습니다. 브라우저에서는 자체 DNS 설정이 시스템 동작을 덮어쓰는지도 확인하세요. 변경 후 브라우저를 다시 시작하고 새 요청을 보내 로그를 확인하세요. 이미 캐시된 페이지를 새로 고치는 것만으로 판단하지 마세요.

정해진 순서로 문제 좁히기

프록시 장애에서는 여러 옵션을 동시에 바꾸는 것이 가장 위험합니다. 아래 순서는 로컬 포트부터 시작해 각 단계에서 하나의 사실만 확인합니다. 어느 단계에서 실패하든 그 계층에서 처리하세요.

코어 실행 여부를 확인하세요.서버를 선택하고 v2rayN을 시작한 뒤 프로세스가 즉시 종료되지 않는지 확인합니다.
실제 포트를 기록하세요.클라이언트 화면에서 HTTP 및 SOCKS 수신 포트를 확인하고 오래된 스크린샷의 숫자를 재사용하지 마세요.
로컬 프록시를 명시적으로 테스트하세요.curl의 --proxy 매개변수로 로컬 포트에 연결해 시스템 프록시와 환경 변수의 영향을 배제합니다.
브라우저의 설정 출처를 확인하세요.브라우저가 시스템 설정을 따르는지 확인하고 프록시를 변경하는 확장 프로그램을 끈 뒤 프로세스를 완전히 다시 시작합니다.
터미널 변수를 확인하세요.HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY를 읽고 설정하는 동시에 NO_PROXY도 확인합니다.
코어 로그를 확인하세요.요청이 로컬 인바운드로 들어갔는지와 최종적으로 어떤 라우팅 출구가 선택되었는지 확인합니다.
마지막으로 DNS를 처리하세요.도메인 해석이 비정상일 때만 로컬 해석과 프록시 측 해석을 비교합니다.

자주 나타나는 세 가지 현상 빠르게 판단하기

브라우저는 성공하지만 curl은 실패: 브라우저는 시스템 프록시를 읽지만 curl은 환경 변수를 읽지 않거나 설정하지 않았을 가능성이 큽니다. 먼저 --proxy로 명시적인 테스트를 진행하세요.
curl의 명시적 프록시는 성공하지만 브라우저는 실패: 로컬 포트와 코어는 대체로 정상입니다. 시스템 프록시 포트, 브라우저 자체 설정, 확장 프로그램 규칙과 백그라운드 프로세스를 중점적으로 확인하세요.
로컬 포트에 연결되지만 요청은 시간 초과: 앱이 프록시 진입점을 찾은 상태입니다. 서버 설정, 라우팅 분기, DNS와 로그에 기록된 원격 연결 오류를 계속 확인하세요.

점검을 마친 뒤에는 임시 환경 변수를 삭제하거나 일상적인 개발을 위해 명확한 활성화 및 비활성화 명령을 남겨 두세요. 설정 변경에 따라 프록시 포트가 바뀔 수 있으므로 이전 포트를 영구 저장하면 다음 장애가 Shell 시작 파일 안에 숨어 버립니다. 포트, 프록시 유형과 변경 위치를 한곳에 기록하는 편이 특정 숫자 하나를 기억하는 것보다 안전합니다.