시스템 프록시를 켰는데도 웹페이지가 열리지 않을 때: 브라우저·터미널별 점검

핵심 내용

시스템 프록시를 켰다는 것은 운영체제에 프록시 설정을 저장했다는 뜻이지, 모든 앱이 이를 사용한다는 뜻은 아닙니다. 이 글에서는 데스크톱용 v2rayN을 기준으로 로컬 리스닝과 프록시를 명시한 요청부터 확인한 뒤, 브라우저 설정과 터미널 환경 변수를 각각 점검합니다. 마지막으로 연결·이름 확인·인증서 오류를 바탕으로 문제를 좁혀 갑니다. ‘웹페이지가 열리지 않음’, ‘브라우저는 되지만 명령줄 요청은 시간 초과’, ‘클라이언트를 종료한 뒤에도 인터넷에 연결되지 않음’ 같은 상황에 적합합니다.

시스템 프록시와 TUN: 트래픽 처리 범위부터 구분하기

시스템 프록시는 앱이 참조하는 연결 설정이지, 모든 트래픽을 프록시로 강제 전송하는 스위치가 아닙니다. 시스템 설정을 따르는 브라우저는 로컬 프록시 포트에 연결하지만, 설정을 무시하는 명령줄 도구는 직접 인터넷에 연결할 수 있습니다. v2rayN의 TUN 모드는 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 처리하므로 권한·라우팅·DNS가 관련됩니다. 시스템 프록시와 같은 기능으로 보면 안 됩니다.

앱이 설정을 읽음 로컬 프록시 진입점 코어에서 라우팅 규칙 확인 대상 아웃바운드 연결 선택 대상 서비스 응답

이 경로에서 어느 한 단계라도 끊기면 웹페이지가 로드되지 않을 수 있습니다. 시스템 설정은 올바르지만 코어가 실행되지 않는다면 로컬 진입점 문제입니다. 로컬 진입점은 정상이지만 노드 연결에 실패한다면 아웃바운드 문제입니다. 특정 브라우저에서만 실패한다면 우선 브라우저 자체의 프록시 설정을 확인하세요. 점검할 때는 한 가지 트래픽 처리 방식만 사용하고 TUN과 다른 프록시 도구는 잠시 꺼 두세요. 여러 경로가 겹치면 요청이 실제로 어디를 거치는지 판단하기 어렵습니다.

브라우저와 터미널 모두 실패: 먼저 로컬 포트를 테스트한 뒤 노드와 라우팅 로그를 확인하세요.
브라우저는 실패하지만 프록시를 명시한 명령은 성공: 확장 프로그램, PAC, 브라우저 자체 프록시 설정을 먼저 확인하세요.
브라우저는 성공하지만 터미널은 실패: 환경 변수, 도구 설정, 실행 환경을 먼저 확인하세요.
일부 도메인만 실패: 우회 목록, 도메인 라우팅, DNS, 대상 서비스 상태를 확인하세요.

로컬 리스닝: 프록시를 명시해 먼저 테스트하기

v2rayN을 열어 노드가 선택되어 있는지 확인하고, 실행 로그에서 시작 실패나 포트 충돌이 있는지 살펴보세요. 그런 다음 현재 클라이언트 설정 또는 실제 실행 구성에서 리스닝 주소와 포트, 진입점 유형을 확인합니다. 아래에서는 HTTP 프록시 연결을 받는다고 가정하고 127.0.0.1:10808을 예시 진입점으로 사용합니다. 모든 버전의 기본 포트를 뜻하는 것은 아니므로 실행 전에 실제 설정값으로 바꾸세요.

10808

로컬 포트 예시이며 실제 설정을 확인하세요

5초

예시 연결 제한 시간

20초

예시 요청 전체 제한 시간

Windows에서는 PowerShell에서 다음 명령으로 포트를 확인한 뒤, 공개 테스트 도메인에 프록시를 명시해 요청할 수 있습니다. 일부 PowerShell 환경에서는 curl이 다른 명령으로 해석될 수 있으므로 curl.exe를 사용합니다. 예시에서는 GET 요청을 보내고 응답 본문은 버립니다. 일부 사이트가 HEAD 요청을 거부해 잘못 판단하는 상황을 피하기 위해서입니다.

