v2rayN 연결됨으로 표시되지만 웹사이트가 열리지 않을 때: 시스템 프록시·포트·라우팅 점검

이 글의 핵심

코어가 실행되고 서버도 선택했지만 브라우저에서 시간 초과가 발생하거나 프록시 연결 오류가 표시되는 데스크톱 사용자에게 적합합니다. 먼저 프록시를 명시한 요청으로 앱이 프록시에 연결되는지와 프록시가 요청을 처리하는지를 따로 확인한 뒤, 수신 포트, 시스템 시간, 라우팅, 서버 설정을 점검합니다. 아래에서는 Windows를 예로 들며, 포트는 클라이언트 화면에 표시된 실제 값을 사용합니다. 한 번에 한 항목만 바꾸고 결과를 기록하세요.

1. ‘연결됨’이 웹페이지 접속 성공을 뜻하지는 않습니다

v2rayN의 실행 상태, 서버 지연 시간 측정 결과, 웹페이지 접속 가능 여부는 서로 다른 단계입니다. 코어 프로세스가 실행 중이라는 것은 프로그램이 동작한다는 뜻일 뿐입니다. TCP 지연 시간이 측정되더라도 대개 원격 포트에 연결할 수 있다는 의미입니다. 인증, 전송 계층 핸드셰이크, DNS 조회, 대상 웹사이트 접속은 여전히 실패할 수 있습니다. 지연 시간 테스트를 반복해서 누르기보다 실제 요청 결과를 확인하세요.

127.0.0.1

로컬 프록시 수신 주소

10808

아래 예시에서 사용하는 로컬 프록시 포트

443

HTTPS에서 흔히 사용하는 대상 포트이며, 서버의 고정 포트는 아닙니다

최신 설정은 HTTP와 SOCKS를 모두 받는 혼합 포트를 사용할 수 있고, 기존 설정은 두 프로토콜의 인바운드를 분리할 수도 있습니다. 10808은 모든 설치 환경에 적용되는 고정값이 아닙니다. 화면에 HTTP 포트가 10809로 표시된다면 HTTP 테스트에는 해당 포트를 사용하세요. 서버 포트는 서버 측 설정에 따라 다르므로 예시와 맞추려고 443으로 바꾸지 마세요.

먼저 프록시를 끈 상태에서 일반적으로 직접 접속할 수 있는 웹사이트가 열리는지 확인합니다.
현재 서버, 라우팅 모드, 로컬 포트, 문제가 발생한 시각을 기록합니다.
일단 트래픽을 가로채는 방식을 하나만 사용합니다. 시스템 프록시를 점검할 때는 경로가 서로 간섭하지 않도록 TUN을 끄세요.
클라이언트 로그를 연 다음 요청을 한 번 보내고, 같은 시간대에 기록된 오류를 확인합니다.

2. 시스템 프록시: 브라우저 요청의 전달 위치 확인

시스템 프록시는 앱이 요청을 로컬 포트로 전달할지 결정하고, 라우팅 모드는 요청이 코어에 들어온 뒤 어떤 아웃바운드를 선택할지 결정합니다. 두 기능은 서로 대체할 수 없습니다. 프록시 서버를 선택해도 시스템 프록시를 설정하지 않으면 시스템 설정을 따르는 브라우저가 직접 연결할 수 있습니다. 반대로 시스템 프록시가 중지된 포트를 가리키면 평소 잘 열리던 웹사이트도 접속되지 않을 수 있습니다.

인바운드 설정 확인

v2rayN에서 ‘설정’ → ‘매개변수 설정’을 열고 로컬 수신 주소, 포트, 인바운드 프로토콜을 확인합니다. 버전에 따라 메뉴 이름과 구성이 다를 수 있으므로 실제 값을 기록하고 오래된 가이드에 나온 포트를 추측해 사용하지 마세요.
시스템 프록시 설정

