V2Ray 문제 해결 가이드

서버 응답 시간 초과: 포트·핸드셰이크·대상 사이트 구분

시간 초과는 제한 시간 안에 예상한 응답을 받지 못했다는 뜻이지, 어느 단계에서 멈췄는지는 알려주지 않습니다. 서버 포트 연결, 암호화 전송 설정, 인증, 서버에서 대상 사이트로의 연결 중 어느 단계에서든 시간 초과가 발생할 수 있습니다. 실행 로그에서 이번 요청과 관련된 첫 오류를 찾으세요. 마지막 줄의 ‘실패’만 확인하지 말고, 오류 전에 연결이 성립했는지와 특정 대상이나 네트워크에서만 문제가 발생하는지도 기록합니다.

먼저 서버의 접속 주소에 연결할 수 있는지 확인

사용 중인 서버의 편집 화면을 열어 제공자가 안내한 주소와 포트를 비교하세요. 주소를 복사할 때 앞뒤 공백을 제거하고, 서버 주소 칸에 전체 웹 주소나 구독 URL을 넣지 마세요. 도메인과 포트는 각각 입력해야 합니다. 최근 구독 내용이 바뀌었다면 해당 그룹을 업데이트한 뒤 유효한 항목을 다시 선택하세요. 이전 항목을 직접 수정해도 다음 구독 업데이트 후에는 변경 사항이 유지되지 않을 수 있습니다.

Windows에서는 아래 명령으로 서버의 TCP 포트에 연결되는지 확인할 수 있습니다. 예시 도메인은 명령어 형식을 보여주기 위한 것이므로 실행할 때 실제 서버 주소와 포트로 바꾸세요. 바꾼 명령은 공개적으로 공유하지 마세요. 테스트가 실패하면 이 컴퓨터에서 해당 TCP 포트까지 연결이 성립하지 않은 것입니다. 성공하더라도 포트에 연결할 수 있다는 뜻일 뿐, 프로토콜·사용자 ID·전송 설정이 올바르다는 보장은 없습니다. 다른 전송 방식을 사용하는 설정이라면 이 테스트만으로 전체 연결을 검증할 수 없습니다.

Test-NetConnection -ComputerName server.example.com -Port 443

여러 서버가 동일한 네트워크에서만 실패한다면 신뢰할 수 있는 다른 네트워크에서 같은 설정을 시험하세요. 네트워크와 서버를 동시에 바꾸면 원인을 구분할 수 없습니다. 특정 서버만 모든 네트워크에서 실패하고 다른 서버는 정상이라면 설정 제공자에게 서버 상태를 문의하세요. 테스트 간격을 계속 줄인다고 시간 초과에서 더 많은 정보를 얻을 수 있는 것은 아닙니다. 연결 제한을 유발할 수 있으니 적당한 간격을 두고 다시 시험하세요.

포트 연결 후 전송 및 보안 설정 확인

TCP 포트는 연결되지만 로그에 핸드셰이크 오류가 나타난다면 프로토콜, 전송 방식, TLS 설정, 서버 이름을 하나씩 비교하세요. WebSocket의 경로와 Host, gRPC 서비스 이름, REALITY 공개 키와 짧은 ID는 서버 설정과 일치해야 합니다. 포트가 같다고 설정을 서로 바꿔 쓸 수 있는 것은 아닙니다. 경로의 대소문자와 앞에 붙는 슬래시도 영향을 줄 수 있으므로 필드를 추측해 입력하기보다 연결 정보를 통째로 다시 가져오는 편이 안전합니다.

기기 시간이 맞지 않으면 인증서 유효기간 확인이나 일부 인증 절차에 영향을 줄 수 있습니다. 시스템 자동 시간 설정을 켠 뒤 로그에서 인증서 이름, 유효기간, 인증서 체인 관련 메시지를 확인하세요. 일상적인 해결책으로 ‘인증서 검증 건너뛰기’를 사용하지 마세요. 필요한 오류를 감출 뿐 서버 이름 설정 문제를 해결하지도 못합니다. 서버 인증서 자체에 문제가 있다면 서버 관리자가 수정해야 하며, 클라이언트에는 올바른 연결 매개변수를 입력해야 합니다.