Test-NetConnection -ComputerName 127.0.0.1 -Port 10808

curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 20 --output NUL --write-out "HTTP=%{http_code}\n" https://example.com/

TcpTestSucceeded : True는 TCP 포트에 연결할 수 있다는 뜻일 뿐, 해당 포트가 HTTP 프록시 연결을 받는다는 의미도 원격 노드가 정상이라는 의미도 아닙니다. 프록시를 명시한 요청에서 HTTP 상태 코드가 반환되어야 최소한 HTTP 응답을 받았다고 볼 수 있습니다. 403이나 다른 거부 상태가 반환되면 응답이 대상 사이트에서 왔는지 중간 장비에서 왔는지도 확인해야 합니다. 이 테스트는 도메인 하나만 확인하므로 모든 서비스가 정상인지 검증하는 용도로 대신할 수 없습니다.

결론: 프록시를 명시한 요청이 성공한 뒤 브라우저 설정을 바꾸세요

로컬 프록시를 명시한 요청이 성공했다면 노드와 코어 설정은 그대로 두고 실패하는 앱의 프록시 진입점만 조정하세요. 테스트에 실패한다면 리스닝이나 아웃바운드 문제부터 해결하고, 브라우저 옵션을 반복해서 바꾸지 마세요.

브라우저 점검: 확장 프로그램·PAC·우회 목록

브라우저에는 시스템 설정, 프록시 확장 프로그램, 자체 프록시 설정이 함께 적용될 수 있습니다. 먼저 현재 설정을 기록한 뒤 항목을 하나씩 확인하세요. 한 번에 하나의 옵션만 바꾸고 같은 주소에 접속해 비교합니다. 브라우저를 바꾼 뒤 페이지가 열린다고 해서 노드 문제가 해결된 것은 아닙니다. 두 브라우저가 서로 다른 연결 경로를 사용한다는 뜻일 가능성이 큽니다.

시스템 프록시 진입점 확인

Windows 11에서 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’로 이동해 ‘수동 프록시 설정’의 주소와 포트를 확인하고, 클라이언트의 현재 리스닝 설정과 일치하는지 비교하세요. PAC를 사용한다면 ‘설정 스크립트 사용’의 스크립트 주소를 확인하세요. 스크립트 URL을 프록시 서버 주소로 착각하면 안 됩니다.
프록시 확장 프로그램 일시 중지

Chrome에서 ‘확장 프로그램’ → ‘확장 프로그램 관리’를 열어 프록시를 제어하는 확장 프로그램을 일시적으로 사용 중지하세요. 그런 다음 ‘설정’ → ‘시스템’ → ‘컴퓨터의 프록시 설정 열기’에서 시스템 구성을 확인합니다. 설정이 조직에서 관리된다고 표시되면 기기 정책을 확인해야 합니다. 일반 설정 스위치로는 정책을 덮어쓸 수 없는 경우가 있습니다.
브라우저 자체 설정 확인

Firefox에서 ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’을 열어 ‘시스템 프록시 설정 사용’과 ‘수동 프록시 구성’ 중 무엇이 선택되어 있는지 확인하세요. 수동 구성을 사용한다면 포트와 프록시 유형이 로컬 진입점과 일치해야 합니다. HTTP 진입점을 SOCKS 항목에 잘못 입력하지 마세요.
우회 조건 확인

시스템 프록시 예외, 브라우저의 ‘프록시 사용 안 함’ 목록, PAC 반환값을 확인하세요. 테스트 도메인이 우회 조건에 해당하면 요청은 직접 연결됩니다. PAC의 DIRECT는 직접 연결을 뜻하고, PROXY 127.0.0.1:10808은 해당 HTTP 프록시 진입점을 사용한다는 뜻입니다.
연결 다시 설정하기

