V2Ray 문제 해결 가이드

01 / 앱 → 로컬 진입점 → 코어 → 외부 연결

인터넷에 연결되지 않을 때: 연결 경로 나누어 확인하기

“클라이언트가 연결됨”은 보통 로컬 서비스가 시작되었다는 뜻일 뿐, 원격 인증에 성공했거나 브라우저 트래픽이 프록시를 통과했다는 의미는 아닙니다. 문제를 진단하기 전에 클라이언트 이름, 운영체제, 현재 서버 별칭, 시스템 프록시 모드, 라우팅 모드, Tun 상태를 기록하고 실패한 웹사이트와 발생 시간도 적어 두세요. 처음부터 구성을 삭제하거나 네트워크를 초기화하지 마세요. 원본 로그와 설정을 남겨야 문제 위치를 파악하고 변경 전후를 비교할 수 있습니다.

기본 네트워크부터 확인한 뒤 로컬 진입점을 점검하세요

클라이언트를 종료하고 시스템 네트워크 설정을 원래대로 되돌린 다음, 평소에 바로 접속할 수 있는 웹사이트를 테스트하세요. 직접 연결도 실패한다면 Wi-Fi에 로그인 페이지가 필요한지, 케이블이 빠져 있는지, 네트워크 어댑터가 IP 주소를 받았는지, 시스템에 수동 프록시 설정이 남아 있는지 확인하세요. 공용 네트워크에서는 프록시가 켜져 있으면 인증 페이지가 열리지 않을 수 있으므로 먼저 인증을 마친 뒤 클라이언트를 실행하세요. 특정 웹사이트 하나만 직접 연결에 실패한다고 전체 네트워크에 문제가 있다고 단정할 수는 없습니다. 서로 무관한 사이트를 하나 이상 더 확인하세요.

기본 네트워크가 정상이라면 v2rayN을 다시 열고, 가져온 서버 중 설정이 완전한 항목을 선택하세요. 우선 Tun을 끄고 시스템 프록시 경로만 테스트합니다. 클라이언트 설정에서 로컬 수신 주소와 포트를 확인하고, 코어 시작 로그에 오류가 없는지도 살펴보세요. 아래 명령은 로컬 포트가 실제로 10808이고 해당 진입점이 HTTP 프록시를 지원하는 경우에만 사용할 수 있습니다. 포트가 다르면 값을 바꾸세요. 이 명령으로 브라우저의 시스템 프록시 사용 여부는 배제할 수 있지만, 코어의 라우팅 규칙까지 우회하지는 않습니다.

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

명령이 웹사이트 응답 헤더를 반환하면 접근 제한 응답이라도 요청이 어떤 HTTP 서비스까지 도달했을 가능성이 큽니다. 대상이 맞는지는 인증서와 응답 내용도 확인하세요. 로컬 포트 연결에 실패하면 코어가 실행 중인지, 포트 설정이 일치하는지 우선 점검합니다. 프록시 터널 생성이나 원격 핸드셰이크에 실패하면 서버 연결 단계로 넘어가세요. HTTP 진입점에 SOCKS 요청을 보내지 마세요. 프로토콜을 잘못 지정하면 포트 연결은 되더라도 요청을 제대로 처리하지 못합니다.

로그로 로컬 진입점, 외부 연결, 대상 웹사이트 구분하기

v2rayN의 로그 창을 열고 현재 시간을 확인한 뒤, 대상 사이트에 한 번만 접속하고 새로 기록된 로그를 살펴보세요. 관련 로그가 전혀 없더라도 앱이 프록시를 사용하지 않았다고 단정할 수는 없습니다. 현재 로그 수준에서 정상 요청을 기록하지 않을 수도 있습니다. 필요하면 잠시 로그 상세도를 높이고 명시적 프록시 명령으로 결과를 비교하세요. 연결 거부 로그는 해당 주소에 도달했지만 서비스가 연결을 받아들이지 않았다는 뜻입니다. 시간 초과가 계속되면 주소, 네트워크 경로, 서버 상태도 확인해야 합니다.

명시적 프록시 요청은 성공하지만 브라우저에서 실패한다면 브라우저 확장 프로그램, 사용자 지정 프록시, 보안 DNS 설정을 확인한 뒤 시스템 프록시 항목에 따라 앱의 프록시 적용 상태를 점검하세요. 모든 프록시 요청이 실패하고 직접 연결은 정상이라면, 설정 출처가 다른 정상 서버를 선택해 보세요. 도메인 하나만 실패한다면 전체 구독을 바꾸기 전에 해당 도메인의 라우팅 규칙과 DNS 결과를 확인하세요. 서버, 대상 웹사이트, 클라이언트는 각각 별개의 대상이므로 따로 검증해야 합니다.

마지막으로 임시 디버그 로그를 끄고 필요한 시스템 프록시나 Tun 모드를 복원한 뒤, 처음에 실패했던 앱을 다시 여세요. 브라우저가 기존 연결을 재사용할 수 있으므로 필요하면 완전히 종료했다가 다시 실행하세요. “어떤 설정을 바꾸자 결과가 달라졌는지” 기록하는 것이 “재시작하니 됐다”라고 적는 것보다 유용합니다. 전자는 같은 문제가 다시 발생했을 때 원인을 빠르게 찾을 수 있지만, 후자는 일시적인 네트워크 복구와 설정 변경의 효과를 구분하기 어렵습니다.

02 / 주소 → 포트 → 전송 방식 → TLS → 인증

서버 연결 시간 초과: 핸드셰이크 단계 확인하기