오류 메시지별 점검 방향

이 키워드만으로 원인을 단정할 수는 없습니다. 읽기·쓰기 시간 초과는 대상 사이트 쪽에서 발생할 수 있고, 연결 조기 종료는 중간 네트워크 장비가 원인일 수도 있습니다. 앞뒤 로그와 비교 테스트를 함께 확인하세요. 서버 연결은 성립한 뒤 특정 사이트 하나만 실패한다면 해당 사이트의 라우팅과 서버 측 접속 조건을 확인하세요. 한 번의 대상 사이트 오류만으로 서버 전체가 고장 났다고 판단하지 마세요.

클라이언트 목록의 지연 시간 테스트는 대상과 연결 방식이 다를 수 있습니다. 포트 테스트는 성공하지만 실제 연결 테스트가 실패한다면 프로토콜 이후의 연결 경로를 더 확인해야 할 수 있습니다. 자세한 내용은 서버 지연 시간과 다운로드 속도 측정 안내를 참고하세요. 관리 담당자에게 문의할 때는 발생 시각, 프로토콜 종류, 오류 단계, 네트워크 비교 결과를 전달하되 전체 인증 정보는 보내지 마세요. 필요한 답변을 받는 데 도움이 됩니다.

DNS 문제: 조회 주체와 요청 경로 확인

DNS 문제는 도메인이 열리지 않거나 첫 페이지 로딩이 오래 걸리거나 같은 대상에 앱마다 다른 결과가 나오는 형태로 나타날 수 있습니다. 브라우저에 DNS 오류가 보인다고 모든 DNS 주소를 바로 바꾸지 마세요. 한 번의 요청에도 운영체제 캐시, 브라우저 보안 DNS, 프록시 코어의 조회, 원격 서버의 조회가 관여할 수 있습니다. 먼저 해당 요청이 실제로 어느 단계에서 이름을 조회하는지 확인한 뒤 필요한 설정만 바꾸세요. 그렇지 않으면 새 설정을 앱이 사용하지 않을 수도 있습니다.

시스템 DNS 조회 결과만으로 프록시 연결 전체를 판단할 수 없습니다

먼저 로그에 표시된 도메인이 무엇인지 확인하세요. 대상 사이트일 수도 있고 서버 주소나 DNS 서비스 자체의 도메인일 수도 있습니다. 서버 주소가 도메인이라면 프록시에 연결하기 전에 코어가 먼저 이를 조회해야 합니다. 이 단계가 실패하면 모든 프록시 요청에 영향을 줄 수 있습니다. 대상 도메인 조회 실패는 일부 사이트에만 영향을 줄 수 있으므로 두 경우의 처리 순서는 다릅니다. 오류에서 해당 도메인의 역할을 기록하되 실제 주소를 공개할 필요는 없습니다.

Windows에서는 아래 명령으로 현재 시스템의 DNS 조회 결과를 확인할 수 있습니다. 시스템 DNS가 응답하는지, 예상한 서버에서 답을 받았는지 확인하는 데 적합하지만 브라우저나 프록시 코어도 같은 결과를 사용한다는 뜻은 아닙니다. 주소 조회에 성공한 뒤에도 연결이 실패한다면 라우팅, 대상 포트 또는 전송 핸드셰이크 문제일 수 있습니다. 모든 오류를 DNS 탓으로 돌리지 마세요.

Resolve-DnsName example.com

원격 DNS 조회를 시험하려면 SOCKS의 도메인 전달 기능을 사용해 로컬에서 먼저 조회한 IP 대신 도메인을 프록시 경로로 전달할 수 있습니다. 아래 예시는 SOCKS 또는 혼합 수신 포트가 10808이라고 가정합니다. 해당 포트가 HTTP만 지원한다면 그에 맞는 테스트 방법을 사용하세요. 프로토콜 불일치로 발생한 오류를 DNS 실패로 해석하면 안 됩니다.

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