기존 연결이 재사용되는 영향을 배제하려면 브라우저 창을 모두 닫은 뒤 다시 실행하세요. 시크릿 창에서도 모든 확장 프로그램이 자동으로 사용 중지되는 것은 아니며 시스템 프록시를 자동으로 무시하지도 않습니다. 더 확실하게 비교하려면 확장 프로그램이 설치되지 않은 임시 브라우저 프로필을 사용하세요.

PAC는 URL이나 호스트 이름에 따라 연결 방식을 결정하는 스크립트이지, ‘켜면 모두 프록시를 사용하는’ 기능이 아닙니다. 스크립트에 연결할 수 없거나 이전 포트를 반환하거나 대상 도메인을 직접 연결하도록 규칙이 설정되어 있으면 웹페이지가 여전히 열리지 않을 수 있습니다. 확인된 수동 프록시 진입점으로 잠시 바꿔 비교해 보세요. 문제가 사라지면 PAC 설정을 되돌리고 규칙을 점검합니다. 테스트가 끝나면 사내 네트워크나 LAN 예외를 복구해 내부 서비스에 영향이 없도록 하세요.

터미널 점검: http_proxy와 도구별 설정

명령줄 도구가 시스템 프록시 설정을 읽는다고 단정할 수는 없습니다. 먼저 위에서 설명한 --proxy 옵션으로 진입점을 명시해 테스트하고, 성공한 뒤 환경 변수를 설정하세요. 전역 설정을 바로 변경하지 마세요. 현재 터미널 세션에서 먼저 검증하고 효과가 확인되면 지속적으로 적용할지 결정하세요. 새로 연 터미널, 편집기 내장 터미널, 백그라운드 서비스는 서로 다른 환경 변수를 물려받을 수 있습니다. 한 창의 결과만으로 다른 프로세스까지 판단하면 안 됩니다.

PowerShell: 현재 세션에서만 변경

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 5 --max-time 20 --output NUL --write-out "HTTP=%{http_code}\n" https://example.com/

https_proxy는 일반적으로 HTTPS 대상에 연결할 때 사용할 프록시를 지정하며, 값이 반드시 https://로 시작해야 하는 것은 아닙니다. 환경 변수의 대소문자 지원 여부는 도구마다 다릅니다. curl은 http_proxy의 대소문자를 특별히 처리하므로 여러 환경에서 재사용하려면 소문자 이름을 쓰는 편이 좋습니다. 변수를 확인할 때는 ALL_PROXY와 NO_PROXY도 살펴보세요. 후자의 설정에 따라 대상 도메인이 프록시를 우회할 수 있습니다.

macOS 및 Linux: 현재 셸 확인

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 5 --max-time 20 --output /dev/null --write-out 'HTTP=%{http_code}\n' https://example.com/

증상	우선 확인할 항목	조치
프록시를 명시하면 성공하지만 일반 요청은 실패	환경 변수를 읽지 못했거나 우회 조건이 설정됨	환경 변수와 도구 문서를 확인하고 no_proxy 범위를 좁혀 다시 테스트
curl은 성공하지만 다른 도구는 실패	도구 자체의 프록시 설정	실행 옵션, 설정 파일, 실행 중 프록시 옵션 확인
새 터미널은 성공하지만 기존 터미널은 실패	기존 프로세스가 이전 환경 변수를 물려받음	터미널이나 상위 프로세스를 다시 시작
컨테이너 또는 가상 환경에서 연결 거부	127.0.0.1이 해당 환경 자체를 가리킴	해당 환경에서 접근할 수 있는 호스트 주소를 사용하고 리스닝 및 방화벽을 확인

브라우저 프록시 확장 프로그램의 설정은 터미널에 자동으로 전달되지 않으며, 터미널 환경 변수도 이미 실행 중인 브라우저 설정을 바꾸지 않습니다. 컨테이너 안의 127.0.0.1은 대개 호스트 컴퓨터가 아니라 컨테이너 자체를 가리킵니다. 그렇다고 문제를 해결하려고 모든 네트워크 인터페이스에서 리스닝하도록 무작정 설정하지는 마세요. 환경 간 접근이 꼭 필요하다면 허용할 주소를 제한하고 적절한 접근 제어를 설정해야 합니다.