서버 테스트가 시간 초과로 끝났다고 해서 서버가 반드시 중단된 것은 아닙니다. 테스트 과정에서 먼저 서버 도메인을 확인하고, 전송 연결을 만든 뒤, 보안 핸드셰이크와 프로토콜 인증을 완료하고 테스트 URL에 요청할 수 있습니다. 어느 단계에서든 실패하면 결과에 영향을 줍니다. 먼저 TCP 연결 테스트, 실제 연결 테스트, 웹 속도 테스트 중 어떤 방식을 사용했는지 확인하세요. 각 테스트가 확인하는 경로는 서로 다릅니다. 특히 TCP가 아닌 전송 방식을 사용하는 구성에서는 일반 TCP 탐색 결과만으로 실제 프로토콜의 사용 가능 여부를 판단할 수 없습니다.

프로토콜을 바꾸기 전에 서버 주소와 포트부터 확인하세요

서버 편집 창에서 주소와 포트를 확인하세요. 주소에 https://, 경로, 끝부분 공백이 포함되어 있지 않은지 살펴보고, 포트가 서버에서 실제로 수신 중인 값과 일치하는지 확인합니다. 도메인 주소는 먼저 DNS 조회가 되는지 확인하고, IP 주소는 현재 서버 주소가 맞는지 점검하세요. Windows에서는 아래 명령으로 TCP 연결 여부를 확인할 수 있습니다. 예시 도메인을 자신의 서버 주소로 바꾸세요. 연결에 성공해도 TCP 연결만 확인된 것이며, 프로토콜 인증이나 TLS, 대상 요청의 성공까지 보장하지는 않습니다.

Test-NetConnection -ComputerName example.net -Port 443

테스트가 실패하면 설정은 그대로 둔 채 휴대폰 핫스팟 등 다른 네트워크에서 비교하세요. 다른 네트워크에서는 성공한다면 원래 네트워크의 외부 연결, 방화벽 또는 라우팅 제한을 우선 살펴보세요. 두 네트워크에서 모두 실패한다면 서버 수신 상태, 진입점 방화벽, 주소 만료 여부를 확인합니다. 서버를 관리할 권한이 없다면 실패 시간과 대상 주소, 오류가 발생한 단계를 구성 제공자에게 전달하세요. 포트를 무작정 바꾸지 마세요. 서버 설정과 포트가 일치하지 않으면 새로운 문제가 생길 뿐입니다.

TLS, 전송 설정, 프로토콜 인증을 구분하세요

포트에 연결된 뒤에도 실패한다면 로그에서 인증서 검증, 핸드셰이크, 인증 또는 전송 경로 관련 오류를 확인하세요. TLS 설정에서는 서버 이름, 즉 흔히 SNI라고 부르는 항목과 시스템 시간이 정확한지 확인해야 합니다. 인증서 이름은 일반적으로 연결에 사용한 IP와 같을 필요는 없지만, 서버 인증서 및 구성 요구사항과 일치해야 합니다. WebSocket을 사용한다면 경로와 Host도 확인하고, gRPC를 사용한다면 서비스 이름을 확인하세요. 이 항목을 모두 주소란의 도메인으로 바꾸는 것은 일반적인 해결책이 아닙니다.

REALITY 구성은 서버 주소 외에도 제공된 정보에 따라 공개 키, 짧은 ID, 서버 이름 등의 항목을 확인해야 합니다. 일반 TLS와 인증서 설정 방식이 다르므로 같은 매개변수를 적용하면 안 됩니다. VLESS, VMess, Trojan의 인증 정보도 서로 바꿔 쓸 수 없습니다. 구독을 업데이트한 뒤에도 이전 서버 항목이 다른 그룹에 남아 있을 수 있으니, 별칭이 같아 보이는지만 확인하지 말고 새 항목이 선택되어 있는지 살펴보세요. 인증서 오류의 상세한 해결 절차는 시스템 시간 및 SNI 문제 해결 노트를 참고하세요.

핸드셰이크 문제를 숨기려고 인증서 검증을 계속 건너뛰지 말고, 시간 초과를 없애려고 대기 시간만 계속 늘리지도 마세요. 시간 초과 기준은 실패 판정까지 걸리는 시간만 바꿀 뿐, 잘못된 주소나 인증 설정을 고쳐 주지 않습니다. 항목을 하나 수정할 때마다 실제 요청을 다시 보내 로그가 다음 단계로 진행되는지 확인하세요. 포트 연결과 핸드셰이크는 성공했는데 테스트 URL 요청만 실패한다면 문제는 서버의 외부 연결, DNS 또는 테스트 대상에 있을 수 있습니다. 다른 대상을 이용해 비교하고 클라이언트 인증 정보를 계속 바꾸지는 마세요.

03 / 구독 가져오기 ≠ 서버 연결

구독 업데이트 실패: 가져오기와 파싱 확인하기

구독 업데이트는 별도의 웹 요청이며, 현재 서버 연결과 다른 네트워크 경로를 사용할 수 있습니다. 먼저 “요청으로 콘텐츠를 받지 못한 경우”와 “콘텐츠는 받았지만 클라이언트가 가져오지 못한 경우”를 구분하세요. 전자는 주소, 네트워크, 계정 상태, 인증서 문제일 가능성이 높고, 후자는 잘못된 페이지가 반환되었거나 형식이 맞지 않거나 지원되지 않는 항목이 포함되었을 수 있습니다. 업데이트가 실패해도 기존 서버를 삭제하지 마세요. 이전 설정으로 연결이 될 수 있어 구독 요청 경로를 복구하는 데 도움이 됩니다.

주소와 구독 그룹 확인하기

v2rayN의 “구독 그룹”에서 해당 그룹의 설정을 열고 구독 주소가 빠짐없이 복사되었는지 확인하세요. 특히 물음표 뒤의 쿼리 매개변수, 끝부분 문자, 실수로 포함된 줄바꿈을 살펴보세요. 구독 링크의 토큰은 접근 자격 증명입니다. 공개 로그, 스크린샷 또는 온라인 디코딩 도구에 붙여넣지 마세요. 채팅 창에서 주소를 복사하면 문장부호가 함께 들어갈 수 있고, 서식 있는 링크의 표시 이름이 실제 주소와 다를 수도 있습니다. 구성 제공자가 안내한 복사 기능을 이용해 다시 가져오세요.

