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

1. 시스템 프록시, 앱 프록시, 라우팅 구분하기

v2rayN의 ‘시스템 프록시 자동 설정’은 운영체제에서 앱이 읽을 수 있는 프록시 설정을 변경하는 기능이며, 기기의 모든 네트워크 연결을 가로채는 기능은 아닙니다. 브라우저는 보통 이 설정을 읽지만, 명령줄 도구와 백그라운드 서비스, 별도 네트워크 모듈을 사용하는 일부 프로그램은 이를 무시할 수 있습니다. 따라서 ‘브라우저는 되는데 터미널은 안 되는’ 경우에는 먼저 앱별 연결 방식의 차이를 확인하세요. 곧바로 노드 문제로 단정할 필요는 없습니다.

이 연결 과정에서 시스템 프록시는 첫 단계에만 영향을 줍니다. Xray 또는 V2Ray 코어가 요청을 받은 다음 라우팅 규칙에 따라 직접 연결, 프록시 또는 차단을 선택합니다. 브라우저가 로컬 포트에 연결했더라도 직접 연결 규칙에 해당하는 사이트는 로컬 네트워크를 통해 접속합니다. 따라서 ‘외부 IP 주소가 바뀌지 않았다’는 사실만으로 시스템 프록시가 작동하지 않는다고 판단할 수는 없습니다.

TUN은 시스템 프록시와 다른 연결 경로입니다. 변수 수를 줄이기 위해 이 글에서는 TUN을 사용하지 않는 상황을 기준으로 점검합니다. 현재 네트워크가 TUN에 의존한다면 먼저 기존 설정을 기록하고, 연결이 끊겨도 되는 상황에서만 분리 테스트를 진행하세요. TUN, DNS, 라우팅을 한꺼번에 변경하면 어떤 설정이 영향을 주었는지 파악하기 어렵습니다.

2. 로컬 포트와 명시적 프록시 요청부터 확인하기

v2rayN에서 ‘설정’ → ‘매개변수 설정’을 열어 로컬 수신 관련 설정을 확인하고, 코어 시작 로그에서 수신 정보를 살펴보세요. 버전에 따라 옵션 그룹의 이름이 다를 수 있으니 실제 화면과 로그를 기준으로 확인해야 합니다. 아래 숫자는 점검용 예시이며 모든 버전의 기본값은 아닙니다. 포트가 SOCKS만 지원한다면 HTTP 프록시로 사용할 수 없습니다.

Windows PowerShell에서는 먼저 포트 수신 상태를 확인한 다음, 프록시를 명시한 요청을 실행하세요. 일부 PowerShell 환경에서는 curl이 다른 도구의 별칭일 수 있으므로 curl.exe를 사용하세요. macOS와 Linux에서는 아래 두 번째 명령의 curl.exe를 curl로 바꾸면 됩니다.

Get-NetTCPConnection -State Listen -LocalPort 10808

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

--noproxy ""는 이번 테스트에서 우회 목록을 비워 기존 NO_PROXY 설정의 영향을 막습니다. macOS와 Linux에서는 출력 폐기 경로를 /dev/null로 바꾸세요. 예시 도메인은 연결 확인용이므로, 실제로 문제가 발생한 사이트로도 다시 테스트해야 합니다. 한 사이트의 접속 성공이 모든 라우팅과 대상 포트의 정상 작동을 의미하지는 않습니다.

• 127.0.0.1:10808 연결이 거부되면 코어가 실행 중인지, 포트가 올바른지, 수신 주소가 맞는지 먼저 확인하세요.
• 200 Connection established가 표시되면 HTTP CONNECT 터널이 만들어진 것입니다. TLS 핸드셰이크와 최종 응답도 계속 확인해야 합니다.
• 대상 사이트에서 HTTP 200, 301 또는 403을 반환하면 애플리케이션 계층 응답을 받은 것입니다. 403은 대상 사이트가 접근을 거부한 것이며 로컬 프록시가 작동하지 않는다는 뜻은 아닙니다.
• 로컬 연결은 되지만 이후 요청이 시간 초과되면 코어 로그에서 아웃바운드, DNS, 대상 사이트 연결을 확인하세요. 브라우저 프록시 설정을 계속 바꾸지 마세요.

3. 브라우저가 프록시를 사용하지 않을 때 점검 순서

v2rayN을 실행한 상태로 사용 가능한 노드를 선택한 다음, 트레이 메뉴의 ‘시스템 프록시’ → ‘시스템 프록시 자동 설정’을 눌러 설정을 적용하세요. 이후 트레이 아이콘 상태만 보지 말고 운영체제에 실제로 저장된 값을 확인해야 합니다. 다른 프록시 프로그램이나 브라우저 확장 프로그램, 조직 정책이 설정을 다시 덮어쓸 수 있습니다.

