v2rayN 연결은 되는데 웹페이지가 열리지 않을 때: macOS·Windows 문제 해결

노드 선택과 요청 연결은 별개입니다

v2rayN에서 서버를 선택했다고 해서 브라우저 트래픽까지 프록시를 거치는 것은 아닙니다. 노드 목록의 지연 시간은 특정 시점의 검사 결과일 뿐, 현재 사이트의 DNS 조회와 TLS 핸드셰이크, 페이지 리소스 로딩까지 보장하지 않습니다. 문제를 확인할 때는 중복 실행 중인 프록시 클라이언트를 종료하고 TUN은 끈 상태로 시스템 프록시만 사용하세요.

현재 노드, 시스템 프록시 상태, 라우팅 모드, 로컬 수신 포트를 기록해 두세요. 클라이언트 로그를 열고 고정된 주소에 한 번 접속합니다. 관련 연결 기록이 전혀 없다면 먼저 진입점을 확인하고, 대상 도메인이나 원격 연결 오류가 표시되면 그다음 경로를 점검하세요. 로그 상세 수준에 따라 기록 내용이 달라지므로 빈 기록 하나만으로 브라우저 요청이 없었다고 단정할 수는 없습니다.

• 모든 사이트가 열리지 않음: 로컬 수신 포트와 시스템 프록시부터 확인하세요. 특히 포트를 변경했거나 클라이언트를 종료한 뒤라면 먼저 점검해야 합니다.
• 일부 사이트만 열리지 않음: 도메인을 기록하고 라우팅 규칙 적용 여부, DNS 결과, 사이트 자체 상태를 비교하세요.
• 브라우저는 되지만 다른 앱은 안 됨: 해당 앱이 시스템 프록시를 따르는지 확인하세요. 노드 문제라고 바로 단정하지 마세요.

1단계: 시스템 프록시가 현재 포트를 가리키는지 확인

v2rayN 기본 화면이나 트레이 메뉴에서 「시스템 프록시」를 열고 「시스템 프록시 자동 설정」을 선택하세요. 「시스템 프록시 지우기」는 관련 진입점을 제거하고, 「시스템 프록시 변경 안 함」은 현재 설정을 유지합니다. 따라서 프록시가 켜져 있다는 뜻은 아닙니다. 버전에 따라 메뉴 위치가 다를 수 있으니 아이콘 색상만 보지 말고 메뉴 이름을 확인하세요.

로컬 프록시 주소에는 보통 127.0.0.1을 입력하며, 포트는 현재 클라이언트 설정에서 확인해야 합니다. 「설정」→「매개변수 설정」을 열어 로컬 수신 포트와 프로토콜 유형을 확인하세요. 서비스 제공업체 노드의 원격 포트를 시스템 프록시에 입력하지 마세요. SOCKS 전용 포트를 HTTP 프록시 항목에 넣어서도 안 됩니다.

2단계: 로컬 포트가 실제로 수신 중인지 확인

아래에서는 10808을 예시로 확인하지만, 모든 버전에 적용되는 고정값은 아닙니다. 클라이언트에서 해당 포트를 HTTP 또는 혼합 수신 포트로 지정한 경우에만 아래 HTTP 프록시 테스트를 실행하세요. 설정값이 다르면 명령의 포트를 실제 값으로 바꾸면 됩니다.

macOS 터미널에서 확인

lsof -nP -iTCP:10808 -sTCP:LISTEN
curl -I --max-time 15 --proxy http://127.0.0.1:10808 https://example.com/

Windows PowerShell에서 확인

Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

curl.exe -I --max-time 15 --proxy http://127.0.0.1:10808 https://example.com/

Windows에서는 curl.exe를 명시해 사용하세요. 이전 버전의 PowerShell에서는 curl이 다른 명령으로 처리될 수 있습니다. 수신 중인 프로세스를 찾으면 프로세스 ID를 기준으로 「작업 관리자」에서 이름을 확인하세요. macOS에서는 lsof 출력에 표시된 프로세스를 확인합니다. 다른 프로세스가 포트를 사용 중이면 용도를 먼저 파악한 뒤 중복 클라이언트를 종료하거나 수신 포트를 변경하세요. 정체를 모르는 시스템 프로세스를 바로 종료하지 마세요.

3단계: 라우팅 규칙을 확인하고 전역 모드를 만능 해결책으로 여기지 않기

시스템 프록시는 요청을 먼저 어디로 보낼지 결정하고, 라우팅 규칙은 그 요청을 직접 연결할지, 프록시로 보낼지, 차단할지 결정합니다. “중국 본토 사이트는 열리는데 그 외 사이트는 안 열림”은 직접 연결되는 사이트만 정상일 가능성이 있습니다. 특정 도메인만 계속 열리지 않는다면 의도치 않게 직접 연결이나 차단 규칙이 적용됐는지 확인하세요.