암호화 DNS에도 먼저 연결 가능한 경로가 필요합니다

HTTPS 기반 DNS를 사용하려면 DNS 서비스에 연결할 수 있어야 하며 서비스 도메인의 조회도 필요할 수 있습니다. 아직 연결되지 않은 프록시를 통해 DNS 서비스 연결을 강제하면 프록시가 서버 주소 조회를 기다리고, DNS 조회는 다시 프록시 연결을 기다리는 순환 의존이 생길 수 있습니다. 분기 규칙을 추가하기 전에 서버 주소의 기본 조회와 DNS 서비스에 도달할 경로부터 확인하세요. 서로 의존하는 조회 경로를 한꺼번에 여러 개 추가하지 마세요.

v2rayN에서 현재 사용하는 코어의 DNS 설정을 확인하고 일반 프록시와 TUN 환경을 구분하세요. 코어마다 설정 필드가 호환되지 않을 수 있으므로 한 설정의 DNS 부분을 다른 코어에 그대로 붙여 넣지 마세요. 먼저 인터페이스에서 제공하는 설정 메뉴를 사용하고 저장 후 코어가 다시 로드됐는지 확인합니다. 선택되지 않은 설정 파일을 수정했다면 화면에서는 변경된 것처럼 보여도 실제 실행 중인 설정은 이전 내용일 수 있습니다.

DNS 조회와 라우팅 규칙을 함께 확인

도메인 규칙은 요청에 도메인 정보가 남아 있어야 하고, IP 규칙은 대상 주소와 데이터 파일에 의존합니다. 브라우저가 먼저 조회하거나 앱이 IP만 전달하거나 트래픽 탐지 과정에서 도메인을 얻지 못하면 도메인 규칙이 적용되지 않을 수 있습니다. Sniffing은 일부 연결에 식별 가능한 대상 정보를 보완할 수 있지만 모든 프로토콜을 지원하는 것은 아니며 DNS를 대체하지도 않습니다. 요청에 어떤 정보가 포함됐는지 먼저 살펴보고 일치한 규칙을 확인하세요. 도메인을 얻지 못한 문제를 규칙 문법 오류로 오인하지 마세요.

아래는 Xray 형식의 라우팅 규칙 예시로, 도메인 및 IP 조건을 작성하는 방법을 보여줍니다. 완전한 클라이언트 설정은 아닙니다. 사용 가능한 geosite·geoip 데이터와 정의된 direct 출구가 필요합니다. 조건을 각각 별도의 규칙으로 나누면 일치 과정을 확인하기 쉽습니다. 이 코드를 전체 설정 파일에 덮어쓰지 마세요. 그래픽 인터페이스에서는 라우팅 편집 기능으로 같은 규칙을 설정해야 합니다.

{
  "rules": [
    {
      "type": "field",
      "domain": ["geosite:cn"],
      "outboundTag": "direct"
    },
    {
      "type": "field",
      "ip": ["geoip:private"],
      "outboundTag": "direct"
    }
  ]
}

데이터 파일 누락, 태그 오타, 잘못된 규칙 순서로 예상과 다른 출구가 선택될 수 있습니다. 자세한 규칙 순서는 geosite·geoip 분기 설정 안내를 참고하세요. 문제를 찾을 때는 해당 대상과 관련된 규칙만 임시로 조정하세요. DNS 문제 하나 때문에 분기 설정 전체를 삭제하지 말고, 확인 후 복구할 수 있도록 원본 설정을 보관하세요.

설정을 바꾼 뒤 브라우저의 기존 탭을 닫거나 관련 앱을 다시 시작하고, 필요하다면 시스템 DNS 캐시를 비우세요. 캐시 삭제는 새 요청을 다시 조회하게 할 뿐 잘못된 서버 주소나 순환 의존을 해결하지 않습니다. 브라우저에서만 문제가 발생한다면 보안 DNS가 시스템 설정을 우회하는지 확인하세요. TUN에서만 문제라면 가상 네트워크의 DNS 라우팅을 확인합니다. 마지막으로 일반 도메인과 현재 서버 도메인 모두에 접속해 기본 연결과 대상 접근이 복구됐는지 확인하세요.