업데이트 대상 그룹과 편집한 그룹이 같은지 확인한 다음 “프록시를 사용하지 않고 구독 업데이트”를 시도하세요. 로컬 네트워크에서 구독 서비스에 접속할 수 있다면, 이 경로를 사용해 작동하지 않는 서버에 의존하지 않을 수 있습니다. 직접 요청이 시간 초과되고 현재 프록시가 실제 접속 테스트에 성공했다면 프록시를 통해 업데이트해 보세요. 두 방법이 모두 실패하면 각각의 오류를 기록하세요. 버튼 이름만으로 클라이언트가 예상한 경로를 사용한다고 단정하지 말고, 로그와 현재 프록시 상태도 함께 확인해야 합니다.

응답 내용에 따라 해결 방법을 선택하세요

인증되지 않았거나 접근이 금지되었다는 응답이 나오면 계정 상태, 구독 토큰, 서버 권한을 확인해야 합니다. 업데이트 버튼을 반복해서 눌러도 권한은 바뀌지 않습니다. 요청이 너무 많다는 메시지가 나오면 연속 재시도를 멈추고 서버가 허용하는 간격이 지난 뒤 다시 시도하세요. 인증서 오류라면 기기 시간과 인증서 체인을 확인합니다. 요청은 성공했지만 사용 가능한 서버가 없다고 표시된다면 로그인 페이지, 점검 페이지, 인증 페이지 또는 다른 클라이언트용 형식을 받았을 수 있습니다. HTTP 요청 성공이 구독 콘텐츠의 정상 여부를 보장하지는 않습니다.

구독은 클라이언트에서 지원하는 공유 링크의 모음이나 인코딩된 콘텐츠일 수 있습니다. 텍스트로 보인다고 모두 가져올 수 있는 것은 아닙니다. 다른 구성 형식의 확장자나 이름을 임의로 바꿔 가져오지 말고, 구독 주소를 “클립보드에서 공유 링크 가져오기”에 넣으면 모든 클라이언트가 자동 인식한다고 기대하지 마세요. 제공된 클라이언트 유형에 맞는 가져오기 메뉴를 선택하세요. 구독의 새 항목을 인식하지 못한다면 먼저 다운로드 페이지에서 클라이언트 선택을 확인하고, 설정을 백업한 뒤 클라이언트를 업데이트하세요. 구독 전체를 직접 수정하지 마세요.

업데이트가 끝나면 현재 서버 항목을 확인하세요

업데이트가 끝나면 그룹의 서버 목록이 예상한 내용인지 확인하고 테스트할 항목을 다시 선택하세요. 일부 그룹 설정은 이전 서버를 남겨 두거나 현재 선택을 유지할 수 있으므로 “업데이트 완료”만 보고 모든 항목이 바뀌었다고 판단하면 안 됩니다. 별칭이 같아도 주소, 포트, 보안 설정은 다를 수 있습니다. 업데이트 직후 연결이 안 된다면 새 설정과 이전 설정의 프로토콜, 전송 방식, 보안 항목을 비교한 뒤 제공자에게 서버 이전이나 설정 변경 여부를 문의하세요.

예약 업데이트만 실패하고 수동 업데이트는 성공한다면 작업이 실행될 때 클라이언트가 켜져 있었는지, 시스템 네트워크가 아직 연결되지 않았는지, 사용할 서버가 없었는지 확인하세요. 시작 순서 때문에 발생한 실패라면 구독 형식을 바꿀 필요는 없습니다. 복구 후에는 수동 업데이트 성공, 그룹 콘텐츠 표시, 새 항목 선택, 실제 웹사이트 접속 성공까지 전체 과정을 확인하세요. 처음 구독 그룹을 만드는 방법은 빠른 시작 가이드를 참고하세요. 이 항목에서는 구독 경로가 끊긴 지점을 다룹니다.

04 / 전송량·대기 시간·안정성을 따로 측정하기

속도 저하: 비교 가능한 테스트 만들기

“속도가 느리다”는 웹페이지 첫 로딩 지연, 다운로드 속도 저하, 동영상 버퍼링, 연결이 간헐적으로 끊기는 경우를 모두 포함할 수 있습니다. 첫 로딩 지연은 DNS, 핸드셰이크, 연결 설정과 관련이 있는 경우가 많고, 지속적인 다운로드 속도 저하는 대역폭, 혼잡, 대상 사이트의 속도 제한과 관련될 수 있습니다. 전송 중 연결이 끊긴다면 Wi-Fi, 기기 절전, 서버 연결 정책도 확인해야 합니다. 어느 단계에서 증상이 나타나는지 먼저 기록하고 그에 맞는 방법으로 테스트하세요. 지연 시간이 낮다고 전송 속도가 빠른 것은 아니며, 한 번의 속도 측정으로 모든 사이트의 속도를 판단할 수도 없습니다.

네트워크·대상·테스트 시간을 동일하게 유지하세요

테스트할 때 같은 기기와 네트워크, 같은 파일 또는 웹페이지를 사용하고 시스템 업데이트, 클라우드 동기화 등 대용량 작업은 잠시 중단하세요. 가능하면 유선 네트워크나 신호가 안정적인 Wi-Fi에서 비교해 무선 간섭을 서버 문제로 오인하지 않도록 합니다. 시간대를 기록하며 여러 차례 연속으로 측정하고, 여러 서버의 속도 테스트를 동시에 시작하지 마세요. 동시 테스트는 로컬 대역폭을 나눠 쓰게 하고 원격 서버의 동시 연결 제한을 유발할 수도 있습니다. 한 번의 테스트가 끝나 연결이 종료된 뒤 다음 비교를 진행하세요.