1. 현재 라우팅 모드를 기록하고 직접 추가한 규칙을 백업하세요.
2. v2rayN의 「라우팅」 메뉴에서 현재 선택 항목을 확인하세요. 규칙을 살펴보려면 「설정」에서 라우팅 설정으로 이동합니다. 메뉴 이름은 설치된 버전에 따라 다를 수 있습니다.
3. 대상 요청을 프록시로 보내는 전역 라우팅 모드를 잠시 선택하고 노드와 테스트 주소는 그대로 유지하세요.
4. 접속이 복구되면 원래 모드로 돌아가 대상 도메인, 도메인 접미사 규칙, 규칙 순서를 확인한 뒤 수정하고 다시 테스트하세요.

전역 라우팅도 클라이언트에 들어온 요청만 처리합니다. 시스템 프록시를 무시하는 앱이 자동으로 연결되는 것은 아닙니다. 모든 규칙을 한꺼번에 삭제하지 마세요. 사내망 주소나 회사 서비스, 로컬 장치가 직접 연결을 필요로 할 수 있습니다. 재현 가능한 결과를 얻으려면 장애가 발생한 도메인과 관련된 규칙만 한 번에 하나씩 바꾸세요.

4단계: DNS 오류가 발생한 위치 구분

DNS 오류는 크게 두 가지입니다. 노드 서버 주소를 확인할 수 없는 경우와 대상 웹사이트 도메인을 확인할 수 없는 경우입니다. 전자는 프록시의 외부 연결 자체를 실패하게 만들고, 후자는 일부 사이트에만 영향을 줄 수 있습니다. 먼저 로그에서 오류가 발생한 도메인을 찾은 뒤 시스템 DNS, 커널 DNS, 브라우저 보안 DNS 중 어디를 점검할지 판단하세요.

macOS에서는 아래 명령으로 시스템이 현재 사용하는 DNS 조회 결과를 확인할 수 있습니다. 이 결과는 시스템 DNS 경로만 보여 주며, 커널 DNS나 프록시 측 DNS 조회를 대신 확인해 주지는 않습니다.

dscacheutil -q host -a name example.com

Windows PowerShell에서도 같은 도메인을 조회할 수 있습니다. 시스템 DNS를 수정한 뒤 이전 캐시를 지워야 한다면 두 번째 명령을 실행하세요. 권한이 필요한 경우 시스템 안내에 따르세요.

Resolve-DnsName example.com
ipconfig /flushdns

• 특정 브라우저에서만 실패: 「보안 DNS」 또는 「HTTPS를 통한 DNS 사용」을 잠시 끄고 비교 테스트하세요. 테스트가 끝난 뒤 설정을 유지할지 결정하면 됩니다.
• SOCKS 테스트 사용: socks5://와 socks5h://는 도메인을 조회하는 위치가 다릅니다. curl의 socks5h://는 대상 도메인 조회를 프록시에 맡깁니다.
• DNS를 바꿔도 계속 실패: DNS 요청 자체의 라우팅을 확인하세요. 아직 연결되지 않은 프록시를 거쳐야만 사용할 수 있는 DNS 서버를 지정하면 의존성 문제가 생길 수 있습니다.

5단계: 노드 설정과 시스템 시간 확인

로컬 진입점이 정상이고 라우팅도 프록시를 통과하는 것을 확인한 다음 노드를 테스트하세요. 같은 구독에서 정상 작동이 확인된 다른 노드 하나로 바꾸고 브라우저, 주소, 라우팅 모드는 그대로 유지합니다. 노드 하나만 실패하면 해당 노드의 서비스 상태와 설정을 확인하세요. 모든 노드가 실패한다면 현재 네트워크의 제한, 구독 만료, 커널의 정상 시작 여부도 살펴봐야 합니다.

macOS에서는 「시스템 설정」→「일반」→「날짜 및 시간」으로 이동해 자동 설정을 확인하세요. Windows에서는 「설정」→「시간 및 언어」→「날짜 및 시간」에서 「시간 자동 설정」을 켜고, 필요하면 「지금 동기화」를 선택합니다. 시계가 크게 어긋나면 TLS 인증서 유효성 확인이나 일부 인증 과정에 영향을 줄 수 있지만, 모든 시간 초과의 원인은 아닙니다.

재테스트 결과에 따라 남은 문제 해결

위 단계를 마친 뒤 기존 주소로 다시 테스트하고 변경 사항과 결과를 기록하세요. 도움을 요청할 때는 운영체제, 클라이언트 버전, 사용 중인 커널, 오류 발생 시각, 민감 정보를 가린 로그를 제공하세요. 구독 링크, 사용자 ID, 비밀번호, 전체 노드 설정이 공개 스크린샷에 포함되지 않도록 주의하세요.