Android 문제: VPN 권한·앱별 프록시·백그라운드 실행

Android에서는 v2rayNG를 우선 사용하고 V2Fly 코어 설정이 필요하다면 v2flyNG를 선택할 수 있습니다. 두 클라이언트의 인터페이스와 코어 옵션은 완전히 같지 않으므로 다른 클라이언트의 메뉴 이름을 그대로 찾아다니기 전에 현재 실행 중인 앱부터 확인하세요. 다운로드는 Android 클라이언트 다운로드에서 진행할 수 있습니다. 시작하기 전에 구독 정보를 보관하고 연결 버튼을 누른 직후 문제가 생기는지, 화면을 잠그거나 네트워크를 전환하거나 특정 앱을 실행한 뒤에 나타나는지 기록하세요.

VPN 권한과 실제 트래픽 처리 상태 확인

처음 연결을 시작하면 시스템에서 VPN 연결 권한을 요청하는 경우가 많습니다. 권한을 허용하고 로컬 VPN 인터페이스가 정상적으로 만들어져야 클라이언트가 관련 앱 트래픽을 처리할 수 있습니다. 상태 표시줄 아이콘은 인터페이스가 있다는 뜻일 뿐 원격 서버 연결이 정상이라는 뜻은 아닙니다. 연결한 뒤 대상 사이트를 열어 실제로 확인하세요. 권한 창이 나타나지 않거나 순식간에 사라진다면 시스템 VPN 설정에서 기존 구성과 관리 정책을 점검하세요.

같은 사용자 환경에서 VPN 인터페이스를 사용하는 네트워크 도구 여러 개를 동시에 실행할 수 없는 경우가 많습니다. 다른 VPN, LAN 도구, 로컬 VPN을 사용하는 필터링 앱이 현재 연결을 대체할 수 있습니다. 먼저 모두 연결 해제한 뒤 클라이언트 하나만 실행해 다시 시험하세요. 특정 VPN의 상시 연결을 설정했거나 VPN을 통하지 않는 연결을 차단했다면 현재 사용 중인 앱을 대상으로 설정했는지도 확인해야 합니다. 잘못 조합하면 연결이 끊겼을 때 시스템이 모든 접속을 차단할 수 있습니다.

앱별 라우팅 규칙이 예상과 반대인지 확인

클라이언트에서 앱별 프록시 또는 앱별 라우팅 설정을 열고 목록이 ‘선택한 앱만 프록시 사용’인지 ‘선택한 앱 우회’인지 확인하세요. 두 설정은 의미가 반대이므로 체크된 항목 수만 보고 판단하면 안 됩니다. 브라우저는 정상인데 다른 앱이 실패한다면 해당 앱이 실제 트래픽 처리 범위에 포함됐는지 먼저 확인하세요. 새로 설치한 앱이 목록에 없을 수도 있습니다. 변경 후에는 연결을 끊었다가 다시 연결해 VPN 라우팅과 앱 범위가 적용되도록 하세요.

클라이언트의 로컬 프록시 입구와 시스템 VPN 모드는 별개입니다. 로컬 프록시 서비스만 켜도 일반 Android 앱이 자동으로 이를 사용하는 것은 아닙니다. 반대로 VPN 처리가 정상이라면 각 앱에 로컬 프록시를 따로 입력할 필요가 없습니다. Wi-Fi의 수동 프록시 설정까지 함께 켜면 경로가 중복될 수 있습니다. 먼저 클라이언트 기본 VPN 방식으로 되돌리고 불필요한 수동 프록시 설정을 해제한 뒤 서버를 확인하세요.

화면 잠금 후 연결 끊김·네트워크 전환 실패 점검 순서