1. 운영체제 설정 확인

   Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 ‘프록시 서버 사용’에 표시된 주소와 포트를 확인하세요. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 연결 → ‘세부사항’ → ‘프록시’를 확인합니다. Linux 데스크톱 환경은 설정 위치가 제각각입니다. GNOME을 사용한다면 ‘설정’ → ‘네트워크’ → ‘네트워크 프록시’를 확인하세요.

2. 브라우저 연결 방식 확인

   Chrome에서 ‘설정’ → ‘시스템’ → ‘컴퓨터의 프록시 설정 열기’를 선택하세요. Firefox에서는 ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’을 열어 ‘시스템 프록시 설정 사용’이 선택되어 있는지 확인합니다. ‘프록시 사용 안 함’이나 수동 설정을 선택하면 시스템 설정을 예상대로 따르지 않습니다.

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

   Chrome에서 ‘확장 프로그램’ → ‘확장 프로그램 관리’를 열고 프록시를 제어하는 확장 프로그램을 잠시 끈 뒤, 새 브라우저 프로필로 테스트하세요. 시크릿 창에서도 정책이나 허용된 확장 프로그램이 적용될 수 있으므로 완전한 격리 환경으로 볼 수는 없습니다.

4. 우회 규칙 확인

   시스템 프록시 예외 목록, 브라우저 수동 프록시의 ‘프록시를 사용하지 않는 주소’ 목록, 자동 설정 스크립트 사용 여부를 확인하세요. PAC는 대상에 따라 직접 연결을 지정할 수 있습니다. 규칙 내용을 확인하지 않은 상태에서 PAC 모드가 모든 사이트에 프록시를 적용한다고 가정하지 마세요.

5. 브라우저를 다시 시작하고 테스트

   브라우저 창을 모두 닫고 백그라운드 프로세스도 종료한 다음 다시 실행하세요. 명령줄 테스트와 동일한 전체 URL을 요청하면서 v2rayN 로그도 확인합니다. Chrome에서는 주소창에 chrome://policy를 입력해 조직에서 적용한 프록시 정책이 있는지 확인할 수 있습니다. 관리되는 기기라면 관리자에게 문의하세요.

브라우저 요청이 코어 로그에 전혀 나타나지 않으면 먼저 브라우저 연결 방식을 확인하세요. 다만 접속 로그가 활성화되어 있고 로그 수준도 적절한 경우에만 ‘기록이 없음’이 참고할 만한 정보가 됩니다. 로그에 대상 요청이 직접 연결로 표시된다면 문제는 시스템 프록시 스위치가 아니라 라우팅 선택에 있습니다. 요청이 프록시 아웃바운드에 들어간 뒤 실패한다면 노드 연결과 대상 사이트 상태를 확인하세요.

4. 터미널 환경 변수와 일회성 옵션을 각각 테스트하기

터미널 도구에는 시스템 프록시를 따르는 공통 규칙이 없습니다. 프록시 환경 변수를 지원하는 도구라면 현재 터미널 세션에서 변수를 설정할 수 있습니다. 명령줄 프록시 옵션을 지원하는 도구라면 한 번만 명시적으로 지정하는 편이 문제를 파악하기 쉽습니다. 변수는 이후에 시작되는 하위 프로세스에만 전달되며, 이미 실행 중인 편집기 터미널이나 백그라운드 작업에는 자동으로 적용되지 않습니다.

Windows PowerShell: 현재 세션에 변수 설정하기

$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"

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

Get-ChildItem Env: | Where-Object Name -Match 'proxy'

HTTPS_PROXY의 http://는 ‘터미널에서 로컬 프록시까지’ 사용하는 프로토콜을 뜻하며 대상 URL의 프로토콜을 가리키는 것이 아닙니다. HTTPS 사이트에 접속할 때 HTTP 프록시는 보통 CONNECT로 터널을 만듭니다. 따라서 대상이 HTTPS라는 이유만으로 변수 값을 https://127.0.0.1:10808로 바꾸면 안 됩니다. 로컬 수신 지점에서 TLS 프록시를 실제로 제공하는 경우에만 후자의 설정이 맞을 수 있습니다.

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'

curl --connect-timeout 5 --max-time 15 -v https://example.com/ -o /dev/null

env | grep -i proxy

대소문자를 구분하는 환경에서 curl은 HTTP 프록시에 소문자 http_proxy만 사용하도록 설계되어 있습니다. HTTPS 프록시 변수는 해당 대소문자 형식을 모두 지원합니다. 도구마다 규칙이 다를 수 있으므로 각 도구의 문서를 확인하세요. 같은 변수의 대소문자 표기가 모두 존재하고 값이 서로 다르면 변수를 더 추가하지 말고 먼저 충돌을 정리하세요.

