브라우저에서 접속된다고 해서 터미널도 프록시를 사용하고 있는 것은 아닙니다. 이 글에서는 Windows용 v2rayN을 기준으로 실제 수신 대기 포트를 확인하고, 프록시를 명시한 요청으로 문제를 분리한 뒤 브라우저 설정과 터미널 환경 변수를 각각 바로잡습니다. 웹페이지는 열리지만 명령줄에서 시간 초과가 발생하거나 시스템 프록시를 켜도 효과가 없는 경우에 유용합니다. 클라이언트를 재설치하거나 구독을 반복해서 바꿀 필요는 없습니다.
1. 시스템 프록시와 터미널 프록시는 서로 다른 경로
v2rayN의 시스템 프록시 기능은 주로 운영체제 설정에 로컬 프록시 주소를 기록해 해당 설정을 읽는 앱에서 사용하도록 합니다. 그렇다고 PC의 모든 네트워크 연결을 가로채는 것은 아닙니다. 브라우저는 시스템 설정을 읽을 수도 있지만 확장 프로그램이나 조직 정책이 설정을 덮어쓸 수도 있습니다. 명령줄 도구는 환경 변수, 자체 설정 파일 또는 실행 인자만 참조할 수 있습니다.
이 연결 경로에서 시스템 프록시는 앱이 진입점을 찾도록 도울 뿐입니다. 요청이 코어에 들어간 뒤에는 라우팅 규칙에 따라 직접 연결할지, 프록시를 사용할지, 차단할지가 결정됩니다. 따라서 “클라이언트가 요청을 받았다”는 것과 “요청이 원격 노드를 통해 나갔다”는 것은 별개의 의미입니다. 브라우저 접속이 성공했더라도 직접 연결 규칙이 적용됐을 수 있으므로, 그것만으로 노드가 작동한다고 판단할 수 없습니다.
- 시스템 프록시: 지원하는 앱에 프록시 주소를 제공하지만, 모든 터미널 도구가 자동으로 사용하는 것은 아닙니다.
- 로컬 인바운드: 코어가 수신 대기하는 HTTP, SOCKS 또는 혼합 프로토콜 진입점입니다. 주소와 프로토콜이 일치해야 합니다.
- 라우팅 분기: 요청이 코어에 들어온 뒤 아웃바운드를 선택합니다. 원래 직접 연결하는 앱을 자동으로 프록시에 연결하지는 않습니다.
- TUN 모드: 별도의 트래픽 연결 방식입니다. 이번에는 진입 경로를 분리해 확인할 수 있도록 먼저 끄세요. 시스템 프록시와 함께 사용하면 원인을 파악하기 어려울 수 있습니다. 테스트가 끝나면 원래 설정으로 복원하세요.
2. 기존 안내를 그대로 따르지 말고 10808과 10809 확인
일부 구형 설정에서는 10808을 SOCKS 진입점, 10809를 HTTP 진입점으로 사용하지만 다른 설정에서는 10808 하나만 혼합 진입점으로 제공할 수 있습니다. 포트 번호만으로 프로토콜을 알 수 없으며 업그레이드, 마이그레이션 또는 수동 변경 후에는 포트가 달라질 수도 있습니다. v2rayN의 「설정」→「매개변수 설정」에서 로컬 수신 관련 항목을 확인하고, 시작 로그에서 실제 적용된 값을 대조하세요. 화면 구성에 따라 항목 이름은 조금 다를 수 있습니다.
아래 PowerShell 명령은 두 예시 포트의 상태만 확인하며 설정을 변경하지 않습니다. 실제 포트가 다르면 해당 값으로 바꾸세요. 출력의 OwningProcess는 수신 프로세스의 ID입니다. Get-Process -Id 프로세스 ID로 프로세스를 확인할 수 있습니다. 실제로 수신 대기하는 프로세스는 화면 프로세스가 아니라 코어 프로세스인 경우가 많습니다.
Get-NetTCPConnection -State Listen |
Where-Object { $_.LocalPort -in 10808,10809 } |
Select-Object LocalAddress,LocalPort,OwningProcess| 확인 결과 | 가능한 의미 | 다음 단계 |
|---|---|---|
| 두 포트 모두 수신 대기하지 않음 | 코어가 실행되지 않았거나 다른 포트를 사용 중 | 시작 로그와 실제 매개변수를 확인하고, 터미널 변수를 먼저 수정하지 마세요. |
| 10808만 수신 대기 중 | 단일 프로토콜 진입점일 수도 있고 혼합 진입점일 수도 있음 | 인바운드 유형을 확인한 다음 HTTP 또는 SOCKS로 테스트 |
| 현재 코어가 아닌 프로세스가 수신 중 | 다른 프로그램 또는 남아 있는 프로세스가 포트를 사용 중 | 프로세스의 용도를 확인한 다음 조치하고, 무작정 종료하지 마세요. |
| IPv6 루프백 주소에서만 수신 중 | 명시한 IPv4 주소와 일치하지 않음 | 수신 주소를 확인하거나 일치하는 IPv6 루프백 주소로 테스트 |
3. 프록시를 명시한 요청으로 터미널 문제 분리
환경 변수를 거치지 않고 명령에 프록시 주소를 직접 지정하세요. Windows PowerShell에서는 curl이 다른 명령의 별칭으로 동작하는 경우를 피하기 위해 curl.exe를 명시하는 것이 좋습니다. 먼저 curl.exe --version을 실행해 도구가 있는지 확인하세요. 아래 대상 주소는 테스트 방법을 보여 주기 위한 예시입니다. 서로 다른 라우팅이 적용되지 않도록 브라우저에서 확인 중인 것과 동일한 공개 HTTPS 주소로 바꿔도 됩니다.
# 10809가 HTTP 진입점임을 확인한 경우에만 실행
curl.exe -v --connect-timeout 10 --max-time 30 --noproxy "" --proxy http://127.0.0.1:10809 https://example.com/ -o NUL
# 10808이 SOCKS5를 지원한다고 확인한 경우에만 실행
curl.exe -v --connect-timeout 10 --max-time 30 --noproxy "" --proxy socks5h://127.0.0.1:10808 https://example.com/ -o NUL--noproxy ""는 이번 테스트에서 우회 목록을 비워 NO_PROXY 설정 때문에 요청이 실수로 직접 연결되는 일을 막습니다. 실제 HTTP 혼합 진입점이 10808이라면 첫 번째 명령의 포트를 10809로 복사하지 말고 10808로 바꾸세요. socks5h는 대상 도메인 이름을 SOCKS 프록시 측에서 해석합니다. socks5는 보통 로컬에서 먼저 이름을 해석하므로 두 방식의 DNS 경로가 다릅니다.
- 먼저 로컬 연결을 확인하세요. 상세 출력에서 대상 공용 주소가 아니라 지정한 루프백 주소와 포트에 연결하는지 확인합니다.
- 다음으로 프록시 협상을 확인하세요. HTTP 프록시로 HTTPS에 접속하면 보통 CONNECT 터널 협상이 표시됩니다. SOCKS라면 해당 프로토콜의 연결 과정이 보여야 합니다.
- 마지막으로 응답을 확인하세요. HTTP 상태 코드가 반환됐다면 최소한 서버 응답을 받은 것입니다. 403 등의 응답을 단순히 로컬 포트 문제로 볼 수 없으며, 대상 서비스를 정상적으로 이용할 수 있다는 뜻도 아닙니다.
- 코어 로그도 함께 확인하세요. 같은 시각의 대상 도메인과 아웃바운드 선택을 확인합니다. 로그에 아웃바운드가 명확하게 기록된 경우에만 예상한 노드를 거쳤는지 판단할 수 있습니다.
프록시를 명시한 요청은 성공하지만 일반 명령은 실패한다면 도구가 프록시 설정을 읽는 방식을 먼저 확인하세요. 명시적 프록시 요청도 실패하면 로컬 진입점, 노드 연결, 라우팅을 우선 점검하고 환경 변수를 계속 추가하지 마세요. 테스트할 때는 한 번에 조건 하나만 바꾸고 명령, 시간, 결과를 기록하세요. “웹페이지가 열리지 않음”만 적는 것보다 문제를 재현하기 쉽습니다.
4. 브라우저의 시스템 프록시, 확장 프로그램, 우회 규칙 확인
v2rayN 트레이 메뉴에서 「시스템 프록시」 상태를 확인하세요. 「시스템 프록시 자동 설정」은 보통 클라이언트가 현재 프록시 설정을 기록한다는 뜻이며, PAC 파일이 적용됐다는 의미는 아닙니다. 「시스템 프록시 지우기」는 해당 설정을 취소합니다. 「시스템 프록시 변경 안 함」은 설정을 직접 수정하지 않는다는 뜻일 뿐, 기존 시스템 프록시가 꺼졌다는 의미는 아닙니다.
- Windows 「설정」→「네트워크 및 인터넷」→「프록시」에서 수동 프록시 주소와 포트가 현재 HTTP 또는 혼합 진입점과 일치하는지 확인하세요. 설정 스크립트가 켜져 있는지도 살펴보세요.
- 프록시 연결을 가로채는 브라우저 확장 프로그램을 잠시 사용 중지하세요. 확장 프로그램이 이전 포트를 계속 사용하면 시스템 설정이 올바르더라도 적용되지 않을 수 있습니다.
- 브라우저에 별도의 수동 프록시가 설정되어 있는지 확인하세요. Firefox에서는 「설정」→「일반」→「네트워크 설정」→「설정」에서 시스템 프록시를 사용하는지 확인할 수 있습니다. 조직에서 관리하는 브라우저라면 정책 제한도 확인하세요.
- 브라우저를 완전히 종료한 뒤 다시 열고 같은 주소로 재시도하면서 코어 로그에 새 요청이 기록되는지 확인하세요. 기존 연결이나 캐시된 페이지는 새 설정이 적용됐다는 증거가 아닙니다.
특정 확장 프로그램을 켜야 브라우저에 접속된다면 먼저 확장 프로그램이 실제로 사용하는 프로토콜과 포트를 기록하고 시스템 설정과 비교하세요. 대개 두 진입 경로가 다르다는 뜻이지 시스템 프록시 버튼이 고장 났다는 의미는 아닙니다. 브라우저와 명령줄에서 서로 다른 도메인을 테스트했다면 아웃바운드 결과를 비교하기 전에 테스트 대상을 통일하세요.
5. 터미널 환경 변수는 도구의 지원 범위에 맞춰 설정
많은 터미널 도구가 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY를 읽지만, 지원 범위와 우선순위, 설정 파일 규칙은 도구마다 다릅니다. 먼저 현재 프로세스에서 어떤 값이 보이는지 확인하고 전역 환경 설정은 바로 수정하지 마세요. 아래 PowerShell 명령은 값을 조회만 합니다. 출력에 사용자 이름, 비밀번호 또는 내부 주소가 포함되어 있다면 공유하기 전에 민감한 내용을 삭제하세요.
Get-ChildItem Env: |
Where-Object { $_.Name -match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$' }아래는 현재 PowerShell 세션의 설정 예시입니다. 먼저 10809가 HTTP 프록시를 지원하는지 확인해야 합니다. 이미 변수가 설정되어 있다면 테스트 전에 원래 값을 기록하고 끝난 뒤 복원하세요. Windows에서는 환경 변수 이름의 대소문자를 구분하지 않는 경우가 일반적입니다. 다른 셸에서는 대소문자 차이에 주의하세요. 예를 들어 curl의 HTTP 프록시 변수는 소문자 http_proxy를 사용합니다.
$env:http_proxy = 'http://127.0.0.1:10809'
$env:https_proxy = 'http://127.0.0.1:10809'
curl.exe -v --connect-timeout 10 --max-time 30 https://example.com/ -o NULhttps_proxy 값에 http://를 사용해도 됩니다. 여기서 프로토콜은 대상 웹페이지가 아니라 “도구가 프록시에 연결하는 방식”을 나타냅니다. HTTPS 사이트에 접속할 때 도구는 일반 HTTP 프록시를 통해 CONNECT 터널을 만든 다음 터널 안에서 대상과 TLS 연결을 설정할 수 있습니다. 이를 무조건 https://127.0.0.1:10809로 바꾸면 TLS를 지원하지 않는 로컬 프록시와 핸드셰이크를 시도해 실패할 수 있습니다.
- NO_PROXY: 대상 도메인, 도메인 접미사 또는
*가 포함되어 있으면 요청이 프록시를 우회할 수 있습니다. 먼저 기존 값을 저장하고 필요한 대상만 지정해 테스트하세요. 필요한 내부망 예외를 영구적으로 삭제하지 마세요. - ALL_PROXY: 일부 도구는 이를 공통 프록시 진입점으로 사용합니다. 이전 값이 남아 있으면 결과에 영향을 줄 수 있으므로, 우선순위는 해당 도구의 문서를 확인하세요.
- 하위 프로세스의 환경 상속: 현재 터미널에서 실행한 프로그램은 보통 현재 환경 변수를 이어받습니다. 이미 실행 중인 편집기의 통합 터미널에는 나중에 변경한 시스템 변수가 반영되지 않을 수 있습니다.
- 별도 실행 환경: WSL과 컨테이너는 자체 네트워크 환경을 사용합니다. 내부의
127.0.0.1이 Windows 호스트를 가리키지 않을 수 있으므로 실제 네트워크 모드에 맞춰 확인해야 합니다. 로컬 주소를 그대로 적용하지 마세요.
테스트 전에 변수가 설정되어 있지 않았다면 아래 명령으로 현재 세션의 설정을 지울 수 있습니다. 기존 값이 있었다면 삭제하지 말고 원래 값으로 복원하세요. PowerShell 창을 닫아도 세션 단위 변경은 종료됩니다. 정상 동작을 확인한 뒤에만 장기 설정을 고려하고, 전역 변수로 다른 작업에 영향을 주지 않도록 실제 명령줄 도구의 프록시 옵션도 각각 확인하세요.
Remove-Item Env:http_proxy -ErrorAction SilentlyContinue
Remove-Item Env:https_proxy -ErrorAction SilentlyContinue6. 오류가 발생한 단계로 원인 파악하기
아래에는 curl에서 흔히 보이는 오류의 핵심 부분을 정리했습니다. 전체 출력에 포함된 주소, 소요 시간, TLS 백엔드 안내는 환경마다 다를 수 있습니다. 로컬 진입점 연결, 프록시 협상, 대상 접속 중 어느 단계에서 오류가 발생했는지 먼저 확인한 뒤 관련 설정을 수정하세요.
오류: curl: (7) Failed to connect to 127.0.0.1 port 10809
원인: 로컬 TCP 연결이 성립하지 않았습니다. 포트가 수신 대기하지 않거나 주소가 맞지 않을 때 흔히 발생합니다. 해결: 수신 상태를 조회해 현재 코어와 실제 포트를 확인한 뒤 프록시를 명시한 요청을 다시 시도하세요. 원격 노드를 먼저 바꾸지는 마세요.
오류: curl: (5) Could not resolve proxy
원인: 프록시 서버 이름을 해석하지 못했습니다. 환경 변수의 호스트 이름이 잘못됐거나 불필요한 문자가 포함됐을 수 있습니다. 해결: 환경 변수 전체 값을 확인하고, 확인된 루프백 주소를 사용해 명시적으로 테스트하세요. 프록시 주소와 대상 도메인 중 어느 쪽에서 이름 해석이 실패했는지 구분할 수 있습니다.
오류: curl: (28) Connection timed out
원인: 특정 연결 단계가 제한 시간을 초과했습니다. 이 한 줄만으로 노드, DNS, 대상 서비스 중 무엇이 문제인지 알 수 없습니다. 해결: -v 출력에서 마지막으로 완료된 단계와 같은 시각의 코어 로그를 대조해 로컬 연결이 성립했는지 확인한 뒤 후속 아웃바운드를 점검하세요.
오류: curl: (35) SSL connect error
원인: TLS 연결에 실패했습니다. 프로토콜 설정 오류, 중간 장비 또는 대상과의 협상 문제일 수 있습니다. 해결: 먼저 로컬 프록시 URL의 프로토콜을 확인한 다음 시스템 시간과 전체 TLS 안내를 점검하세요. 인증서 검증을 끄는 방법을 일반적인 해결책으로 사용하지 마세요.
로그 상세 수준을 일시적으로 높이면 라우팅과 연결 단계를 구분하는 데 도움이 됩니다. 다만 로그에 접속 도메인과 노드 주소가 포함될 수 있습니다. 문제를 확인한 뒤 원래 로그 수준으로 되돌리고, 공유할 때는 필요한 부분만 남기세요. 구독 주소, 인증 정보, 개인 접속 기록은 가려야 합니다.
7. 자주 묻는 질문과 복원 확인
브라우저도 정상이고 curl에서 프록시를 직접 지정해도 되는데, 일반 명령은 왜 실패하나요?
진입점과 기본 연결은 확인됐으므로 다음으로 해당 도구가 환경 변수를 읽는지, 자체 프록시 설정이 있는지, NO_PROXY가 대상에 적용되는지 확인하세요. 같은 터미널에서 테스트한 다음 그 터미널에서 실제 도구를 실행해 환경 상속 차이를 피하세요.
포트를 바꾼 뒤 브라우저는 다시 되는데 터미널은 왜 이전 포트에 연결하나요?
시스템 프록시와 터미널 변수는 별도로 설정됩니다. 현재 터미널의 프록시 변수를 다시 확인하고 실제 포트로 바꾸세요. 도구가 설정 파일을 사용한다면 해당 항목도 수정해야 합니다. 계속 실행 중인 프로세스는 다시 시작해야 할 수 있습니다.
10808을 사용한다면 10809도 반드시 열어야 하나요?
반드시 그런 것은 아닙니다. 10808이 혼합 진입점이라면 HTTP와 SOCKS 클라이언트가 각자 사용하는 프로토콜로 같은 포트에 연결할 수 있습니다. 먼저 현재 인바운드가 지원하는 프로토콜을 확인하고 테스트하세요. 구형 안내에 맞추려고 수신 설정을 불필요하게 추가하지 마세요.
클라이언트를 종료한 뒤 웹페이지가 모두 열리지 않으면 어떻게 하나요?
Windows 「설정」→「네트워크 및 인터넷」→「프록시」에서 중지된 로컬 포트를 계속 가리키는 설정이 있는지 확인하고 더 이상 사용하지 않는 프록시 설정을 지우세요. 터미널 환경 변수도 테스트 전 값으로 복원하고 브라우저 확장 프로그램도 원래 상태로 되돌리세요.
마지막으로 세 가지를 확인하세요. 프록시를 명시한 요청이 올바른 로컬 진입점에 연결되는지, 브라우저와 터미널이 각각 예상한 프록시 설정을 사용하는지, 코어 로그에서 라우팅 아웃바운드가 의도한 대로 선택되는지 확인해야 합니다. 그래야 “시스템 프록시 설정이 저장됨”, “앱이 실제로 프록시를 사용함”, “요청이 예상한 아웃바운드로 나감”을 구분할 수 있고, 다음에 문제가 생겨도 재설치부터 시작하지 않아도 됩니다.
- 실제 수신 주소와 포트, 프로토콜을 기록하고 반복 실행할 수 있는 테스트 명령을 하나 보관하세요.
- 문제 해결 중 사용 중지한 확장 프로그램, 변경한 환경 변수, 임시 로그 수준을 복원하고 정상 동작을 확인한 설정만 유지하세요.
- 계속 실패하면 도구 이름, 전체 명령, 오류가 발생한 단계, 민감 정보를 가린 로그를 정리해 같은 연결 경로를 이어서 점검하세요.