먼저 직접 연결로 접속 가능한 대상의 기본 상태를 확인한 다음 프록시 경로의 결과와 비교하세요. 두 테스트에서 서로 다른 대상을 사용하면 로컬 네트워크에 전반적인 문제가 있는지 살펴볼 수는 있지만, 프록시로 인한 속도 저하를 직접 계산할 수는 없습니다. 서버 두 대를 공정하게 비교하려면 같은 대상과 같은 요청 방식을 사용하세요. 특정 다운로드 서버가 접속 IP에 따라 속도를 제한하거나 느린 외부 회선을 제공할 수도 있습니다. 따라서 “서버를 바꾸니 빨라졌다”는 결과는 해당 조합이 더 적합하다는 뜻이지, 이전 서버의 전반적인 성능이 부족하다는 뜻은 아닙니다.

DNS 조회 대기와 데이터 전송 대기를 구분하세요

웹페이지를 처음 열 때마다 오래 기다리지만 이후 다운로드는 정상이라면 DNS 시간 초과, IPv6 대체 연결, TLS 핸드셰이크를 먼저 확인하세요. 브라우저 개발자 도구의 네트워크 타임라인에서 DNS 조회, 연결, 응답 대기, 콘텐츠 다운로드 시간을 구분할 수 있습니다. 프록시를 사용할 때는 일부 단계가 프록시에서 처리될 수 있으므로 실제 경로를 고려해 값을 해석해야 합니다. 명시적 프록시 명령으로 브라우저 확장 프로그램의 영향을 배제한 뒤 DNS 항목에 따라 조회 경로를 비교하세요. 첫 로딩이 느리다는 이유만으로 버퍼나 스레드 수부터 바꾸지 마세요.

웹 응답은 정상인데 지속 전송 속도만 낮다면 서로 다른 다운로드 서버를 이용해 특정 대상에서만 느린지 확인하세요. 다른 로컬 네트워크에서도 테스트해 병목이 로컬 외부 연결에 있는지, 원격 경로에 있는지 비교합니다. 라우팅 정책도 결과에 영향을 줍니다. 직접 연결해야 할 대용량 파일 요청이 프록시로 보내지면 경로가 길어질 수 있고, 프록시를 거쳐야 할 대상이 실수로 직접 연결되면 재시도를 반복할 수 있습니다. 테스트 중 라우팅 모드를 잠시 바꿔 비교할 수 있지만, 결과가 확인되면 분할 라우팅 요구사항을 무시하지 말고 해당 규칙을 수정하세요.

증상과 관련된 경우에만 고급 설정을 조정하세요

연결 재사용을 무조건 켜야 하는 것은 아닙니다. 효과는 코어, 프로토콜, 서버의 지원 여부에 따라 달라집니다. 일부 연결 비용을 줄일 수 있지만 패킷 손실이 발생하면 여러 요청에 영향을 줄 수도 있습니다. UDP 전달 역시 클라이언트, 외부 연결 프로토콜, 서버, 네트워크 조건에 따라 달라지며 스위치 하나로 보장할 수 없습니다. 음성 통화나 게임에 문제가 있다면 웹페이지가 열리는지만 보지 말고 앱 트래픽이 실제로 프록시를 통과하는지, UDP 경로가 구성되었는지 확인한 뒤 설정을 조정하세요.

Tun 사용 중 작은 웹페이지는 열리지만 큰 요청이 멈춘다면 경로 MTU를 확인해 볼 수 있습니다. 다만 이것만으로 원인을 단정해서는 안 됩니다. 먼저 Tun을 끄고 명시적 프록시로 비교하세요. 차이가 반복해서 재현되는 경우에만 클라이언트에서 제공하는 MTU 설정을 참고해 값을 조금씩 조정하고 원래 값을 기록해 두세요. 회사 네트워크, 가상 머신, 여러 단계의 터널은 실제 패킷 크기에 영향을 줄 수 있으므로 다른 사람의 값을 그대로 적용하는 것이 적절하지 않을 수 있습니다. 값을 바꿀 때마다 같은 대용량 요청으로 다시 테스트하세요.

정해진 피크 시간대에만 문제가 생긴다면 시간대별 비교 결과를 남기고 서비스 제공자에게 전달하세요. 클라이언트만으로 상위 네트워크 혼잡이나 원격 외부 연결의 용량 부족을 해결할 수는 없습니다. 테스트가 끝나면 로그 수준과 라우팅을 원래대로 복원하고 임시로 중단했던 앱도 다시 실행하세요. 디버그 환경과 평소 사용 환경이 너무 달라져 테스트에서는 정상인데 실제로는 느린 상황을 피할 수 있습니다.

05 / 서버 도메인 조회와 대상 도메인 조회는 별개의 경로

DNS 문제: 어디에서 조회하는지 확인하기

먼저 서버 도메인과 대상 웹사이트의 도메인을 구분하세요. 원격 서버에 연결하려면 먼저 서버 주소를 알아야 합니다. 대상 웹사이트의 도메인은 앱, 운영체제, 코어 또는 원격 측에서 조회할 수 있습니다. 브라우저의 보안 DNS가 켜져 있으면 브라우저가 별도의 경로를 사용할 수도 있습니다. 따라서 시스템 명령에서 도메인이 조회되더라도 프록시 코어가 같은 결과를 사용한다는 보장은 없습니다. 웹사이트가 프록시를 통해 열려도 시스템 DNS가 복구되었다는 뜻은 아닙니다. 해결을 위해 DNS 서버 주소부터 바꾸지 말고 실제 조회 경로부터 정리하세요.

시스템과 코어의 DNS 조회를 각각 확인하세요

