이 체크리스트는 노드를 가져오고 v2rayN 코어도 실행되지만 웹페이지나 터미널 명령이 계속 연결에 실패할 때 유용합니다. 먼저 로컬 프록시 포트가 실제로 수신 중인지 확인한 다음 브라우저와 명령줄 도구를 각각 테스트하고, 마지막으로 DNS, 라우팅 규칙과 원격 노드를 점검하세요. 점검을 마치면 문제가 애플리케이션, 시스템 프록시, 로컬 인바운드 또는 원격 아웃바운드 중 어디에 있는지 분명히 알 수 있습니다.
재현 가능한 로컬 프록시 기준선부터 만들기
“시스템 프록시가 활성화됨”은 운영체제에 프록시 주소가 저장되어 있다는 뜻일 뿐입니다. v2rayN의 로컬 포트가 작동 중이거나 모든 애플리케이션이 이 설정을 읽는다는 의미는 아닙니다. 제대로 점검하려면 최소한 코어 실행 상태, 로컬 인바운드 포트의 수신 여부, 테스트 애플리케이션이 실제로 해당 포트로 요청을 보내는지 확인해야 합니다.
v2rayN 7.x의 일반적인 설정을 예로 들면 HTTP 프록시는 127.0.0.1:10809, SOCKS 프록시는 127.0.0.1:10808에서 수신할 수 있습니다. 이 숫자는 흔한 예시일 뿐이며 실제 값은 클라이언트 화면의 로컬 수신 설정을 기준으로 해야 합니다. 버전 업그레이드, 백업 가져오기 또는 포트 수동 변경 후에는 예전 튜토리얼의 포트가 더 이상 맞지 않을 수 있습니다.
- v2rayN 메인 화면에서 대상 노드가 현재 활성 서버로 설정되어 있고 코어 상태가 시작 실패나 반복 재시작 상태에 머물러 있지 않은지 확인하세요.
- 「설정」→「매개변수 설정」을 열어 로컬 HTTP 및 SOCKS 수신 포트와 수신 주소를 기록하세요. 버전에 따라 메뉴 이름이 다르면 “로컬 포트” 또는 “인바운드 설정”이 포함된 화면을 찾으면 됩니다.
- 트레이 메뉴에서 “시스템 프록시 설정”에 해당하는 활성화 상태를 선택하세요. “시스템 프록시 지우기”나 “시스템 프록시 변경 안 함”을 선택하면 안 됩니다. 전환한 뒤 테스트 브라우저를 완전히 종료하고 다시 여세요.
- 우선 지연 시간 테스트를 완료할 수 있는 노드를 선택하고 라우팅을 확인하기 쉬운 프록시 모드로 전환하세요. 기준선 테스트가 통과한 뒤 원래의 분할 라우팅 규칙으로 되돌리면 됩니다.
브라우저 경로: 시스템 프록시가 실제로 읽히는지 확인하기
대부분의 데스크톱 브라우저는 기본적으로 운영체제의 프록시 설정을 읽지만, 브라우저 내부에 별도 프록시 정책이나 확장 프로그램 설정이 남아 있거나 이전 프로세스가 계속 실행 중일 수 있습니다. 시스템 프록시를 변경한 뒤 페이지를 새로 고치는 것만으로는 충분하지 않을 때가 있습니다. 브라우저를 완전히 종료하고 다시 열면 시작 시 읽은 설정이 남아 있는 문제를 배제할 수 있습니다.
테스트할 때는 일반 창을 사용하고 프록시 방식을 바꾸는 브라우저 확장 프로그램을 일시 중지한 뒤, 이전에 열어 본 적 없는 주소를 선택하세요. 일반 웹페이지는 열리지만 특정 도메인만 실패한다면 로컬 프록시 연결은 대체로 정상입니다. 다음으로 라우팅 규칙 적중 여부, DNS 확인과 원격 대상을 점검하고 시스템 프록시 스위치만 반복해서 바꾸지는 마세요.
| 관찰 결과 | 가능성이 높은 문제 위치 | 다음 조치 |
|---|---|---|
| 모든 웹페이지에서 즉시 연결 거부가 표시됨 | 로컬 포트가 수신 중이 아니거나 포트 입력이 잘못됨 | v2rayN 로컬 포트를 확인하고 코어 시작 로그를 점검하세요 |
| 페이지가 오래 기다린 뒤 시간 초과됨 | 노드 아웃바운드, 네트워크 연결 또는 라우팅 규칙 | 정상 작동이 확인된 노드로 전환하고 아웃바운드 시간 초과 기록을 확인하세요 |
| 한 브라우저는 되지만 다른 브라우저는 안 됨 | 브라우저 자체 프록시 설정 또는 백그라운드 프로세스 | “시스템 프록시 사용”을 선택하고 완전히 종료한 뒤 다시 여세요 |
| 도메인은 실패하지만 테스트 IP에 직접 접속하면 응답함 | DNS 조회 경로 또는 도메인 규칙 | 클라이언트 DNS 설정과 도메인 분할 라우팅 규칙을 확인하세요 |
| 브라우저는 되지만 터미널 명령은 직접 연결에 실패함 | 터미널 도구가 시스템 프록시를 읽지 않음 | 현재 터미널에 프록시 환경 변수를 설정하세요 |
결론: 브라우저 성공이 모든 프로그램을 프록시로 전환했다는 뜻은 아님
브라우저 테스트 통과는 “브라우저→시스템 프록시→로컬 인바운드→원격 아웃바운드” 경로가 작동한다는 것만 증명합니다. 터미널, 백그라운드 서비스와 네트워크 연결을 직접 관리하는 프로그램은 프록시 출처를 별도로 확인해야 합니다.
브라우저가 여전히 직접 연결할 때 확인할 사항
- 브라우저 네트워크 설정을 열고 수동으로 입력한 이전 주소가 아니라 “시스템 프록시 사용”이 선택되어 있는지 확인하세요.
- 시스템 프록시 주소가
127.0.0.1인지, 포트가 v2rayN의 현재 HTTP 포트와 일치하는지 확인하세요. - 프록시 설정을 덮어쓸 수 있는 확장 프로그램을 끈 다음 일반 창에서 다시 테스트하세요.
- 시스템 시간과 시간대가 정확한지 확인하세요. 시간 차이가 너무 크면 TLS 연결이 실패할 수 있으며, 이 현상이 프록시가 작동하지 않는 것으로 오해될 수 있습니다.
- v2rayN 실행 로그를 확인하세요. 웹페이지를 새로 고칠 때 새 연결 기록이 전혀 추가되지 않는다면 요청이 로컬 프록시로 들어오지 않은 경우가 많습니다.
터미널 경로: 환경 변수 또는 명시적 매개변수로 프록시 지정하기
명령줄 터미널은 프로그램을 실행하는 컨테이너일 뿐이며 모든 네트워크 연결을 자동으로 시스템 프록시로 전달하지 않습니다. 프록시 사용 여부는 실제 도구에 달려 있습니다. 어떤 도구는 HTTP_PROXY와 HTTPS_PROXY를 읽고, 어떤 도구는 명령줄 매개변수만 받으며, 또 어떤 도구는 자체 설정 파일에 값을 저장해야 합니다. 따라서 “브라우저는 열리는데 터미널은 시간 초과됨”은 보통 노드가 갑자기 고장 난 것이 아니라 두 프로그램이 서로 다른 네트워크 경로를 사용하기 때문입니다.
HTTP 프록시 환경 변수를 지원하는 도구라면 현재 터미널 세션에서 임시로 설정해 보세요. 대상이 HTTPS 사이트여도 프록시 주소의 프로토콜은 http://로 작성합니다. 도구가 HTTP 프록시를 통해 CONNECT 터널을 만들기 때문입니다. 아래에서는 10809를 예시로 사용하므로 실행 전에 화면에 표시된 실제 포트로 바꾸세요.
Windows PowerShell 임시 설정
$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
$env:NO_PROXY="localhost,127.0.0.1"이 세 줄은 현재 PowerShell 프로세스와 이후 실행되는 자식 프로세스에만 영향을 줍니다. 창을 닫으면 설정도 사라지므로 문제 해결에는 적합하지만 장기적인 사용에는 적합하지 않습니다. 현재 값은 $env:HTTPS_PROXY로 확인하고, 삭제할 때는 Remove-Item Env:HTTP_PROXY와 Remove-Item Env:HTTPS_PROXY를 사용하세요.
Windows 명령 프롬프트 임시 설정
set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809
set NO_PROXY=localhost,127.0.0.1macOS 및 Linux 현재 셸 임시 설정
export HTTP_PROXY="http://127.0.0.1:10809"
export HTTPS_PROXY="http://127.0.0.1:10809"
export NO_PROXY="localhost,127.0.0.1"도구가 SOCKS5를 지원한다면 명시적 매개변수로 10808 포트를 테스트할 수 있습니다. socks5h의 h는 대상 도메인 확인을 프록시 서버가 수행한다는 뜻입니다. “로컬 DNS 실패”와 “프록시 연결 실패”를 구분하는 데 유용합니다. 모든 프로그램이 ALL_PROXY를 읽는 것은 아니므로 첫 번째 확인에는 보통 명시적 매개변수가 더 적합합니다.
curl -v --proxy socks5h://127.0.0.1:10808 https://example.com/
curl -v --proxy http://127.0.0.1:10809 https://example.com/- 명시적 프록시 명령은 성공하지만 일반 명령은 실패한다면 도구가 시스템 프록시를 읽지 않는 것입니다. 명령 매개변수를 유지하거나 프록시 환경 변수를 설정하세요.
- HTTP 프록시는 성공하지만 SOCKS5는 실패한다면 SOCKS 포트와 로컬 인바운드 유형을 확인하세요. 두 포트를 서로 바꿔 입력하지 마세요.
- 두 종류의 명시적 프록시가 모두 실패한다면 v2rayN으로 돌아가 수신 상태, 활성 노드와 실행 로그를 확인하세요.
- 명령은 연결되지만 다운로드 중간에 끊긴다면 원격 연결 재설정, 노드 안정성과 대상 서비스 제한을 확인하세요. 로컬 포트만 점검해서는 안 됩니다.
실제 오류 메시지로 문제 계층을 좁히기
터미널의 상세 출력은 “접속할 수 없음”보다 훨씬 유용합니다. curl -v를 사용할 때 먼저 127.0.0.1의 예상 포트에 연결하는지 확인하고, 그다음 프록시가 대상 사이트와 터널을 성공적으로 설정했는지 확인하세요. 첫 단계부터 실패하면 로컬 문제이고, 로컬 연결에 성공한 뒤 시간 초과된다면 보통 문제는 라우팅이나 아웃바운드로 넘어간 것입니다.
오류: curl: (7) Failed to connect to 127.0.0.1 port 10809
원인 및 해결: 로컬 HTTP 포트가 수신 중이 아니거나 명령에 잘못된 포트를 사용했습니다. 「설정」→「매개변수 설정」에서 포트를 확인하고 v2rayN 코어가 정상적으로 시작되었는지 확인하세요.
오류: curl: (5) Could not resolve proxy: 127.0.0.1:10809
원인 및 해결: 프록시 변수 형식이 잘못되어 도구가 전체 값을 프록시 호스트 이름으로 처리했을 수 있습니다. 값을 http://127.0.0.1:10809로 작성하고 불필요한 따옴표, 공백 또는 중복된 프로토콜 접두사를 제거하세요.
오류: Proxy CONNECT aborted
원인 및 해결: HTTP 프록시가 요청을 받았지만 터널을 설정하지 못했습니다. 포트 유형을 SOCKS로 잘못 입력하지 않았는지 확인한 뒤 v2rayN의 아웃바운드 로그와 활성 노드를 점검하세요.
오류: connection refused
원인 및 해결: 대상 주소가 연결을 능동적으로 거부했습니다. 거부된 주소가 127.0.0.1이라면 로컬 수신 상태를 확인하고, 로그에 원격 서버의 거부가 표시된다면 노드 주소, 포트와 프로토콜 매개변수를 확인하세요.
오류: context deadline exceeded
원인 및 해결: 제한 시간 안에 요청이 완료되지 않았습니다. 먼저 정상 작동이 확인된 다른 노드로 전환한 다음 DNS, 네트워크 패킷 손실과 라우팅이 대상을 잘못 직접 연결 아웃바운드로 보내는지 차례로 확인하세요.
실행 로그는 어떤 순서로 확인해야 하나요?
- 인바운드: 테스트 명령을 실행할 때 로컬에서 새 연결이 들어온 기록이 있는지 확인합니다. 기록이 전혀 없다면 애플리케이션이 프록시를 사용하지 않았거나 포트를 잘못 입력한 것입니다.
- 라우팅: 대상 도메인이나 IP가 프록시, 직접 연결 또는 차단 아웃바운드 중 어디로 전송되었는지 확인합니다. 분할 라우팅 모드에서는 노드 지연 시간보다 규칙 적중 결과가 중요합니다.
- 아웃바운드: 연결 시간 초과, 연결 거부, 도메인 확인 실패 또는 인증 매개변수 오류가 발생했는지 확인합니다. 이 계층의 오류가 원격 노드와 직접 관련됩니다.
- 반환: 터널이 설정된 뒤 곧바로 재설정되는지 확인합니다. 특정 대상에서만 발생한다면 대상 서비스의 연결 정책도 고려해야 합니다.
브라우저는 되지만 일부 명령이 실패할 때: DNS와 분할 라우팅 확인
같은 도메인이라도 브라우저와 터미널에서 서로 다른 확인 경로를 사용할 수 있습니다. 브라우저는 자체 보안 DNS 설정을 사용할 수 있지만 터미널 도구는 보통 운영체제 확인기를 호출합니다. socks5://를 사용하면 로컬에서 먼저 확인할 수 있고, socks5h://를 사용하면 도메인 확인을 프록시 서버에 맡깁니다. 확인 위치가 다르면 얻는 주소와 라우팅 규칙 적중 결과도 달라질 수 있습니다.
분할 라우팅 규칙도 “어떤 프로그램은 되고 어떤 프로그램은 안 되는” 현상을 만들 수 있습니다. V2Ray 또는 Xray 코어는 도메인, IP, 포트와 인바운드 태그에 따라 아웃바운드를 선택합니다. 대상 도메인이 직접 연결 규칙에 포함되어 있으면 애플리케이션이 로컬 프록시에 연결했더라도 요청은 직접 연결 출구로 나갈 수 있습니다. 이때 시스템 프록시가 고장 난 것이 아니라 라우팅 판단을 수정해야 합니다.
- 먼저 테스트 대상을 안정적이고 접속 가능한 것으로 확인된 주소로 바꾸세요. 특정 사이트의 장애를 프록시 장애로 오인하는 일을 피할 수 있습니다.
socks5h://127.0.0.1:10808과http://127.0.0.1:10809를 각각 한 번씩 테스트해 로컬 DNS 경로에서만 실패하는지 비교하세요.- v2rayN 라우팅 설정에서 대상 도메인에 적중한 규칙을 확인하고, 비교를 위해 일시적으로 더 단순한 프록시 모드로 전환하세요.
- 사용자 지정 규칙을 활성화했을 때만 실패한다면 도메인 접미사, IP 대역과 규칙 순서를 하나씩 확인하세요. 앞쪽 규칙이 요청을 먼저 가로챌 수 있습니다.
- DNS 또는 라우팅을 변경한 뒤 코어를 재시작하고 새 터미널 창을 여세요. 이전 연결과 오래된 환경 변수가 결과에 영향을 주지 않도록 하기 위해서입니다.
결론: 요청이 로컬 인바운드로 들어왔는지 먼저 확인하기
실행 로그에 새 연결이 없다면 애플리케이션 프록시 설정을 확인하고, 인바운드는 있지만 사용 가능한 아웃바운드가 없다면 라우팅과 노드를 확인하세요. 이 기준으로 나누어 점검하면 노드를 계속 바꾸는 것보다 안정적인 결론을 얻기 쉽습니다.
자주 묻는 문제와 복구 방법
테스트가 끝나면 임시 변경 사항을 정리해 다음 실행 때 이전 변수, 이전 포트와 새 설정이 서로 덮어쓰지 않도록 하세요. 특히 환경 변수에 장기간 저장된 설정은 v2rayN을 종료한 뒤에도 명령줄 도구가 기존 로컬 포트에 계속 연결을 시도하게 만들어 지속적인 연결 거부로 이어질 수 있습니다.
시스템 프록시 스위치는 켜져 있는데 브라우저가 왜 계속 직접 연결하나요?
브라우저를 완전히 종료한 다음 브라우저 네트워크 설정에서 “시스템 프록시 사용”이 선택되어 있는지 확인하세요. 페이지를 새로 고치면서 v2rayN 로그도 함께 확인하세요. 새 인바운드 기록이 없다면 요청이 아직 로컬 프록시로 들어오지 않은 것입니다.
브라우저는 정상인데 curl은 왜 계속 시간 초과되나요?
먼저 --proxy http://127.0.0.1:10809를 포함한 명령을 실행하세요. 명시적 프록시가 성공한 뒤 현재 터미널에 HTTP_PROXY와 HTTPS_PROXY를 설정하면 됩니다.
HTTP 포트와 SOCKS 포트를 서로 바꿔 사용할 수 있나요?
사용할 수 없습니다. HTTP 클라이언트는 HTTP 인바운드에, SOCKS5 클라이언트는 SOCKS 인바운드에 연결해야 합니다. 예시 포트가 각각 10809와 10808이어도 입력할 때는 클라이언트의 실제 설정을 기준으로 하세요.
v2rayN을 종료한 뒤 터미널에서 인터넷이 되지 않으면 어떻게 하나요?
현재 세션이나 시스템에 저장된 프록시 환경 변수를 삭제한 다음 새 터미널을 여세요. 도구에 별도 프록시 설정이 있다면 127.0.0.1의 이전 포트를 가리키는 항목도 삭제해야 합니다.
특정 도메인 하나만 열리지 않는데 클라이언트를 다시 설치해야 하나요?
대부분 그럴 필요는 없습니다. 먼저 해당 도메인의 DNS 결과와 라우팅 적중 여부를 확인한 뒤 단순 프록시 모드와 비교하세요. 다른 대상이 정상이라면 로컬 수신과 기본 프록시 경로는 대체로 작동하고 있는 것입니다.
점검 후 마무리 체크리스트
- 임시로 전환했던 전역 프록시 모드를 원래의 라우팅 분할 설정으로 되돌리세요.
- 테스트에만 사용한
HTTP_PROXY,HTTPS_PROXY또는ALL_PROXY환경 변수를 삭제하세요. - 시스템 프록시 포트가 v2rayN의 현재 로컬 HTTP 포트와 여전히 일치하는지 확인하세요.
- 정상 노드, 포트 번호, 테스트 명령과 주요 오류 메시지를 텍스트로 기록해 두세요. 다음에는 실패한 계층부터 바로 점검할 수 있습니다.
- 노드를 바꾼 뒤 복구되었다면 잠시 더 관찰해 일시적인 네트워크 불안정과 노드 설정 오류를 구분하세요.