메인 화면이나 트레이 메뉴의 ‘시스템 프록시’에서 ‘시스템 프록시 자동 구성’을 선택합니다. 이 옵션은 시스템 프록시 설정을 기록한다는 뜻입니다. 모든 버전에서 PAC를 활성화하는 것은 아니며, 모든 앱의 트래픽을 가로채는 것도 아닙니다.
시스템 설정값 확인

Windows에서 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’로 이동해 현재 수동 프록시와 설정 스크립트를 확인합니다. 수동 프록시 주소는 로컬 수신 설정과 일치해야 합니다. HTTP 프록시가 SOCKS만 지원하는 포트를 가리키면 안 됩니다.
브라우저 설정 덮어쓰기 확인

프록시 전환 확장 프로그램을 잠시 끄고 브라우저 자체 프록시 설정을 확인한 뒤, 브라우저를 닫았다가 다시 열어 페이지를 테스트합니다. 시스템 프록시 값이 계속 바뀐다면 프록시 설정을 변경할 수 있는 다른 프로그램을 먼저 종료하세요.

명령줄 도구는 Windows 시스템 프록시 설정을 따르지 않을 수 있습니다. 터미널 요청의 성공이나 실패만으로 브라우저 설정이 올바르다고 판단할 수는 없습니다. 아래에서 --proxy 옵션을 명시하는 이유는 이 차이를 우회하고 로컬 인바운드와 이후 연결을 따로 확인하기 위해서입니다.

3. 로컬 포트: 프록시 진입과 외부 연결을 따로 확인

PowerShell에서 아래 명령을 실행합니다. 일부 환경에서는 curl이 다른 명령으로 처리될 수 있으므로 curl.exe를 명시합니다. 첫 번째 명령은 HTTP 또는 혼합 인바운드에, 두 번째 명령은 SOCKS 또는 혼합 인바운드에 사용합니다. 현재 인바운드 유형에 맞는 명령만 실행하세요. 두 명령이 모두 성공할 필요는 없습니다.

curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

socks5h는 대상 도메인 조회를 SOCKS 측에 맡기므로 이 PC의 DNS 조회 경로와 비교할 때 유용합니다. 다만 이것만으로 원격 DNS가 반드시 사용된다고 단정할 수는 없습니다. HTTP 테스트에서 200 Connection established만 표시된다면 TLS와 대상 사이트 응답도 확인해야 합니다. 프록시 터널을 연 중간 응답을 웹페이지 요청 완료로 오해하지 마세요.

확인된 결과	우선 점검 항목	다음 단계
로컬 연결이 즉시 거부됨	수신 포트, 코어 상태	포트를 확인하고 수신 프로세스를 점검합니다
로컬 연결 후 계속 시간 초과	서버, 핸드셰이크, DNS, 라우팅	같은 시각의 코어 로그를 대조합니다
대상 사이트의 HTTP 응답을 받음	브라우저의 프록시 경로	확장 프로그램, 시스템 프록시, 캐시 확인
403 또는 451 응답	사이트 접속 정책	다른 테스트 사이트를 사용하세요. 이 결과만으로 서버가 작동하지 않는다고 판단할 수 없습니다

결론: 프록시를 명시한 요청이 성공하면 앱의 프록시 진입 경로부터 점검

같은 대상에 프록시를 명시한 요청은 성공하지만 브라우저에서 실패한다면 브라우저와 시스템 프록시 설정부터 바로잡으세요. 이 경우 구독을 초기화하거나 코어 전체를 바꾸는 것은 우선 조치가 아닙니다.

포트 사용 중 오류가 표시되면 아래 명령으로 수신 중인 프로세스를 확인합니다. 로컬 주소 열과 LISTENING 상태를 확인하세요. 마지막 열은 PID입니다. 그런 다음 ‘작업 관리자’ → ‘세부 정보’에서 프로세스를 확인합니다. PID만 보고 정체를 모르는 시스템 프로세스를 강제 종료하지 마세요.

netstat -ano | findstr ":10808"