Windows에서는 아래 명령으로 시스템 DNS 조회 결과를 확인할 수 있습니다. 응답 주소 유형, 시간 초과 여부, 네트워크 변경 후 결과가 달라지는지를 기록하세요. 도메인에서 여러 개의 유효한 주소가 반환되는 것은 이상 현상이 아닐 수 있습니다. 콘텐츠 전송 네트워크는 지역과 네트워크에 따라 다른 결과를 반환할 수 있습니다. IP 주소로 HTTPS 사이트에 직접 접속하는 것은 신뢰할 수 있는 대체 테스트가 아닙니다. 서버가 인증서 검증이나 가상 호스트 선택에 도메인을 사용할 수 있기 때문입니다. 인증서 오류가 발생해도 원래 도메인의 DNS에 문제가 있다고 단정할 수 없습니다.

Resolve-DnsName example.com

코어 로그에서 DNS 시간 초과, DNS 서버에 연결할 수 없음, 사용 가능한 주소 없음 등의 메시지가 있는지 확인하세요. 서버 주소가 도메인이고 원격 DNS를 사용하려면 아직 연결되지 않은 프록시가 필요한 경우, 시작 의존성 순환이 생길 수 있습니다. 프록시에 연결하려면 도메인을 조회해야 하는데, 도메인을 조회하려면 먼저 프록시에 연결해야 하는 상황입니다. 클라이언트에서 제공하는 초기 DNS 조회 또는 서버 도메인 조회 설정을 사용해 이 의존성을 해결하고, 시작 단계에 필요한 주소를 현재 네트워크에서 확인할 수 있도록 하세요. 아직 만들어지지 않은 터널로 모든 DNS 요청을 무조건 보내지 마세요.

도메인 정책이 분할 라우팅에 미치는 영향 이해하기

라우팅의 AsIs, IPIfNonMatch, IPOnDemand는 라우팅 규칙을 적용할 때 도메인 조회 결과를 어떻게 사용할지 지정합니다. 세 가지를 단순한 “DNS 속도 모드”로 이해하면 안 됩니다. AsIs는 이 단계에서 도메인을 IP로 변환하지 않습니다. IPIfNonMatch는 도메인 규칙에 일치하지 않으면 IP로 조회한 뒤 IP 규칙을 적용합니다. IPOnDemand는 IP가 필요한 규칙을 확인할 때 조회를 실행합니다. 실제 외부 연결 과정에서 별도로 DNS 조회가 필요할 수 있으므로 라우팅 정책을 모든 DNS 동작과 동일하게 보면 안 됩니다.

아래는 코어 라우팅 필드의 일부 예시이며 완성된 설정이 아닙니다. 클라이언트가 생성한 설정 파일을 그대로 덮어쓰는 데 사용해서는 안 됩니다. 도메인 분류를 먼저 확인한 다음 주소 분류를 확인하는 방식을 보여 줍니다. 해당 지리 데이터 파일과 direct라는 이름의 외부 연결이 이미 있어야 합니다. v2rayN에서 라우팅 설정을 편집할 때는 규칙이 실제 사용 중인 라우팅 집합에 기록되는지 확인하세요. 규칙 순서와 그보다 앞선 규칙도 최종 결과에 영향을 줍니다.

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

브라우저 캐시, IPv6, Tun의 트래픽 적용 확인하기

브라우저에서만 문제가 발생하면 보안 DNS, 확장 프로그램, 캐시를 확인하고 모든 앱에서 문제가 발생하면 시스템과 코어를 점검하세요. IPv6 조회에 성공해도 현재 네트워크에서 IPv6 외부 연결을 사용할 수 있다는 뜻은 아닙니다. 반대로 IPv6를 끄는 것도 일반적인 해결책이 아닙니다. 먼저 주소 유형과 연결 로그를 비교해 특정 유형의 주소 연결만 계속 실패하는지 확인한 뒤 클라이언트의 DNS 또는 외부 연결 정책을 조정하세요. 설정 변경 후 캐시가 만료될 때까지 기다리거나 기존 결과를 재사용하지 않도록 관련 앱을 다시 시작해야 할 수 있습니다.

Tun의 DNS 적용 여부는 클라이언트 구현, 시스템 라우팅, 앱 동작에 따라 달라집니다. Tun을 켜면 모든 DNS 요청이 반드시 같은 경로를 사용한다고 볼 수 없습니다. 로그에 예상하지 못한 가상 주소가 나타나면 FakeDNS 유형의 기능이 활성화되어 있는지 확인하세요. 해당 주소를 시스템 hosts 파일에 바로 추가하지 마세요. 캐시를 지우기 전에 기존 결과를 기록하고 DNS 설정을 변경한 뒤 결과를 다시 비교하세요. 접두사와 규칙 일치 순서에 관한 자세한 내용은 사용자 지정 라우팅 규칙 노트를, 구체적인 라우팅 조합은 직접 연결·프록시·차단 설정을 참고하세요.

06 / 시스템 설정·앱 설정·가상 네트워크 인터페이스를 나눠 확인하기

프록시가 적용되지 않을 때: 트래픽 적용 방식 확인하기

시스템 프록시는 앱이 읽을 수 있는 설정 모음이지 모든 트래픽을 강제로 통과시키는 스위치가 아닙니다. Tun은 가상 네트워크 인터페이스와 라우팅을 이용해 트래픽을 전달하므로 시스템 프록시와 작동 계층이 다릅니다. 진단할 때는 우선 한 가지 방식만 켜세요. 데스크톱 브라우저라면 먼저 “시스템 프록시 자동 설정”을 사용해 로컬 진입점과 원격 연결이 모두 정상인지 확인한 다음 Tun을 테스트하세요. 두 방식을 함께 켜고 DNS까지 동시에 바꾸면 여러 계층의 문제가 뒤섞여 어떤 변경이 결과에 영향을 줬는지 파악하기 어려워집니다.

시스템 설정이 앱에서 실제로 사용되는지 확인하세요