앱을 화면에 표시했을 때는 연결되지만 잠시 잠근 뒤 실패한다면 시스템 배터리 관리가 클라이언트를 제한하는지 확인하세요. 기기에서 제공하는 설정으로 필요한 백그라운드 실행을 허용하고 해당 앱의 과도한 절전 제한을 해제하며 연결 알림은 유지하세요. 기기마다 메뉴 이름이 다르므로 앱 정보의 배터리, 백그라운드 활동, 네트워크 권한 항목을 살펴보세요. 모든 앱의 백그라운드 제한을 해제하지 말고 연결에 사용하는 클라이언트만 조정하세요.

Wi-Fi와 모바일 네트워크를 전환한 뒤에는 이전 네트워크 상태를 참조하는 연결이 남아 있을 수 있습니다. 먼저 연결을 끊었다가 다시 연결해 복구되는지 확인하세요. 네트워크를 바꿀 때마다 재현된다면 전환 전후의 네트워크 종류와 로그를 기록합니다. 공용 Wi-Fi에서는 웹 인증을 먼저 완료해야 할 수도 있습니다. 데이터 절약 모드, 로밍 제한, 특정 네트워크에서만 허용하는 앱 권한으로 ‘집에서는 정상인데 밖에서는 실패’하는 상황이 생길 수 있으므로 서버 문제와 나눠 확인하세요.

특정 네트워크에서만 도메인 오류가 발생한다면 시스템 비공개 DNS 설정과 클라이언트 자체 DNS 설정을 확인하세요. 두 설정이 같은 연결 경로를 사용한다고 볼 수 없으며, 하나를 끄면 나머지가 자동으로 활성화되는 것도 아닙니다. 원래 값을 기록하고 시스템 자동 선택으로 잠시 되돌려 비교한 다음 이 페이지의 DNS 항목에서 서버 도메인과 대상 도메인을 확인하세요. 결과를 설명할 수 없는 상태에서 DNS 주소를 여러 개 연달아 추가하면 실패 경로를 재현하기 어려워집니다.

웹·실시간 통신·구독 백그라운드 문제 구분

웹은 열리지만 음성 통화, 게임 또는 다른 실시간 기능이 실패한다면 UDP, 앱별 처리 범위, 서버 지원 여부가 원인일 수 있습니다. 해당 앱의 트래픽이 프록시로 전달되는지 먼저 확인한 뒤 서버 프로토콜과 제공자의 지원 안내를 점검하세요. 웹이 열린다는 이유만으로 모든 전송 방식이 작동한다고 판단하면 안 됩니다. 한 앱에서만 문제가 발생한다면 앱 자체 네트워크 진단을 사용해 보세요. 특정 기능 하나 때문에 모든 라우팅과 DNS를 동시에 초기화하지 마세요.

구독을 화면이 켜진 상태에서 수동 업데이트하면 정상인데 백그라운드 자동 업데이트만 실패한다면 백그라운드 네트워크 제한과 업데이트 시점을 먼저 확인하세요. 구독을 바로 삭제하지 마세요. 설치 중 패키지가 호환되지 않는다는 메시지가 나오면 기기 아키텍처를 확인하고 다운로드 페이지에서 arm64 또는 범용 버전을 선택하세요. 설치 호환성 문제를 연결 문제로 오인하지 마세요. 클라이언트를 바꾸기 전에 기존 설정의 프로토콜과 대상 코어가 호환되는지 확인하고, 세 클라이언트의 비교는 클라이언트 비교 가이드를 참고하세요.

원인을 찾지 못했다면 ‘언제 정상인지, 언제 실패하는지, 재연결하면 복구되는지’를 비교해 정리하고 민감한 내용을 숨긴 오류 로그를 첨부하세요. 자주 쓰는 용어는 용어 설명에서, 기본 절차는 시작 가이드에서 확인할 수 있습니다. 재설치를 반복하는 것보다 재현 조건을 명확히 정리하는 편이 도움이 되며, 같은 문제가 다시 생겨도 이미 확인한 단계 다음부터 바로 점검할 수 있습니다.