v2rayN에서 시스템 프록시를 켰는데도 브라우저나 명령줄에서 연결되지 않는 데스크톱 사용자를 위한 안내입니다. 먼저 로컬 프록시 접속 지점을 확인한 다음 브라우저 확장 프로그램, 시스템 프록시 설정, 터미널 환경 변수와 우회 규칙을 각각 점검합니다. 프록시를 명시한 요청과 직접 연결을 비교하면 문제가 앱 설정, 로컬 리스너 또는 원격 연결 중 어디에 있는지 파악할 수 있어, 요청 경로는 그대로인데 노드만 계속 바꾸는 일을 피할 수 있습니다.
시스템 프록시를 설정해도 모든 앱이 프록시를 사용하는 것은 아닙니다
v2rayN의 ‘시스템 프록시’는 주로 운영체제의 프록시 설정에 로컬 프록시 주소를 입력합니다. 앱이 이 설정을 읽는지는 앱 자체에 따라 다릅니다. 브라우저는 대개 시스템 프록시를 사용하지만 확장 프로그램, 시작 옵션 또는 기업 정책이 설정을 덮어쓸 수 있습니다. curl 같은 명령줄 도구는 보통 자체 옵션과 환경 변수를 사용하므로, 트레이 메뉴에서 시스템 프록시가 선택된 것만 보고 터미널 요청도 클라이언트로 전달된다고 단정할 수 없습니다.
‘요청이 클라이언트에 전달되는 것’과 ‘요청이 원격 프록시를 통과하는 것’도 구분해야 합니다. 요청이 로컬 접속 지점에 도달해도 라우팅 규칙에 따라 직접 연결될 수 있습니다. 시스템 프록시는 요청이 들어갈 접속 지점을 정하고, 라우팅은 그다음 아웃바운드 경로를 정하므로 서로 다른 설정입니다. VMess, VLESS 같은 노드 프로토콜을 브라우저의 프록시 유형으로 지정하는 것도 아닙니다. 브라우저는 클라이언트가 제공하는 로컬 HTTP 또는 SOCKS 접속 지점에 연결해야 합니다.
- 브라우저에서만 실패하는 경우: 먼저 확장 프로그램, 브라우저 자체 프록시 설정, 시스템 프록시 주소를 확인하세요.
- 터미널에서만 실패하는 경우: 먼저 명령이 프록시를 지원하는지 확인하고 옵션, 환경 변수, 우회 목록을 점검하세요.
- 브라우저와 터미널 모두 실패하는 경우: 먼저 로컬 포트가 수신 중인지 확인한 뒤 코어 로그와 노드 연결을 점검하세요.
- 일부 도메인만 실패하는 경우: 접속 지점을 확인한 다음 도메인 라우팅, 이름 해석, 대상 사이트 응답을 점검하세요.
먼저 v2rayN 로컬 리스너 포트 확인
아래 예시에서는 HTTP 프록시가 활성화된 로컬 접속 주소로 127.0.0.1:10808을 사용합니다. 문제 해결을 위한 예시 주소일 뿐, 모든 버전과 설정에서 사용하는 고정값은 아닙니다. v2rayN의 ‘설정’ → ‘매개변수 설정’에서 로컬 수신 포트와 접속 유형을 확인하세요. 버전에 따라 ‘로컬 통합 수신 포트’처럼 다른 이름으로 표시될 수 있으니 현재 화면을 기준으로 확인하면 됩니다. HTTP와 SOCKS가 별도 포트를 사용한다면 HTTP에 해당하는 포트를 선택하세요.
Windows PowerShell에서 먼저 포트가 수신 중인지 확인한 뒤 프록시를 명시해 요청을 보내세요. 일부 Windows PowerShell 환경에서는 curl이 다른 명령으로 해석될 수 있으므로 여기서는 curl.exe를 사용합니다. 테스트하는 동안 v2rayN을 실행하고 현재 노드와 코어가 시작된 상태인지 확인하세요.
Get-NetTCPConnection -State Listen -LocalPort 10808
curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:10808 --noproxy "localhost,127.0.0.1" https://example.com/이 명령은 우회 목록을 로컬 주소로 제한하므로 예시 도메인에 접속할 때 지정한 프록시를 사용합니다. 대상 사이트의 HTTP 응답을 받았다면 이번 요청에서 프록시 경로와 대상 연결이 적어도 성립했다는 뜻입니다. 다만 로그에 직접 연결 규칙이 적용된 것으로 표시된다면 원격 노드를 통과했다고 단정할 수 없습니다. 200 Connection established만 표시되는 경우에는 HTTP CONNECT 터널이 수락됐다는 뜻일 뿐이므로, 대상 사이트의 응답도 확인하세요.
브라우저 확장 프로그램 충돌, 세 단계로 분리 점검
프록시를 명시한 테스트는 성공했는데 브라우저만 실패한다면 먼저 ‘브라우저 프록시를 누가 제어하는지’ 확인하세요. 같은 브라우저에서 프록시 확장 프로그램을 여러 개 사용하면 하나는 고정 프록시를, 다른 하나는 자동 설정 스크립트를 적용하는 식으로 충돌하기 쉽습니다. 확장 프로그램 아이콘에 표시되는 모드가 운영체제에 저장된 프록시 모드와 같다는 보장도 없습니다.
-
프록시 확장 프로그램 사용 중지
Chrome에서는 ‘메뉴’ → ‘확장 프로그램’ → ‘확장 프로그램 관리’를 여세요. Edge에서는 ‘메뉴’ → ‘확장’ → ‘확장 관리’를 엽니다. 프록시 설정을 변경하는 확장 프로그램을 모두 임시로 사용 중지하고 기존 상태를 기록한 다음 브라우저를 완전히 종료했다가 다시 시작하세요. 현재 탭만 닫아서는 안 됩니다.
-
시스템 프록시 접속 지점 확인
Windows 11에서 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’를 열고 ‘프록시 서버 사용’의 주소와 포트가 v2rayN의 현재 수신 주소와 일치하는지 확인하세요. ‘설정 스크립트 사용’을 켰다면 스크립트 주소를 기록한 뒤 현재 사용해야 하는 설정인지 확인합니다.
-
확장 프로그램을 하나씩 다시 켜서 테스트
같은 테스트 주소에 다시 접속하세요. 확장 프로그램을 사용 중지한 뒤 정상화됐다면 프록시 확장 프로그램을 하나씩만 다시 켜고 ‘시스템 프록시 사용’ 또는 올바른 고정 프록시 설정을 선택하세요. 매번 한 가지 설정만 바꾸고 같은 주소로 확인해야 캐시, 노드, 규칙을 한꺼번에 변경하는 일을 피할 수 있습니다.
Firefox에서는 ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’을 열어 ‘시스템 프록시 설정 사용’이 선택됐는지 확인하세요. 이전 수동 프록시 설정이나 자동 프록시 설정 주소가 선택되어 있지 않아야 합니다. 브라우저에서 프록시 설정이 조직에 의해 관리된다고 표시되면 기기 관리자에게 문의하세요. v2rayN을 다시 설치해도 브라우저 정책은 보통 해제되지 않습니다.
- 시크릿 창이 완전히 분리된 환경은 아닙니다. 확장 프로그램이 시크릿 모드에서 허용될 수 있고 시스템 프록시와 기기 정책도 계속 적용됩니다.
- 새 탭을 열어도 새 프로세스가 시작되는 것은 아닙니다. 브라우저 프로세스가 시작 당시의 프록시 옵션을 유지할 수 있으므로 필요하면 작업 관리자에서 브라우저가 완전히 종료됐는지 확인하세요.
- 인증서 설정부터 바꾸지 마세요. 일반적인 HTTP CONNECT 프록시를 사용하기 위해 브라우저에 루트 인증서를 설치할 필요는 없습니다. 인증서 오류가 발생하면 먼저 시스템 시간, 대상 도메인, 네트워크 환경을 확인하세요.
터미널 프록시는 환경 변수로 별도 설정
터미널은 프로그램을 실행하는 환경일 뿐, 각 프로그램이 시스템 프록시를 사용하도록 대신 설정해 주지는 않습니다. curl은 보통 프록시 환경 변수를 읽지만 다른 명령은 자체 설정 파일이나 명령줄 옵션을 사용할 수 있습니다. 먼저 앞 절의 --proxy 옵션으로 연결을 확인한 다음 환경 변수를 설정하면 ‘프록시 서비스가 작동하지 않는 문제’와 ‘프로그램이 설정을 읽지 않는 문제’를 구분할 수 있습니다.
Windows PowerShell: 현재 세션에만 설정
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"
curl.exe -I --connect-timeout 10 --max-time 20 https://example.com/https_proxy는 HTTPS 대상 요청에 사용하지만 변수 값은 http://127.0.0.1:10808이어도 됩니다. 이 주소의 프로토콜은 로컬 프록시 서비스의 방식을 가리킵니다. curl은 HTTP CONNECT로 터널을 만들며, 대상 HTTPS 사이트를 암호화되지 않은 방식으로 접속하는 것이 아닙니다. 변수 이름에 HTTPS가 있다고 해서 접속 주소를 무조건 https://로 바꾸지 마세요.
macOS 및 Linux: 환경 변수의 대소문자 확인
env | grep -iE '^(http_proxy|https_proxy|all_proxy|no_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"
curl -I --connect-timeout 10 --max-time 20 https://example.com/대소문자를 구분하는 환경에서 curl의 HTTP 프록시 변수는 소문자 http_proxy를 사용해야 합니다. 대문자 HTTP_PROXY만 설정하면 작동하지 않을 수 있습니다. 다른 도구는 지원 방식이 서로 다를 수 있으므로 해당 도구의 문서를 확인하세요. 우선 현재 세션에만 변수를 설정해 테스트하고, 정상 작동을 확인한 뒤 셸 시작 파일에 추가하는 편이 안전합니다. 그래야 터미널을 열 때마다 잘못된 포트가 자동으로 설정되는 일을 막을 수 있습니다.
우회 목록과 직접 연결 결과를 함께 확인
no_proxy 또는 NO_PROXY는 프록시를 거치지 않을 대상을 지정합니다. 테스트 도메인이 목록에 포함되어 있거나 값이 *라면 프록시 변수를 올바르게 설정해도 프로그램이 직접 연결할 수 있습니다. 또 다른 흔한 원인은 종료된 SOCKS 포트를 가리키는 이전 all_proxy 값입니다. 프로그램마다 변수 적용 우선순위가 다를 수 있으므로 https_proxy 하나만 보지 말고 관련 변수를 모두 확인하세요.
| 테스트 결과 | 우선 확인할 항목 | 다음 조치 |
|---|---|---|
| 프록시를 명시하면 성공하지만 기본 요청은 실패 | 앱의 프록시 설정 출처 | 환경 변수, 별도 설정, 우회 목록 확인 |
| 프록시를 명시하면 실패하지만 직접 연결은 성공 | 로컬 접속 지점 또는 프록시 아웃바운드 | 수신 포트, 접속 프로토콜, 코어 로그 확인 |
| 터미널은 성공하지만 브라우저는 실패 | 브라우저에서 덮어쓴 설정 | 프록시 확장 프로그램을 끄고 시스템 프록시와 브라우저 정책 확인 |
| 두 방식 모두 실패 | 네트워크 또는 대상 서버 연결 | 먼저 기본 네트워크 연결을 확인한 뒤 이름 해석, 핸드셰이크, 대상 사이트를 점검 |
Windows에서는 아래 두 명령으로 같은 대상에 접속할 수 있습니다. 첫 번째는 로컬 프록시를 명시하고, 두 번째는 --noproxy "*"로 직접 연결합니다. macOS와 Linux에서는 명령 이름을 curl로 바꾸면 됩니다. 예시 도메인은 연결 상태를 비교하기 위한 용도입니다. 직접 연결과 프록시 연결이 모두 성공해도 이상한 일이 아니며, 이 결과만으로 접속 출구 지역을 판단할 수는 없습니다.
curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:10808 --noproxy "localhost,127.0.0.1" https://example.com/
curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/결론: 요청 경로를 먼저 고정하세요
프록시를 명시한 요청은 성공하고 기본 요청은 실패한다면 먼저 앱이 프록시를 읽도록 설정하세요. 노드부터 바꾸지 마세요. 같은 로컬 접속 지점으로 요청이 들어간 것이 확인됐는데도 실패할 때만 라우팅과 원격 연결을 더 살펴보세요.
curl 오류 메시지로 실패 단계 확인
브라우저의 ‘페이지에 연결할 수 없음’ 메시지만으로는 원인을 파악하기 어려운 경우가 많습니다. curl의 오류 번호를 보면 접속 지점, 프록시 프로토콜, TLS 단계 중 어디서 실패했는지 구분하기 쉽습니다. 아래는 자주 발생하는 오류 문구이며 전체 출력의 경과 시간, 주소, 추가 설명은 운영체제와 curl 버전에 따라 달라질 수 있습니다.
오류: curl: (7) Failed to connect
원인 및 해결: 지정한 주소에 연결하지 못했습니다. 출력에 127.0.0.1이 표시되면 먼저 v2rayN 코어가 실행 중인지, 포트가 맞는지, 해당 포트에서 수신 중인지 확인하세요. 원격 TLS부터 점검할 필요는 없습니다.
오류: curl: (5) Could not resolve proxy
원인 및 해결: 프록시 호스트 이름을 해석하지 못했습니다. 프록시 변수의 주소 철자, 프로토콜 접두사, 따옴표를 확인하세요. 로컬 접속 지점을 사용하는 경우 실제 루프백 주소와 포트를 입력해야 합니다.
오류: curl: (6) Could not resolve host
원인 및 해결: 대상 호스트 이름을 해석하지 못했습니다. 요청이 의도치 않게 직접 연결됐는지, 이름 해석을 로컬에서 처리하는 SOCKS 모드를 사용하는지 먼저 확인한 다음 로그에서 이름 해석 경로를 살펴보세요. 이 오류를 노드 연결 시간 초과와 같은 문제로 보아서는 안 됩니다.
오류: curl: (28) Connection timed out
원인 및 해결: 제한 시간 내에 연결을 완료하지 못했습니다. 오류에 표시된 주소와 코어 로그를 함께 확인해 로컬 접속 지점에서 실패했는지 이후 원격 연결에서 실패했는지 구분한 다음 노드 주소, 포트, 네트워크 연결 상태를 확인하세요.
오류: curl: (60) SSL certificate problem
원인 및 해결: 인증서 검증에 실패했습니다. 시스템 시간, 인증서 신뢰 체인, 네트워크 가로채기 여부를 확인하세요. 인증서 검증을 끄고 문제가 해결된 것으로 간주하지 마세요.
더 자세한 정보가 필요하면 기존 명령에 -v를 추가해 실제 연결 주소, 프록시 환경 변수 관련 안내, 핸드셰이크 단계를 확인하세요. 로그를 공유하기 전에는 구독 주소, 인증 정보, 프록시 자격 증명, 민감한 요청 헤더를 삭제해야 합니다. 전체 설정을 공개할 필요는 없으며 터미널 환경 변수 전체 목록을 공개 게시판에 올리지 마세요.
설정을 복구하고 점검 결과 확인
테스트가 끝나면 프록시 제어 방식은 명확한 한 가지만 유지하세요. 평소 브라우저에서 시스템 프록시를 사용할 경우 확장 프로그램도 시스템 설정을 따르게 하세요. 터미널에서 프록시가 필요하다면 해당 세션에 환경 변수를 설정하면 됩니다. 시스템 프록시, 확장 프로그램의 고정 프록시, 자동 설정 스크립트, 여러 개의 오래된 환경 변수를 ‘예비용’으로 모두 남겨 두면 다음에 문제가 생겼을 때 요청 경로를 파악하기 어렵습니다.
- Windows 세션 정리: 테스트 전에 기록해 둔 값으로 복원하세요. 원래 환경 변수가 없었다면 아래 명령으로 이번에 추가한 변수를 삭제할 수 있습니다.
- 다른 셸 세션 정리: 마찬가지로 이전 값을 먼저 복원하세요. 원래 변수가 설정되어 있지 않았던 경우에만
unset으로 변수를 삭제하세요. - 클라이언트 설정 마무리: 시스템 프록시를 더 이상 사용하지 않는다면 v2rayN 트레이 메뉴에서 ‘시스템 프록시’ → ‘시스템 프록시 지우기’를 선택한 다음 클라이언트를 종료하세요. 메뉴 문구는 버전에 따라 다를 수 있습니다.
- 결과 기록: 실제 포트, 접속 유형, 브라우저 프록시 제어 방식, 프록시를 명시한 요청과 직접 연결의 결과를 기록해 두면 다음에 같은 조건으로 다시 테스트할 수 있습니다.
# PowerShell: 이번에 추가한, 원래 없던 변수만 삭제
Remove-Item Env:http_proxy, Env:https_proxy, Env:no_proxy -ErrorAction SilentlyContinue
# Bash / Zsh: 이번에 추가한, 원래 없던 변수만 삭제
unset http_proxy https_proxy no_proxy프록시를 명시한 요청은 성공했는데 일부 도메인의 아웃바운드 경로가 예상과 다르다면 라우팅 안내를 계속 확인하세요. 로컬 접속 지점과 노드 연결을 모두 설정할 수 없다면 연결 문제 해결을 참고하세요. 먼저 접속 지점과 앱 설정을 단계별로 확인한 뒤 DNS, 라우팅 또는 노드 옵션을 바꿔야 어떤 변경으로 문제가 해결됐는지 알 수 있습니다.