• NO_PROXY 또는 no_proxy에 대상 도메인이 포함되면 프록시를 우회합니다. 일부 도구는 *를 모든 대상 우회로 처리합니다.
• 일부 도구에서는 ALL_PROXY를 대체 프록시로 사용할 수 있지만 지원 범위는 도구마다 다릅니다. 전용 변수나 명령줄 옵션이 이 값을 덮어쓸 수도 있습니다.
• 작동 여부를 확인한 SOCKS 연결 주소가 있다면 curl --proxy socks5h://127.0.0.1:10808 https://example.com/으로 한 번 테스트할 수 있습니다. socks5h는 프록시 쪽에서 대상 도메인을 조회하도록 합니다.
• WSL, 컨테이너, 원격 터미널에서 127.0.0.1은 각 환경 자체를 가리키며 v2rayN이 실행 중인 호스트를 가리키지 않을 수 있습니다. 연결을 쉽게 하려고 로컬 프록시를 LAN 전체에 공개하지 마세요.

명시적으로 --proxy를 지정하면 성공하지만 환경 변수를 설정한 뒤 실패한다면, 도구가 해당 변수를 지원하는지, 자체 프록시 설정이 있는지, 요청이 우회 목록에 해당하는지 확인하세요. Windows WinHTTP 설정과 데스크톱 시스템 프록시는 서로 다른 연결 설정입니다. 터미널 도구 하나를 고치려고 전역 WinHTTP 설정을 무작정 바꾸지 마세요.

5. 실제 오류 메시지로 문제 발생 지점 찾기

‘웹페이지가 열리지 않는다’는 설명보다 오류 메시지가 문제 위치를 파악하는 데 더 유용합니다. 아래는 흔히 볼 수 있는 출력 예이며 실제 문구는 curl 버전, 운영체제, 브라우저 언어에 따라 다를 수 있습니다. 로컬 연결, CONNECT, TLS, 대상 응답 중 어느 단계에서 오류가 발생했는지 기록한 뒤 해당 설정을 수정하세요.

브라우저는 정상인데 터미널에서 인증서 오류만 발생한다면 노드를 바로 바꾸지 마세요. 브라우저와 명령줄 프로그램은 서로 다른 인증서 신뢰 저장소를 사용할 수 있습니다. 반대로 터미널은 성공하고 브라우저에서 프록시 연결 오류가 발생한다면, 특정 프로토콜이 전반적으로 작동하지 않는다고 판단하기보다 두 환경이 사용하는 로컬 포트부터 비교하세요.

6. 설정 복구 및 최소한의 점검 기록 남기기

문제를 찾았다면 필요한 설정만 남기세요. 작업 흐름상 프록시 환경 변수가 필요하다면 사용하는 셸의 시작 파일에 추가하고 로컬 개발 서버에 영향을 주지 않는지 확인하세요. 임시 테스트가 끝난 뒤에는 아래 명령으로 이 글에서 설정한 변수를 해제할 수 있습니다. 테스트 전에 변수가 설정되어 있었다면 삭제하지 말고 원래 값으로 복구하세요.

현재 세션의 환경 변수 지우기

# Windows PowerShell
Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:NO_PROXY -ErrorAction SilentlyContinue

# macOS、Linux shell
unset http_proxy https_proxy no_proxy

이 명령으로는 도구별 설정, 대소문자 표기가 다른 변수, 셸 시작 파일, 이미 실행된 하위 프로세스 등 다른 위치에 저장된 설정은 지워지지 않습니다. 브라우저 테스트를 위해 잠시 꺼 둔 확장 프로그램은 하나씩 다시 활성화하고 확인하세요. 특정 설정을 복구한 뒤 문제가 재현된다면 설정을 덮어쓴 원인을 찾을 수 있습니다.

• 환경 기록: 운영체제, v2rayN 버전, 코어 종류, TUN 사용 여부, 로컬 연결의 프로토콜과 포트.
• 요청 통일: 같은 대상 URL을 사용해 명시적 프록시, 환경 변수, 브라우저 접속 결과를 각각 기록하세요.
• 아웃바운드 확인: 해당 시각의 라우팅 규칙 매칭과 오류 로그를 보관하고, 직접 연결과 프록시 중 실제 경로를 확인하세요.
• 정보 보호: 로그를 공유하기 전에 구독 주소, 토큰, 노드 인증 정보와 불필요한 내부 도메인을 삭제하세요.