v2rayN 하단 상태 표시줄에서 “시스템 프록시 자동 설정”을 선택한 다음 운영체제의 프록시 설정을 열어 로컬 주소와 포트가 실제로 입력되었는지 확인하세요. 주소가 루프백인지 확인하는 것만으로는 부족합니다. 포트도 클라이언트의 수신 포트와 일치해야 합니다. 시스템 설정이 저절로 복원된다면 다른 프록시 프로그램, 브라우저 확장 프로그램, 기기 관리 정책, 보안 소프트웨어가 설정을 바꾸는지 확인하세요. 여러 클라이언트가 동시에 시스템 프록시를 관리하거나 같은 설정을 두고 반복해서 충돌하게 하지 마세요.

Windows에서는 일부 명령줄 프로그램과 백그라운드 서비스가 데스크톱 시스템 프록시를 사용하지 않습니다. 환경 변수를 읽거나 별도의 프록시 설정을 사용하는 앱도 있습니다. 브라우저는 접속되는데 명령줄에서는 실패한다고 클라이언트에 문제가 있다고 단정할 수 없습니다. 앱의 안내에 따라 프록시를 설정하거나 명시적 프록시 매개변수를 지원하는 요청으로 비교하세요. macOS 프록시 설정은 현재 네트워크 서비스와 연결됩니다. Wi-Fi, 유선 네트워크 또는 다른 서비스로 전환했다면 이전에 설정한 서비스만 보지 말고 현재 적용 중인 서비스의 설정을 확인하세요.

단일 진입점으로 포트와 우회 목록 확인하기

시스템 프록시의 우회 목록과 대상 도메인에 직접 연결 규칙을 적용한 브라우저 설정이 있는지 확인하세요. 내부 네트워크 주소를 직접 연결하는 것은 일반적으로 적절합니다. 로그에 흔적을 남기려고 모든 내부 네트워크 트래픽을 원격으로 보내면 안 됩니다. 대상이 우회 목록에 있다면 실제 용도에 맞게 해당 규칙만 수정하세요. 다른 기기에서 로컬 프록시에 연결하려는 경우에는 수신 주소, 방화벽, 접근 제어를 별도로 설정해야 합니다. 이때 로컬 브라우저 문제를 해결한다는 이유로 LAN 수신을 함부로 켜지 마세요.

Tun이 작동하지 않을 때는 권한과 라우팅부터 확인하세요

다른 VPN 또는 터널 프로그램을 끈 다음 클라이언트 안내에 따라 가상 인터페이스 생성과 라우팅 변경에 필요한 권한을 부여하세요. Windows에서는 관리자 권한이 필요한 경우가 많으며, 다른 데스크톱 플랫폼에서는 사용하는 클라이언트의 권한 안내를 따르세요. Tun을 켠 뒤에는 스위치가 켜졌는지만 보지 말고 로그에서 인터페이스 생성이 실제로 완료되었는지 확인하세요. 권한 요청을 취소하면 화면 상태가 실제 적용 결과를 바로 반영하지 않을 수 있으므로 로그와 인터페이스 상태를 기준으로 판단해야 합니다.

Tun을 켠 직후 인터넷이 끊긴다면 먼저 Tun을 끄고 네트워크가 복구되는지 확인한 다음 여러 네트워크 어댑터, 가상 머신 네트워크, 기업용 네트워크 프로그램, 남아 있는 라우팅 설정을 점검하세요. 원격 서버 연결이 실수로 자신의 터널에 다시 들어가면 루프가 생길 수 있습니다. DNS 적용 충돌로 모든 도메인이 한꺼번에 실패하는 것처럼 보일 수도 있습니다. 라우팅이 무엇을 하는지 모른 채 시스템 경로를 일괄 삭제하지 마세요. 우선 클라이언트의 정상 종료 기능으로 설정을 되돌리고, 충돌하는 프로그램을 하나씩 비활성화해 비교하면서 복구 가능한 상태를 유지하세요.

복구 후 프록시가 필요한 앱, 로컬 네트워크 서비스, 시스템 인터넷 연결 확인을 각각 테스트하세요. 시스템 인터넷 연결 아이콘이 비정상적으로 표시되어도 확인 대상 서버에 접속할 수 없을 뿐일 수 있으므로 실제 요청 결과를 함께 살펴보세요. 메인 창의 상태 표시줄, 로그, 설정 위치는 v2rayN 메인 화면 안내를 참고하세요. 최종적으로 어떤 앱이 시스템 프록시를 사용하고, 어떤 앱은 별도 설정이 필요한지, Tun은 언제 사용하는지 정리해 두세요.

07 / 그래픽 인터페이스 시작과 코어 시작을 따로 확인하기

시작 실패: 현재 상태를 기록한 뒤 복구하기

더블클릭해도 창이 뜨지 않는 경우, 창이 열린 뒤 종료되는 경우, 화면은 정상인데 코어가 중지되는 경우는 서로 다른 문제입니다. 먼저 작업 관리자에서 클라이언트 프로세스가 이미 실행 중인지 확인하고, 창이 시스템 트레이로 최소화되었거나 연결이 끊긴 모니터로 이동했는지 살펴보세요. 여러 인스턴스를 실행하려고 연달아 더블클릭하지 마세요. 로컬 포트나 설정 파일을 두고 충돌해 단일 문제가 여러 인스턴스 간 충돌로 번질 수 있습니다. 프로세스를 종료해야 한다면 먼저 로그를 기록하고 정상 종료를 시도하세요. 응답이 없을 때만 강제 종료를 고려해야 합니다.

설치 형식·아키텍처·쓰기 가능한 폴더 확인하기