오류 구분: 연결·DNS·TLS를 따로 확인

실패한 명령의 전체 오류 메시지를 보관하고 같은 시간대의 클라이언트 로그도 확인하세요. 브라우저 오류 페이지로는 실패 단계의 일부만 알 수 있지만, 명령줄의 상세 출력은 ‘로컬 진입점 연결 실패’와 ‘원격 핸드셰이크 실패’를 구분하는 데 더 유용한 경우가 많습니다. 로그를 공유하기 전에 구독 주소, 노드 인증 정보, 개인적인 접속 기록을 삭제하세요.

오류: ERR_PROXY_CONNECTION_FAILED

원인:브라우저가 설정된 프록시 진입점에 연결하지 못했습니다. 클라이언트가 종료되었거나 포트가 바뀌었거나 프록시 확장 프로그램이 이전 주소를 가리키는 경우가 흔합니다.

해결 방법:현재 주소의 로컬 포트를 테스트한 뒤 브라우저가 실제로 사용하는 프록시 설정을 확인하세요. 원격 노드부터 바꾸지는 마세요.

오류: curl: (7) Failed to connect

원인:TCP 연결이 성립하지 않았습니다. 이어지는 메시지를 확인해 연결에 실패한 대상이 로컬 프록시 주소인지 대상 서버인지 구분하세요.

해결 방법:실패 대상이 127.0.0.1이면 리스닝 포트, 코어 시작 로그, 포트 충돌을 확인하세요. 원격 주소라면 해당 네트워크 경로를 점검하세요.

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

원인:프록시 호스트 이름을 확인할 수 없거나 환경 변수 형식이 잘못되어 도구가 잘못된 값을 호스트 이름으로 처리하고 있습니다.

해결 방법:프록시 URL의 프로토콜, 호스트, 포트를 확인하세요. 로컬 진입점에는 실제 루프백 주소를 사용하고 PAC 스크립트 주소를 프록시 변수에 넣지 마세요.

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

원인:대상 호스트 이름을 확인하지 못했습니다. 프록시를 우회해 직접 연결 중이거나 SOCKS 설정에서 로컬이 대상 도메인을 확인하도록 구성한 경우가 흔합니다.

해결 방법:먼저 요청이 프록시를 우회하는지 확인한 다음 로컬 DNS 확인과 프록시 측 DNS 확인을 비교하세요. 이 오류 하나만 보고 모든 DNS 설정을 바꾸지는 마세요.

오류: curl: (60) SSL certificate problem

원인:인증서 신뢰 체인 검증에 실패했습니다. 시스템 시간, 누락된 신뢰 인증서, 네트워크의 TLS 검사 장비가 원인일 수 있습니다.

해결 방법:시스템 시간과 인증서 체인을 확인하고 조직의 지침에 따라 신뢰 인증서를 설정하세요. 인증서 검증을 계속 꺼 두는 것은 해결 방법이 아닙니다.

실제 진입점이 SOCKS5를 지원한다면 아래 두 명령으로 도메인 이름을 어느 쪽에서 확인하는지 비교할 수 있습니다. socks5://는 curl이 로컬에서 대상 도메인을 확인하고, socks5h://는 프록시에 대상 도메인 처리를 맡깁니다. 뒤의 명령에서만 성공한다면 로컬 DNS 확인 경로를 먼저 살펴보세요. 여기서도 예시 포트를 사용하므로 HTTP 전용 진입점에 SOCKS 명령을 그대로 적용하면 안 됩니다.

curl.exe --noproxy "" --proxy socks5://127.0.0.1:10808 --connect-timeout 5 --max-time 20 --output NUL https://example.com/

curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 20 --output NUL https://example.com/