이전 코어 프로세스가 남아 있다면 해당 클라이언트를 정상 종료한 뒤 다시 시작합니다. 로컬 포트를 바꾸려면 시스템 프록시와 앱의 수동 프록시 설정도 함께 수정해야 합니다. 한쪽만 바꾸면 포트 충돌이 연결 거부 문제로 바뀔 수 있습니다. 개인 PC에서 사용할 때는 보통 127.0.0.1로 수신하도록 설정하면 되며, 로컬 네트워크에 공개할 필요는 없습니다.

4. 시간과 핸드셰이크: 로그로 인증·전송 오류 구분

시스템 시간이 어긋나면 VMess 인증에 영향을 주거나 TLS 인증서가 아직 유효하지 않거나 이미 만료된 것으로 판단될 수 있습니다. Windows에서 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’으로 이동해 자동으로 시간 설정을 켜고 ‘지금 동기화’를 누르세요. 날짜와 시간대도 확인합니다. 시계가 얼핏 맞아 보이는지가 아니라 실제 시간이 정확한지가 중요합니다.

오류: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.

원인: Windows에서 흔히 발생하는 수신 주소 또는 포트 충돌입니다. 실제 로그에는 주소 접두사가 함께 표시될 수 있습니다.

해결: netstat로 PID를 확인하고 중복 프로세스를 종료하거나, 로컬 포트를 변경한 뒤 시스템 프록시 설정도 함께 수정합니다.

오류: x509: certificate has expired or is not yet valid

원인: 시스템 시간이 정확하지 않거나 서버 인증서의 유효 기간에 문제가 있을 수 있습니다. 이 한 줄만으로 어느 쪽 문제인지 판단할 수는 없습니다.

해결: 먼저 PC 시간을 동기화하세요. 오류가 계속되면 서비스 제공업체에 인증서를 확인해 달라고 요청하세요. 인증서 검증을 건너뛰는 방식으로 해결하지 마세요.

오류: dial tcp: lookup …: no such host

원인: 도메인 조회 실패 시 자주 나타나는 로그 형식입니다. 생략된 부분에는 실제 도메인이 표시되며, 서버 주소일 수도 대상 사이트 주소일 수도 있습니다.

해결: 먼저 조회에 실패한 도메인이 무엇인지 확인한 뒤 철자, 시스템 DNS 조회, 코어의 DNS 경로를 점검하세요. 모든 DNS 설정을 무작정 변경하지 마세요.

오류: context deadline exceeded

원인: 특정 작업이 제한 시간 안에 완료되지 않았다는 뜻입니다. 이 한 줄만으로 서버가 작동하지 않는다고 단정할 수는 없습니다.

해결: 앞뒤 로그를 살펴보고 DNS 조회, 원격 연결, 대상 사이트 접속 중 어느 단계에서 시간 초과가 발생했는지 확인한 뒤 해당 단계에 맞는 테스트를 진행하세요.

VLESS, VMess 또는 Trojan을 사용하는 경우 서버를 가져온 뒤에도 주소, 포트, 인증 정보, 전송 설정을 확인해야 합니다. TLS의 serverName, WebSocket 경로, gRPC의 serviceName은 서버 설정과 일치해야 합니다. REALITY는 서버에서 제공한 공개 키와 shortId 등의 매개변수도 맞아야 합니다. 프로토콜을 바꾸는 것을 만능 해결책으로 여기지 마세요. 클라이언트 코어도 해당 설정을 지원해야 합니다.

5. 라우팅과 DNS: 요청이 잘못된 아웃바운드를 선택하는지 확인

로그에서 요청이 코어에 들어오는 것이 확인되는데 일부 도메인만 접속되지 않는다면 분할 라우팅을 점검하세요. V2Ray/Xray의 routing.rules는 순서대로 일치 여부를 확인하고, 규칙이 적용되면 해당 아웃바운드를 선택합니다. outboundTag는 실제로 존재하는 outbounds[].tag를 참조해야 합니다. 어떤 규칙에도 해당하지 않을 때 사용하는 기본 아웃바운드도 확인하세요. 기본적으로 프록시를 거친다고 가정하면 안 됩니다.