클라이언트 다운로드 페이지에서 운영체제와 프로세서 아키텍처를 확인하세요. Windows 데스크톱 버전과 클래식 WPF 버전은 인터페이스 기술이 다르고 필요한 실행 환경도 다를 수 있으므로 설치 패키지 안내와 시작 메시지를 기준으로 판단하세요. 다른 버전의 요구사항을 모든 버전에 동일하게 적용하면 안 됩니다. Linux에서는 deb와 rpm 패키지를 구분하고, macOS에서는 Apple Silicon과 Intel을 먼저 확인하세요. 아키텍처 불일치, 지원되지 않는 운영체제 버전, 누락된 종속성은 서버 설정을 바꿔서 해결할 수 없습니다.

압축 해제 방식의 프로그램을 사용한다면 현재 계정에서 쓸 수 있는 폴더에 파일을 모두 압축 해제하세요. 압축 파일 미리보기 창에서 바로 실행하거나 필수 파일을 제외한 채 주 프로그램만 복사하지 마세요. 설정을 저장할 수 없다면 폴더 권한, 디스크 여유 공간, 동기화 프로그램의 파일 잠금을 확인하세요. 보안 소프트웨어가 차단했다면 기록을 확인해 어떤 파일을 처리했는지 파악하세요. 프로그램을 실행하려고 기기 보호 기능을 통째로 끄거나, 출처를 알 수 없는 곳에서 누락된 구성 요소라고 주장하는 파일을 내려받지 마세요.

코어 시작 오류는 로그에 처음 나타난 오류부터 해결하세요

그래픽 인터페이스는 정상인데 코어가 시작되지 않는다면 마지막의 “중지됨” 메시지가 아니라 로그에서 가장 먼저 발생한 오류를 확인하세요. 포트 충돌, 설정 구문 오류, 알 수 없는 필드, 지리 데이터 파일 누락, 권한 부족은 각각 해결 방법이 다릅니다. 로컬 수신 포트가 사용 중이라면 어떤 프로세스가 점유 중인지 먼저 확인하세요. 정체를 알 수 없는 시스템 서비스를 바로 종료하지 마세요. Windows에서는 아래 명령으로 포트와 프로세스를 확인할 수 있습니다. 예시 포트는 클라이언트에서 실제 사용하는 값으로 바꾸세요.

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

Get-Process -Id 1234

두 번째 명령의 프로세스 ID는 예시일 뿐입니다. 첫 번째 명령에서 확인한 값으로 바꾸세요. 점유한 프로세스가 다른 클라이언트 인스턴스라면 중복 인스턴스를 종료하세요. 계속 실행해야 하는 프로그램이라면 로컬 수신 포트를 바꾸고 시스템 프록시와 앱 내 프록시 설정도 함께 변경해야 합니다. 한 곳만 바꾸면 시작 오류가 진입점 연결 실패로 바뀔 수 있습니다. 검색 결과가 없어도 오류가 기본 포트가 아닌 다른 수신 포트를 가리키는지 살펴보세요. 모든 충돌이 같은 포트에서 발생한다고 단정하면 안 됩니다.

설정 오류는 로그가 지목한 대상과 필드를 기준으로 찾으세요. JSON에 쉼표가 더 들어갔거나, 값의 유형이 잘못되었거나, 따옴표가 닫히지 않으면 파싱에 실패합니다. JSON 파서가 읽을 수 있어도 코어가 요구하는 필드 형식과 일치한다는 보장은 없습니다. 사용자 지정 설정은 사용하는 코어와 호환되어야 합니다. Xray와 V2Fly의 필드 지원을 서로 바꿔 적용할 수는 없습니다. 클라이언트가 생성한 실행 설정은 재시작 후 덮어쓰일 수 있으므로 클라이언트 설정이나 사용자 지정 구성 입력란에서 수정하세요. 임시 출력 파일만 편집하지 마세요.

최소 설정으로 사용자 데이터 문제인지 확인하기

복구하기 전에 구독 그룹, 라우팅, 사용자 지정 DNS, 필요한 사용자 설정을 백업하고 구독 인증 정보를 안전하게 보관하세요. 프로그램을 종료한 뒤 클라이언트가 지원하는 방법으로 별도 설정 폴더를 사용하거나 기존 폴더의 이름을 바꿔 최소 설정으로 테스트하세요. 프로그램이 실행 중일 때 데이터베이스를 이동하지 마세요. 깨끗한 설정에서 시작할 수 있다면 설정을 하나씩 복원하세요. 서버 하나를 먼저 복원해 연결을 확인한 뒤 라우팅과 고급 설정을 가져옵니다. 기존 데이터를 한꺼번에 복원하면 문제도 그대로 돌아올 수 있습니다.

최소 설정으로도 계속 충돌한다면 운영체제의 앱 오류 기록, 권한 안내, 실행 환경 정보를 확인한 뒤 재설치를 고려하세요. 문제를 전달할 때는 재현 단계와 오류 문구를 기록하고 인증 정보, 구독 주소, 사용자 폴더에 포함된 민감한 부분을 가리세요. 설정 오류 예시는 코어 시작 실패 로그 진단을 참고하세요. 복구 완료 기준은 창이 열리는 것만이 아닙니다. 코어가 계속 실행되고 로컬 진입점에 연결할 수 있으며, 종료 후 다시 실행해도 설정이 올바르게 유지되어야 합니다.

08 / VPN 권한 → 앱 범위 → 백그라운드 실행 → 네트워크 전환

Android 문제: 연결 및 백그라운드 연결 끊김

Android에서는 주로 v2rayNG를 사용하고, V2Fly 코어가 필요한 경우에만 v2flyNG를 고려하세요. 두 앱은 지원하는 설정과 필드가 다를 수 있으므로 문제를 해결하려고 복잡한 구성 전체를 그대로 서로 가져오지 마세요. 설치 패키지가 기기 아키텍처에 맞는지 먼저 확인하세요. 최근 기기 대부분은 arm64를 사용하지만 정확한 값은 기기 운영체제를 기준으로 해야 합니다. 확인할 수 없다면 다운로드 페이지의 범용 패키지 안내를 살펴보세요. 설치에 실패하면 먼저 시스템이 표시하는 이유를 확인하세요. 설치 패키지를 수정하거나 시스템 서명 검사를 우회하지 마세요.