V2Ray 프로토콜 선택은 별개의 문제입니다. 브라우저는 로컬 HTTP 또는 SOCKS 진입점에 연결하고, 코어는 노드 설정에 따라 VMess, VLESS 등의 프로토콜로 아웃바운드 연결을 합니다. 아웃바운드 프로토콜을 바꾼다고 시스템 프록시를 무시하는 앱이 갑자기 설정을 읽지는 않습니다. V2Ray 노드 속도 측정 결과도 특정 테스트 조건에서 참고할 자료일 뿐, 브라우저 우회 목록이나 터미널 변수, 대상 웹사이트 인증서가 모두 올바르다는 증거는 아닙니다.

복구 및 재테스트: 남은 설정이 직접 연결에 영향을 주지 않도록 하기

점검이 끝나면 임시로 변경한 설정을 모두 복구하세요. 특히 클라이언트를 종료했는데도 시스템 수동 프록시가 로컬 포트를 가리키면 시스템 설정을 따르는 브라우저는 더 이상 프로그램이 리스닝하지 않는 진입점에 계속 연결하게 됩니다. 먼저 v2rayN의 시스템 프록시 메뉴에서 ‘시스템 프록시 해제’를 선택한 뒤 클라이언트를 종료하세요. 클라이언트를 시작할 수 없다면 운영체제의 프록시 설정에서 해당 진입점을 직접 끄세요.

브라우저:필요한 확장 프로그램과 기존 PAC 설정을 복구하고 이전 포트를 가리키지 않는지 확인하세요.
터미널:테스트 세션을 닫거나 임시 환경 변수를 삭제하세요. 시작 파일을 수정했다면 해당 파일도 확인해야 합니다.
클라이언트:기존 라우팅 및 트래픽 처리 방식을 복구해 비교용으로 설정한 전역 프록시가 남지 않도록 하세요.
재테스트:직접 연결, 프록시를 명시한 요청, 브라우저, 일반 터미널 요청 결과를 각각 기록해 같은 결과를 다시 얻을 수 있는지 확인하세요.

현재 세션의 프록시 변수 제거

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

# macOS / Linux shell
unset http_proxy https_proxy all_proxy no_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

위 명령은 현재 세션에서 해당 변수만 제거합니다. Windows 사용자 수준의 영구 변수는 삭제하지 않으며 셸 시작 파일도 수정하지 않습니다. 실행 전에 원래 값을 기록해 두세요. 조직에서 제공한 네트워크 설정에 해당하는 변수라면 비우지 말고 원래 값으로 복구해야 합니다. 편집기에 통합된 터미널을 사용한다면 상위 프로세스에서 물려받은 이전 변수를 지우기 위해 편집기를 다시 시작해야 할 수도 있습니다.

결론: 실패한 구간에만 손대고 정상 설정은 유지하세요

로컬 진입점이 성공하면 포트 설정을 유지하고, 프록시를 명시한 요청이 성공하면 노드 설정을 유지하세요. 특정 앱만 실패한다면 해당 앱을 점검하면 됩니다. 한 번의 테스트에서 변수 하나만 바꾸는 편이 클라이언트를 재설치하거나 구독을 반복해서 갱신하는 것보다 원인을 신뢰성 있게 파악하기 쉽습니다.

구독을 가져오면 노드 설정 출처는 해결되지만, 브라우저 프록시를 설정하거나 터미널에 환경 변수를 자동으로 추가해 주지는 않습니다. 데스크톱에서는 이 글의 안내에 따라 v2rayN 진입점과 앱 설정을 확인하세요. Android용 v2rayNG는 구독을 가져온 뒤 앱의 절차에 따라 VPN 서비스를 시작해야 하며, 이는 데스크톱 시스템 프록시와는 다른 연결 경로입니다. v2rayNG 다운로드나 다른 V2Ray 클라이언트를 찾는다면 다운로드 페이지에서 플랫폼에 맞는 v2rayN, v2rayNG, v2flyNG를 선택한 뒤 시작 가이드를 참고해 기본 설정을 마치세요.