먼저 라우팅을 비교하세요: 현재 모드를 기록한 다음, 일반 대상 요청이 프록시를 거치도록 하는 라우팅 모드를 잠시 선택해 같은 주소를 테스트하고 원래 설정으로 되돌립니다. v2rayN의 라우팅 모드와 시스템 프록시 메뉴는 서로 다른 설정입니다.
차단 규칙도 확인하세요: 일반 웹사이트는 열리지만 특정 도메인만 실패한다면 해당 도메인이 직접 연결 또는 차단 규칙에 해당하는지 확인합니다. 특히 범위가 넓은 도메인 규칙과 IP 규칙의 순서를 살펴보세요.
조회 대상 구분: 서버 주소가 도메인으로 설정된 경우 서버에 연결하기 전에 도메인을 조회할 경로가 필요합니다. 대상 웹사이트의 DNS만 조정해서는 서버 도메인 조회 실패를 해결하지 못할 수 있습니다.
설정 항목의 역할 파악: routing.domainStrategy는 라우팅 규칙에서 도메인을 조회하는 방식을 제어합니다. 앱의 트래픽 가로채기 설정이 아니며, 이 항목만으로 모든 DNS 요청이 외부로 나가지 않는다고 보장할 수도 없습니다.
접속 기록 보관: 로그에서 대상 주소와 아웃바운드 tag를 잠시 확인합니다. GUI가 설정 파일을 자동 생성한다면 해당 라우팅 설정을 수정하세요. 임시 생성 파일을 직접 편집하면 변경 사항이 덮어써질 수 있습니다.

브라우저의 보안 DNS, 시스템 DNS, 코어 DNS는 서로 다른 경로를 사용할 수 있습니다. nslookup으로 시스템에서 사용하는 DNS 리졸버를 확인할 수 있지만, 프록시 내부 DNS가 정상이라는 증거가 되지는 않습니다. 또한 이것만으로 브라우저의 모든 DNS 요청이 어디로 전달되는지 판단할 수도 없습니다. 브라우저에서만 문제가 발생한다면 브라우저의 보안 DNS 설정을 잠시 바꿔 비교한 뒤 테스트가 끝나면 원래 설정으로 되돌리세요.

6. 서버 상태: 포트 연결과 프로토콜 사용 가능 여부 구분

로컬 수신이 정상인데 프록시를 명시한 요청도 실패한다면 그다음 원격 연결을 확인합니다. PowerShell의 포트 테스트는 TCP 연결만 확인할 뿐 VMess, VLESS, Trojan의 인증이나 전송 매개변수는 검증하지 않습니다. 따라서 TcpTestSucceeded: True는 문제 범위를 좁히는 데만 도움이 되며 실제 웹페이지 요청을 대신할 수 없습니다.

$nodeHost = Read-Host "현재 서버 주소 입력"
$nodePort = [int](Read-Host "현재 서버 포트 입력")
Test-NetConnection -ComputerName $nodeHost -Port $nodePort

설정 출처 확인: 구독을 갱신했는지, 계정이 만료되었는지, 사용량 한도를 초과했는지 확인하세요. 구독 링크, UUID, 비밀번호, 전체 설정을 모르는 사람에게 보내지 마세요.
정상 작동이 확인된 다른 서버로 변경: 로컬 포트와 라우팅 설정은 그대로 두고 같은 주소를 다시 테스트합니다. 특정 서버만 실패한다면 해당 서버의 매개변수와 서비스 상태부터 확인하세요.
네트워크 변경: 현재 네트워크와 휴대폰 핫스팟을 비교합니다. 핫스팟에서는 되지만 기존 네트워크에서 실패한다면 기존 네트워크의 외부 연결 제한, DNS, 방화벽 정책을 중점적으로 확인하세요.
차단 기록 확인: 보안 프로그램이 클라이언트 화면은 허용하면서 코어 프로세스의 네트워크 연결은 차단할 수 있습니다. 프로그램 경로와 로그를 확인한 뒤 필요한 항목만 허용하세요. 방화벽을 계속 꺼 두는 것은 해결 방법이 아닙니다.