VPN 권한을 허용한 뒤에도 원격 연결을 확인하세요

처음 연결할 때 시스템 VPN 권한을 허용하고, 시스템에 해당 연결이 표시되는지 확인하세요. 다른 VPN 앱이 실행 중이라면 먼저 연결을 해제한 뒤 v2rayNG를 테스트하세요. Android에서는 일반적으로 같은 사용자 또는 프로필 환경에서 일반 VPN 서비스를 하나만 사용할 수 있습니다. 두 앱이 번갈아 연결을 가져가면 원인을 알기 어려운 연결 끊김이 발생할 수 있습니다. 시스템의 열쇠 아이콘은 로컬 VPN 서비스가 설정되었다는 뜻이지 서버 인증에 성공했거나 구독의 모든 구성을 사용할 수 있다는 뜻은 아닙니다.

v2rayNG에서 테스트할 구성을 선택해 연결한 다음 앱 로그를 열고 실제 웹사이트를 한 번 방문하세요. 서버 주소를 조회하지 못했다는 오류가 나오면 DNS 항목을 확인하고, 핸드셰이크에 실패했다면 서버 연결 시간 초과 항목에 따라 전송 및 보안 설정을 점검하세요. 비교 테스트가 필요하면 같은 구성을 사용해 Wi-Fi와 모바일 데이터에서 각각 확인하세요. 네트워크를 바꾸면서 서버까지 함께 변경하지 마세요. 모바일 데이터 이용 제한, 로밍 권한, 시스템의 네트워크 사용 제어도 결과에 영향을 줄 수 있으므로 시스템 설정에서 각각 확인해야 합니다.

앱별 프록시와 시스템의 비공개 DNS 확인하기

특정 앱에서만 접속할 수 없다면 앱별 프록시 설정을 열고 현재 “선택한 앱만 프록시 사용”과 “선택한 앱은 프록시 우회” 중 어떤 방식인지 확인하세요. 같은 앱을 선택해도 두 설정은 결과가 반대입니다. 대상 앱이 업무 프로필, 앱 복제 환경 또는 다른 사용자 공간에 있는지도 살펴보세요. 이런 환경은 현재 VPN의 트래픽 적용 범위에서 제외될 수 있습니다. 앱 목록을 변경한 뒤에는 클라이언트 안내에 따라 연결을 다시 설정하고 대상 앱을 완전히 종료했다가 실행해 기존 연결이 이전 경로를 재사용하지 않도록 하세요.

시스템의 “비공개 DNS” 또는 “전용 DNS” 이름은 기기에 따라 다릅니다. 이 설정은 클라이언트 내장 DNS, 브라우저 보안 DNS와 함께 도메인 조회에 사용될 수 있습니다. 특정 네트워크에서만 문제가 생긴다면 기존 설정을 기록한 뒤 시스템 자동 모드로 잠시 바꾸어 비교하고, 클라이언트의 도메인 정책과 DNS 서버 연결 여부를 확인하세요. 세 곳의 설정을 동시에 바꾸면 연결이 복구되어도 어떤 항목이 원인이었는지 알 수 없습니다. 웹사이트는 열리지만 특정 앱만 실패한다면 앱 자체의 프록시와 네트워크 제한도 확인하세요.

화면을 잠근 뒤 연결이 끊기면 백그라운드 제한부터 확인하세요

화면이 켜져 있을 때는 정상인데 잠금 후 일정 시간이 지나면 연결이 끊긴다면 배터리 최적화, 백그라운드 활동 권한, 자동 시작 제한, 시스템 데이터 절약 모드를 확인하세요. 클라이언트가 백그라운드에서 계속 실행되도록 허용하고, 백그라운드 모바일 데이터 사용이 차단되어 있지 않은지도 살펴보세요. 기기 제조사마다 메뉴 위치가 다르므로 현재 시스템 메뉴에 맞게 설정하면 됩니다. 최근 앱 목록에 앱을 고정하는 것만으로 필요한 백그라운드 권한이 모두 허용되는 것은 아닙니다. 잠금 전후의 로그와 연결 상태를 비교해 서비스가 종료되는지 확인하세요.

시스템에서 상시 VPN을 지원한다면 기본 연결이 안정된 뒤 활성화를 검토하세요. “VPN에 연결되지 않으면 연결 차단”을 켜면 연결이 끊긴 뒤 네트워크 동작이 달라집니다. 클라이언트가 중지되었을 때 일반 네트워크 접속도 시스템에서 차단할 수 있습니다. 문제를 진단하는 동안 이 설정의 상태를 기록해 시스템의 차단 동작을 서버 문제로 오인하지 않도록 하세요. 직접 연결을 잠시 복구하려면 해당 정책을 이해하고 조정해야 합니다. 클라이언트의 연결 버튼만 끄는 것으로 해결되지 않을 수 있습니다. 조직의 기기 관리 정책을 적용받는 기기는 관련 규정을 따라야 합니다.

네트워크를 바꾼 뒤 잠시 기다리거나 다시 연결해야 하는 것은 기존 연결, 주소 변경, 시스템 네트워크 복구 때문일 수 있습니다. 전환할 때마다 연결이 완전히 끊긴 채 복구되지 않는다면 VPN이 자동으로 다시 연결되는지, 서버 도메인이 다시 조회되는지, 새 네트워크에서 원격 포트에 접속할 수 있는지 확인하세요. 마지막으로 자주 사용하는 앱에서 실제 접속을 테스트하세요. 앱 내 지연 시간 측정만으로 판단하지 마세요. 처음 가져오기와 연결하는 방법은 설정 가이드를 참고하세요. 설치 형식을 바꿔야 한다면 현재 설정을 백업한 뒤 Android 클라이언트 다운로드 페이지로 이동하세요.