모든 서버에서 동시에 문제가 발생하고 로그에 코어를 시작할 수 없다고 표시된다면 구독을 계속 새로고침하기보다 설정 구문 오류나 코어 호환성 문제부터 해결하세요. 업그레이드 전 설정을 백업하고, 업그레이드 후에는 현재 선택한 코어가 서버 프로토콜을 지원하는지 확인합니다. 소프트웨어 업그레이드로 원격 인증서, 계정 사용량, 서버 매개변수 오류를 해결할 수는 없습니다.

7. 자주 묻는 질문과 복구 후 확인 사항

지연 시간은 측정되는데 웹페이지는 왜 시간 초과가 발생하나요?

TCP 테스트만으로 프로토콜 인증이나 대상 사이트 접속까지 완료되는 것은 아닙니다. 먼저 이 글의 프록시 명시 요청을 실행한 뒤 같은 시각의 로그를 확인해 로컬 연결, 원격 핸드셰이크, 대상 사이트 응답을 각각 점검하세요. 지연 시간 수치만으로 사용 가능 여부를 판단하지 마세요.

브라우저만 인터넷에 접속되고 다른 프로그램은 여전히 안 되나요?

일부 프로그램은 시스템 프록시를 사용하지 않습니다. 해당 프로그램의 네트워크 설정을 확인하세요. HTTP나 SOCKS를 지원한다면 실제 수신 주소와 해당 포트를 입력합니다. TUN이 필요한지 검토한 뒤 별도로 활성화하고 라우팅과 DNS를 다시 확인하세요. 시스템 프록시가 모든 트래픽을 가로챈다고 생각하면 안 됩니다.

v2rayN을 종료한 뒤 일반 웹페이지도 열리지 않나요?

클라이언트를 다시 실행한 뒤 ‘시스템 프록시’에서 ‘시스템 프록시 지우기’를 선택합니다. 그런 다음 Windows의 ‘네트워크 및 인터넷’ → ‘프록시’에서 설정이 여전히 PC의 이전 포트를 가리키는지 확인하세요. 조직에서 관리하는 기기라면 조직에서 요구하는 설정을 유지하고 관리자에게 문의하세요.

재부팅한 뒤 다시 문제가 생겼는데 재설치해야 하나요?

먼저 시작 순서, 포트 사용 여부, 다른 프로그램이 시스템 프록시 설정을 덮어썼는지 확인하세요. 문제가 재현되면 수신 PID와 로그를 기록해 코어가 실행되지 않는 것인지 브라우저의 프록시 진입 경로가 작동하지 않는 것인지 구분합니다. 원인을 찾기 전에 재설치하면 정상 설정만 잃을 수 있습니다.

접속이 복구되면 문제 해결을 위해 임시로 추가한 전역 라우팅과 디버그 설정을 되돌리고 필요한 시스템 프록시 모드만 유지하세요. 평소 직접 접속하는 사이트 하나, 프록시가 필요한 사이트 하나, 이전에 실패했던 앱을 각각 다시 테스트합니다. 세 항목이 예상대로 작동하는지 확인한 뒤 효과가 있었던 변경 사항을 기록하세요.

문제 제보 시 포함할 항목: 클라이언트 버전, 코어 버전, 운영체제 버전, 실제 로컬 포트, 라우팅 모드, 테스트 시각.
로그 공유 범위: 오류가 발생하기 전후의 관련 줄만 추려내세요. 공개하기 전에 구독 주소, 인증 정보, 공개하고 싶지 않은 서버 정보를 가립니다.
설정 항목 더 살펴보기: 인바운드, 아웃바운드, 라우팅의 연결 관계는 JSON 설정 매뉴얼에서 확인할 수 있습니다. 기본 설정 방법은 사용 가이드를 참고하세요.