V2Ray 클라이언트
문제 해결

인터넷에 연결되지 않을 때: 기본 네트워크와 프록시 연결을 구분하세요

프록시를 중지하고 기본 네트워크가 정상인지 확인하세요

v2rayN에서는 시스템 프록시를 해제하고 Tun 모드를 끄세요. v2rayNG에서는 연결을 중지하세요. 평소 직접 접속할 수 있는 사이트를 열어 현재 네트워크에 웹 인증이 필요한지 확인합니다. 공용 Wi-Fi는 연결된 것으로 표시되어도 로그인이 끝나지 않았을 수 있습니다. 이 경우 프록시 앱이 실행되더라도 기기가 인터넷에 연결된 것은 아닙니다. 앱을 종료한 뒤에도 접속할 수 없다면 노드 설정을 바꾸지 말고 Wi-Fi 신호, 라우터의 인터넷 연결, 시스템 네트워크 설정부터 확인하세요.

노드와 앱 설정은 그대로 두고 다른 네트워크로 전환해 다시 확인하세요. 예를 들어 Wi-Fi에서 모바일 데이터로 바꾼 뒤 직접 접속이 되는지 확인합니다. 특정 네트워크에서만 실패하면 해당 네트워크의 인증, DNS, 접속 정책을 점검하면 됩니다. 모든 네트워크에서 실패한다면 기기 자체를 확인하세요. 테스트 중에는 VPN, 네트워크 가속 앱, 프록시 기능이 있는 보안 앱 등 트래픽을 처리하는 다른 프로그램을 잠시 중지해 경로 설정이 서로 덮어쓰이지 않도록 하세요.

커널 실행, 노드 연결, 트래픽 처리 순서로 확인하세요

앱을 다시 열고 로그에 커널 종료, 설정 불러오기 실패, 포트 사용 중 오류가 있는지 확인하세요. 화면에 실행 중이라고 표시되어도 프런트엔드만 살아 있고 커널 프로세스는 이미 종료됐을 수 있습니다. 커널이 계속 실행되는 것을 확인한 다음 현재 노드의 실제 연결을 테스트하고 브라우저에서 접속해 보세요. 실제 연결이 실패하면 노드 연결 시간 초과 항목을 확인하세요. 연결은 성공하지만 브라우저에서 접속할 수 없다면 시스템 프록시, 앱별 프록시, DNS를 점검하세요. 바로 프로토콜을 바꿀 필요는 없습니다.

데스크톱에서는 변수를 줄이기 위해 Tun을 잠시 끄고 시스템 프록시 자동 설정만 사용해 볼 수 있습니다. 이 상태에서는 브라우저가 작동하지만 Tun을 켜면 실패한다면 가상 네트워크 어댑터 생성, 실행 권한, 라우팅 충돌을 우선 확인하세요. 반대로 Tun은 되지만 시스템 프록시가 작동하지 않는다면 앱이 시스템 프록시를 사용하는지, 시스템 설정의 주소와 포트가 현재 클라이언트를 가리키는지 확인해야 합니다. 두 방식은 트래픽을 처리하는 위치가 다르므로 한쪽이 정상이라고 다른 쪽 설정까지 올바른 것은 아닙니다.

접속 사례를 몇 가지 비교해 전체 장애인지 특정 사이트 문제인지 구분하세요

서로 다른 사이트 두 곳을 선택하고 다른 앱의 상태도 함께 확인하세요. 한 사이트만 열리지 않는다면 서비스 점검, 계정 제한, 인증서 오류, 해당 사이트에 적용된 라우팅 규칙 문제일 수 있습니다. 브라우저에서 인증서 경고가 표시되면 시스템 날짜와 시간대를 확인하세요. 인증서 검증을 끄는 것은 일반적인 해결 방법이 아닙니다. 한 앱에서만 문제가 생긴다면 앱 자체의 프록시, 별도 DNS, 캐시를 확인하세요. 모든 앱에서 동시에 실패하는 경우 공통 연결 경로나 시스템 트래픽 처리 계층을 점검해야 합니다.

인터넷이 복구되면 먼저 앱을 종료해 시스템 프록시가 정상적으로 해제되는지 확인한 뒤 다시 연결해 테스트하세요. 비정상 종료로 프록시 주소가 남으면 다음에 기기를 켰을 때도 인터넷이 끊긴 것처럼 보일 수 있습니다. 네트워크 설정 전체를 바로 초기화하지 마세요. 오류 발생 시각 전후의 로그와 기존 설정을 먼저 보존하고, 시스템 계층에 문제가 있다는 근거가 있을 때만 점검 범위를 넓히세요. 기본 절차는 첫 연결 점검 노트와 함께 확인할 수 있습니다.

노드 연결 시간 초과: 연결, 핸드셰이크, 테스트 대상을 구분하세요

먼저 시간 초과가 발생한 단계를 확인하세요

노드 목록에서 실제 연결을 테스트한 뒤 로그를 열어 같은 시각의 오류를 찾으세요. 연결 시간 초과는 정해진 시간 안에 특정 단계가 완료되지 않았다는 뜻이지, 서버가 영구적으로 중단됐다는 뜻은 아닙니다. 도메인 DNS 조회 실패, 서버 포트 연결 실패, 암호화 핸드셰이크 실패, 프록시 연결 후 테스트 대상의 응답 없음 등 여러 문제가 테스트 실패로 표시될 수 있습니다. 오류에 나온 단계와 대상 주소부터 확인하세요. 목록의 결과 하나만 보면 서로 다른 원인을 혼동하기 쉽습니다.

로그가 서버 주소 연결 단계에서 멈춘다면 구독이 최근 업데이트됐는지, 해당 노드가 현재 활성 노드인지, 서버 도메인을 조회할 수 있는지 확인하세요. 같은 그룹의 다른 노드로 비교한 다음 네트워크도 바꿔 테스트합니다. 특정 노드만 실패하고 나머지는 정상이라면 해당 설정이나 서버 측 문제일 가능성이 높습니다. 한 그룹 전체가 실패하지만 다른 그룹은 정상이라면 해당 그룹의 서비스 상태를 확인하세요. 모든 그룹에서 실패한다면 모든 노드를 동시에 수정하지 말고 기기 네트워크, 시스템 시간, 클라이언트 커널 실행 상태부터 확인하세요.

포트 연결 성공이 프로토콜 핸드셰이크 성공을 의미하지는 않습니다

포트에 연결할 수 있다는 것은 해당 포트에서 연결을 받아 주는 서비스가 있다는 뜻일 뿐입니다. 사용자 식별자, 전송 방식, 암호화 매개변수가 일치하는지는 확인되지 않습니다. 핸드셰이크 오류가 발생하면 프로토콜 종류, 서버 포트, 전송 유형, TLS 설정, 서버 이름, 경로를 하나씩 확인하세요. WebSocket 같은 전송을 사용한다면 경로와 Host 값도 서버 설정과 일치해야 합니다. REALITY를 사용하는 경우 공개 키, 짧은 ID, 서버 이름을 추측해 입력해서는 안 됩니다. 신뢰할 수 있는 원본 설정을 다시 가져오는 것이 값을 무작위로 바꾸는 것보다 안전합니다.

시스템 설정에서 날짜와 시간을 열고 자동 시간 설정을 켠 다음 다시 시도하세요. 시간이 크게 어긋나면 인증서 유효기간 판정에 영향을 줄 수 있고, 일부 프로토콜 인증도 시간에 의존합니다. 인증서 도메인이 일치하지 않는다면 서버 이름과 서비스 제공자의 안내를 확인하세요. 안전하지 않은 연결을 허용하도록 바로 변경하지 마세요. 오래된 클립보드에서 설정을 가져왔다면 줄바꿈, 전각 문자, 이전 포트가 섞이지 않았는지 확인하세요. 노드를 직접 수정하기 전에 백업해 다시 가져온 항목과 비교할 수 있도록 하세요.

테스트 주소와 실제 사용 환경의 차이를 확인하세요

실제 연결 테스트는 보통 프록시를 통해 지정된 대상에 접속합니다. 대상이 일시적으로 응답하지 않거나 응답 방식이 바뀌거나 규칙에 따라 다른 경로로 연결되면 노드가 실패한 것으로 표시될 수 있습니다. 클라이언트 설정에서 테스트 주소를 확인하고 유효한 웹 주소인지 살펴본 다음, 브라우저에서 같은 노드를 사용해 다른 사이트에 접속해 보세요. 성공 여부를 얻으려고 시간 제한을 계속 줄이지 마세요. 테스트 주소에 접속할 수 있다고 인터넷의 모든 서비스가 정상이라는 뜻도 아닙니다.

문제를 더 구체적으로 확인하려면 Windows PowerShell에서 TCP 포트를 검사할 수 있습니다. 아래 명령은 예시 포트를 로컬에서 수신 중인 프로그램이 있는지 확인하는 용도입니다. 원격 서버를 확인하려면 실제 서버 주소와 포트를 입력해야 합니다. 성공으로 표시되어도 프록시 인증까지 성공한 것은 아닙니다. macOS와 Linux에서도 시스템 네트워크 도구로 비슷한 검사를 할 수 있지만, 한 번 점검하려고 도구 모음을 추가로 설치할 필요는 없습니다. 보통 클라이언트 로그만으로도 실패 단계를 파악할 수 있습니다.

Test-NetConnection -ComputerName 127.0.0.1 -Port 10808

같은 노드가 다른 기기에서는 작동한다면 두 기기의 구독 업데이트 시점, 커널 기능, 직접 덮어쓴 설정을 비교하세요. v2rayN, v2rayNG, v2flyNG의 화면이 비슷해도 설정 확장 기능이 모두 호환되는 것은 아닙니다. 서비스 제공자가 준 원본 설정을 보존하고, 단순히 시간 초과라고만 알리는 대신 구체적인 핸드셰이크 오류와 발생 시각을 전달하면 문제를 파악하기 쉽습니다. 사용자 ID, 구독 주소, 전체 서버 정보가 포함된 로그를 공개하지 마세요.

구독 업데이트 실패: 다운로드 오류와 콘텐츠 가져오기 오류를 구분하세요

구독 그룹의 주소와 업데이트 방식을 먼저 확인하세요

v2rayN에서는 구독 그룹 → 구독 그룹 설정을 열어 주소가 온전한지 확인하세요. v2rayNG에서도 구독 그룹 설정에서 같은 항목을 확인합니다. 링크 일부만 복사했거나 안내 문구까지 함께 복사했거나 앞뒤 공백이 들어가는 경우가 흔합니다. 구독 주소에는 개인 접근 정보가 포함될 수 있으므로 기기에서만 확인하고 공개 변환 도구에 입력하지 마세요. 서비스 제공자가 주소를 새로 발급했다면 이전 주소는 만료됐을 수 있으니 현재 유효한 주소를 다시 복사해야 합니다.

업데이트 오류가 시간 초과, DNS 조회 실패, 인증서 문제, 서버의 접근 거부 중 무엇인지 먼저 확인하세요. 시간 초과라면 현재 네트워크를 확인하고, DNS 조회 실패라면 DNS 항목을 참고하세요. 인증서 문제는 시스템 시간과 인증서 오류 내용을 확인해야 합니다. 접근이 거부되거나 리소스를 찾을 수 없다면 계정 상태, 주소 만료 여부, 서비스 제공자의 접속 주소 변경 여부를 확인하세요. 계정 권한을 확인하려고 업데이트 버튼을 계속 누르지 마세요. 같은 결과를 반복해도 새로운 단서는 얻을 수 없습니다.

직접 연결과 프록시 연결을 통한 업데이트를 각각 확인하세요

구독 업데이트에도 인터넷 연결이 필요합니다. 현재 선택한 노드가 작동하지 않는데 업데이트도 프록시를 사용하도록 설정되어 있으면 새 노드를 받으려면 먼저 작동하는 노드가 필요한 순환 문제가 생깁니다. 먼저 클라이언트에서 프록시 없이 업데이트하는 옵션을 사용해 보세요. 직접 연결은 실패하지만 사용할 수 있는 다른 연결이 있다면 그 연결을 유지한 채 프록시를 통해 업데이트를 시도합니다. 메뉴 이름은 빌드마다 다를 수 있습니다. 중요한 것은 버튼만 바꾸는 데 그치지 않고 실제 요청이 어떤 경로를 거치는지 로그에서 확인하는 것입니다.

업데이트가 성공으로 표시되더라도 노드 콘텐츠를 받았는지 확인하세요. 일부 네트워크는 구독 요청을 Wi-Fi 로그인 페이지로 리디렉션하고, 서비스는 계정 만료 안내나 일반 웹페이지를 반환할 수 있습니다. 다운로드 요청 자체는 완료됐지만 파서가 콘텐츠를 노드로 변환하지 못하는 상황입니다. 클라이언트에서 업데이트 로그를 볼 수 있다면 지원하지 않는 형식, 유효한 서버 없음, 빈 콘텐츠 같은 메시지를 확인하세요. 기기의 브라우저에서 로그인 페이지가 반환됐는지 확인할 수 있지만, 인증 정보가 포함된 전체 화면을 저장하거나 공유하지 마세요.

기존 그룹은 유지하고 소규모 가져오기로 형식을 확인하세요

먼저 기존 그룹 전체를 삭제하지 마세요. 계속 사용할 수 있는 설정을 보존하고 필요하면 보호된 개인 폴더에 내보낸 뒤, 테스트용 그룹을 새로 만들어 같은 구독을 가져오세요. 새 그룹은 가져오기에 성공하지만 기존 그룹은 실패한다면 필터, 자동 정렬, 별칭, 덮어쓰기 옵션을 확인하세요. 두 그룹 모두 실패한다면 서비스 제공자가 해당 클라이언트에서 읽을 수 있는 형식을 제공하는지 확인하세요. 일반 설정 파일, 단일 공유 링크, 통합 구독은 서로 다른 입력 형식입니다. 링크의 모양만 보고 용도를 판단할 수 없습니다.

구독을 업데이트하면 이후 자동 생성되는 설정에 영향을 줄 수 있습니다. 중요한 수동 변경을 구독 노드에 직접 적용하면 다음 업데이트에서 덮어써질 수 있습니다. 계속 유지해야 하는 설정은 클라이언트에서 별도의 덮어쓰기나 사용자 지정 설정 기능을 지원하는지 먼저 확인하세요. 업데이트가 끝나면 활성 노드가 남아 있는지 확인하고 유효한 항목을 다시 선택한 뒤 실제 연결을 테스트합니다. 노드 수가 바뀌는 것 자체는 오류가 아닙니다. 서비스 제공자가 항목을 추가하거나 제거했을 수 있으므로 유효한 설정과 실제 연결 여부로 판단하세요.

새로운 프로토콜 조합만 가져오지 못한다면 설치 파일 페이지에서 사용할 클라이언트를 확인한 뒤 해당 클라이언트의 설정 지원 문서를 살펴보세요. Android에서는 기본적으로 v2rayNG를 사용하고, 관련 커널 설정이 필요한 경우에만 v2flyNG를 고려하세요. 커널 계열마다 확장 필드가 다르므로 앱 이름만 바꾸면 호환된다고 가정해서는 안 됩니다. 일반적인 가져오기 방법과 구독 개념은 FAQ에서도 확인할 수 있습니다. 형식 문제를 모든 노드의 오류로 오해하지 마세요.

속도 저하: 첫 응답 대기와 지속 전송을 구분하세요

어느 구간에서 느린지 파악한 뒤 테스트 방법을 정하세요

웹페이지를 처음 열 때 오래 기다리지만 열린 뒤에는 빠른 경우와 대용량 파일 다운로드가 계속 느린 경우는 서로 다른 문제입니다. 전자는 DNS 조회, 연결 설정, 핸드셰이크를 확인해야 하고, 후자는 대역폭, 패킷 손실, 서버 부하, 트래픽 정책과 관련이 있을 수 있습니다. 백그라운드 다운로드, 클라우드 동기화, 동영상 재생을 중지하고 노드 하나, 앱 하나, 같은 테스트 파일을 기준으로 삼으세요. Wi-Fi 신호가 불안정하면 공유기 가까이에서 테스트하고, 데스크톱에서는 가능하면 유선 네트워크를 사용해 로컬 무선 재전송을 프록시 성능 문제로 오인하지 않도록 하세요.

직접 연결로 접속할 수 있는 동일한 리소스를 기준으로 삼은 뒤 프록시를 통해서도 접속해 보세요. 리소스 자체에 속도 제한이 있으면 연결이 정상이어도 출구 성능을 제대로 판단할 수 없습니다. 사이트마다 콘텐츠 전송 경로가 다를 수 있으므로 같은 다운로드 주소도 서로 다른 경로로 연결될 수 있습니다. 한 번의 테스트는 그 시점의 연결 경로만 보여 줍니다. 실제 연결 테스트에 걸린 시간을 다운로드 속도로 간주하지 마세요. 연결 요청을 설정하는 데 걸린 시간일 뿐 장시간 전송 중의 혼잡이나 안정성을 측정하지 않습니다.

변수를 고정하고 노드, 네트워크, 시간대를 비교하세요

같은 네트워크에서 노드를 바꿔 보고, 그다음 노드를 유지한 채 네트워크를 바꾼 뒤 다른 시간대에 다시 테스트하세요. 이렇게 하면 서버 출구, 로컬 네트워크, 혼잡 시간대의 영향을 각각 살펴볼 수 있습니다. 특정 노드만 느리다면 해당 노드의 서비스 상태를 확인하세요. 특정 Wi-Fi에서 모든 노드가 느리다면 신호, 라우터 부하, 통신 경로를 우선 점검하세요. 모든 기기에서 같은 대상에 접속할 때 느리다면 대상 사이트나 공통 출구를 고려해야 합니다. 매번 현상을 기록하면 충분하며 오랫동안 회선을 가득 채워 테스트할 필요는 없습니다.

라우팅 규칙도 속도에 영향을 줍니다. 직접 접속할 수 있는 리소스가 더 멀리 있는 프록시 출구를 거치거나, 페이지 본문은 직접 연결되지만 이미지와 API는 프록시를 거치면 일부 콘텐츠가 멈춘 것처럼 보일 수 있습니다. 현재 라우팅 모드, 규칙 순서, 로그에 기록된 대상 경로를 확인하세요. 비교를 위해 잠시 단순한 라우팅 설정을 사용할 수 있지만 테스트 후 원래 설정으로 되돌리세요. 규칙 오류를 가리려고 항상 전체 프록시를 사용하지 마세요. 특정 사이트가 빨라졌다고 모든 앱에 같은 모드가 적합한 것도 아닙니다.

트래픽 처리 계층이 원인일 때만 Tun과 MTU를 조정하세요

Tun을 끄면 브라우저 전송은 정상인데 켜면 대용량 파일 전송이 멈춘다면 가상 네트워크 어댑터, 다른 VPN, MTU를 추가로 확인해야 합니다. 경로에 따라 MTU가 너무 크면 패킷 분할이나 재전송이 발생할 수 있지만 모든 속도 저하의 원인이 MTU인 것은 아닙니다. 먼저 현재 값을 기록하고 소폭 조정한 뒤 같은 리소스로 다시 테스트하세요. 개선이 일관되게 나타나지 않으면 원래 값으로 복구합니다. MTU, DNS, 전송 매개변수, 커널을 한 번에 모두 바꾸지 마세요. 문제가 해결되더라도 무엇이 효과가 있었는지 알 수 없습니다.

동영상, 게임 등의 앱은 UDP나 QUIC을 사용할 수도 있습니다. 웹페이지의 TCP 요청이 정상이라고 같은 연결에서 UDP도 정상이라는 뜻은 아닙니다. 이런 서비스에서만 문제가 생긴다면 노드와 클라이언트의 트래픽 처리 방식이 해당 트래픽을 지원하는지, 앱이 다른 전송 방식으로 자동 전환하는지 확인하세요. 브라우저의 실험 기능을 끄는 것은 단기 비교에는 쓸 수 있지만 모든 사용자가 적용할 최적화 방법은 아닙니다. 측정 결과를 바꾸려고 관련 없는 시스템 설정까지 변경하지 마세요.

기기 리소스 사용량도 확인하세요. 규칙이 많거나 로그를 자주 기록하거나 연결을 동시에 많이 사용하면 성능이 낮은 기기의 CPU나 저장 장치가 병목이 될 수 있습니다. 점검 중에는 반복 측정을 중단하고 불필요한 디버그 로그를 끈 뒤 일반 사용 상태를 관찰하세요. 시스템 보안을 끄는 것은 속도 개선 방법이 아닙니다. 프록시를 공유한다면 다른 기기가 출구를 함께 사용 중인지 확인하세요. 관련 범위와 수신 설정은 로컬 네트워크 공유 설정 노트를 참고하세요. 서버 혼잡이 원인으로 확인되면 클라이언트 설정을 조금 바꿔도 해결되지 않을 수 있습니다. 사용 가능한 다른 출구를 선택하거나 시간대와 테스트 조건을 서비스 제공자에게 알려 주세요.

DNS 문제: 누가 어디에서 DNS 조회를 하는지 확인하세요

도메인 조회 실패가 프록시 서버 장애를 뜻하는 것은 아닙니다

로그에 DNS 조회 실패, 호스트를 찾을 수 없음, 반복적인 조회 대기가 표시되면 먼저 프록시 서버 도메인과 최종 접속 대상 도메인 중 어느 쪽에서 실패했는지 구분하세요. 전자는 프록시 연결을 설정하기 전에 발생합니다. 프록시가 연결되기 전에는 조회할 수 없는 도메인을 프록시로만 조회하도록 설정하면 의존성 순환이 생길 수 있습니다. 후자는 클라이언트 DNS 설정, 라우팅 정책, 대상 앱의 DNS 조회 방식을 확인해야 합니다. 브라우저에서 로딩 표시가 계속된다는 사실만으로 로컬 DNS와 원격 DNS 중 어느 쪽에 문제가 있는지 알 수는 없습니다.

Windows 터미널에서 아래 명령을 실행해 시스템 DNS 조회 결과를 확인할 수 있습니다. 공개 문서용 도메인을 사용하므로 시스템 DNS의 기본 동작만 검사합니다. 주소가 반환되어도 웹페이지 접속이 보장되는 것은 아니며 프록시 커널이 같은 DNS 경로를 사용한다는 뜻도 아닙니다. 시스템 조회는 성공했는데 클라이언트 로그에 DNS 오류가 표시된다면 커널 설정의 DNS 서버 주소, 조회에 사용되는 출구, 도메인 정책을 확인하세요. 브라우저 기록을 반복해서 지우는 것으로 원인 파악을 대신하지 마세요.

nslookup example.com

시스템, 브라우저, 클라이언트의 세 가지 DNS 설정을 확인하세요

시스템 네트워크 설정에서 DNS 항목을 열고 자동으로 가져오는지 직접 지정했는지 기록하세요. 다음으로 브라우저의 보안 DNS 사용 여부와 클라이언트에 별도 DNS가 설정되어 있는지 확인합니다. 세 설정이 동시에 적용되면 같은 도메인도 서로 다른 결과를 반환할 수 있고 예상한 분할 라우팅을 우회할 수도 있습니다. 점검할 때는 명확한 DNS 경로 하나를 선택하고 불필요한 개별 설정을 잠시 끈 뒤 테스트하세요. 이후 설정을 하나씩 복구합니다. 회사나 학교 네트워크에서 내부 도메인을 사용한다면 필요한 내부 DNS도 유지해야 합니다.

암호화 DNS를 사용하려면 DNS 서비스 자체의 주소에 연결할 수 있어야 합니다. 그 주소도 도메인이라면 먼저 기본 DNS 조회를 완료해야 합니다. 규칙에 따라 아직 연결되지 않은 프록시를 거쳐야 한다면 다시 순환 문제가 생길 수 있습니다. 이때는 DNS 서비스를 더 추가하지 말고 클라이언트 문서에 따라 연결 가능한 부트스트랩 DNS와 출구를 설정하세요. 서버 수를 늘린다고 항상 안정성이 향상되는 것은 아닙니다. 잘못된 병렬 조회와 라우팅은 결과의 출처를 오히려 파악하기 어렵게 만듭니다.

라우팅을 고려해 DNS 조회와 연결의 관계를 확인하세요

아래는 커널 설정의 DNS 및 라우팅 일부로, 필드 간 관계를 이해하기 위한 예시입니다. 클라이언트에 바로 가져올 수 있는 완전한 설정 파일은 아닙니다. 도메인 서버 목록과 필요에 따른 조회 정책을 보여 주며, 실제로 실행하려면 인바운드, 아웃바운드 등 필요한 설정이 모두 있어야 합니다. 그래픽 클라이언트를 사용한다면 자동 생성 파일을 직접 편집하지 말고 해당 클라이언트의 설정을 우선 변경하세요. 재시작하거나 노드를 바꾸면 파일 내용이 다시 생성될 수 있습니다. 커널마다 지원하는 필드도 따로 확인해야 합니다.

{
  "dns": {
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch"
  }
}

도메인 기반 규칙은 DNS 조회 전에 출구를 결정할 수 있고, IP 주소 집합을 기준으로 하는 규칙은 먼저 IP를 알아내야 할 수 있습니다. DNS 결과, 규칙 순서, 연결 대상을 함께 살펴봐야 합니다. 직접 접속한 IP에서 연결에 실패해도 바로 DNS 오류라고 단정할 수 없습니다. 많은 사이트는 올바른 도메인과 TLS 서버 이름에 의존하므로 IP를 직접 입력하는 것은 같은 요청이 아닙니다. 대상 서비스의 동작을 이해한 경우에만 IP 단위 테스트가 진단에 도움이 됩니다.

DNS 설정을 바꾼 뒤에도 이전 결과가 시스템, 브라우저, 앱 캐시에 남아 있을 수 있습니다. Windows에서는 새 설정이 적용됐는지 확인한 뒤 아래 명령을 실행하고 문제가 있던 앱을 재시작해 새 요청을 보내세요. 캐시를 지우면 새 DNS 조회가 이루어질 뿐, 연결할 수 없는 DNS 서버가 복구되지는 않습니다. 특정 네트워크에서만 도메인 조회에 실패한다면 해당 네트워크의 DNS와 인증 상태를 비교하세요. Tun을 켰을 때만 실패한다면 DNS 트래픽 처리, 가상 네트워크 어댑터 라우팅, 다른 네트워크 도구와의 충돌을 확인하세요.

ipconfig /flushdns

시스템 프록시가 작동하지 않을 때: 앱의 연결 경로와 수신 주소를 확인하세요

먼저 클라이언트와 시스템이 같은 포트를 가리키는지 확인하세요

v2rayN에서 시스템 프록시 자동 설정을 선택한 뒤 시스템 네트워크 설정의 프록시 페이지를 열어 주소가 로컬 루프백 주소인지, 포트가 클라이언트의 실제 수신 포트와 일치하는지 확인하세요. 일반적으로 로컬 포트로 10808을 사용할 수 있지만 현재 설정을 기준으로 해야 합니다. 안내에 적힌 포트 번호를 그대로 덮어쓰지 마세요. 커널이 실행되지 않았거나 다른 프로그램이 수신 포트를 사용 중이거나 시스템에 이전 포트가 저장되어 있으면 프록시가 켜져도 접속에 실패할 수 있습니다. 원격 노드를 점검하기 전에 로컬 연결 경로가 열려 있는지 확인하세요.

클라이언트 설정에서 수신 포트가 어떤 프록시 프로토콜을 지원하는지도 확인해야 합니다. 앱에서 HTTP 프록시를 선택했지만 해당 포트가 SOCKS만 받거나 그 반대라면 연결이 즉시 실패하거나 비정상적인 응답이 반환될 수 있습니다. 일부 빌드는 여러 프록시 프로토콜을 받을 수 있는 혼합 포트를 제공하고, 다른 빌드는 프로토콜마다 포트를 따로 설정합니다. 포트 번호만으로 프로토콜 종류를 판단하지 마세요. 로컬 네트워크 수신과 루프백 수신도 다릅니다. 기기 자체에서 사용할 때는 일반적으로 로컬 네트워크 연결을 허용할 필요가 없습니다.

시스템 프록시는 시스템 설정을 사용하는 앱에만 적용됩니다

브라우저는 시스템 프록시를 사용할 수도 있고 자체 프록시나 확장 프로그램을 사용할 수도 있습니다. 먼저 프록시 확장 프로그램을 일시 중지하고 브라우저에서 시스템 설정 사용 여부를 확인한 뒤 새 페이지를 열어 로그를 살펴보세요. 클라이언트 로그에 요청이 없다면 트래픽이 로컬 연결 경로로 들어오지 않았을 수 있습니다. 명령줄 도구, 게임, 일부 데스크톱 앱은 시스템 프록시를 사용하지 않을 수 있습니다. 앱 자체의 네트워크 설정을 확인하세요. 브라우저가 정상이라고 모든 프로그램이 자동으로 클라이언트를 거치는 것은 아닙니다.

명시적으로 프록시를 지정한 요청과 일반 요청을 비교할 수 있습니다. 아래 명령을 사용하려면 로컬 10808 포트에서 HTTP 프록시를 받아야 하며 커널과 활성 노드도 실행 중이어야 합니다. 현재 포트나 프로토콜이 다르면 실제 설정에 맞게 수정하세요. Windows PowerShell에서는 별칭 차이를 피하기 위해 시스템에서 제공하는 curl.exe를 사용하세요. 명시적 요청은 성공하지만 일반 브라우저 요청은 실패한다면 시스템 및 브라우저 연결 경로를 확인하세요. 두 요청 모두 실패한다면 수신 포트, 노드, DNS를 확인하고 트래픽 처리 범위를 바로 넓히지 마세요.

curl.exe --proxy http://127.0.0.1:10808 --head https://example.com/

시스템 프록시, 자동 설정 스크립트, Tun을 구분하세요

시스템 프록시 페이지에는 수동 프록시, 자동 설정 스크립트, 자동 감지가 함께 표시될 수 있습니다. 이전 스크립트 주소나 다른 프로그램이 쓴 설정이 남아 있으면 실제 연결 경로가 화면에 표시된 예상과 다를 수 있습니다. 현재 상태를 기록하고 프록시를 변경하는 다른 도구를 중지한 뒤 이번 점검에 필요한 방식 하나만 사용하세요. 조직 정책으로 관리되는 기기는 설정 변경이 금지되거나 자동으로 복구될 수 있습니다. 이런 제한은 기기 관리자에게 문의해야 하며 권한을 반복해서 높여 정책을 우회해서는 안 됩니다.

시스템 프록시를 사용하지 않는 앱의 트래픽까지 처리해야 할 때만 Tun을 고려하세요. 켜기 전에 일반 프록시로 현재 노드에 접속할 수 있는지 확인합니다. Tun을 켠 뒤 가상 네트워크 어댑터가 생성되는지, 기본 라우팅이 바뀌는지, 로그에 권한 오류가 표시되는지 살펴보세요. 다른 VPN, 가상 머신 네트워크, 보안 프로그램도 라우팅에 영향을 줄 수 있습니다. 충돌이 생기면 관련 프로그램 하나씩만 중지해 비교하세요. 로컬 네트워크 연결 허용은 Tun 사용의 전제 조건이 아닙니다. 두 설정은 서로 다른 문제를 해결합니다.

종료하기 전에 시스템 프록시 지우기를 사용하고 시스템 페이지에서 원래 상태로 복구됐는지 확인하세요. 클라이언트가 충돌한 적이 있다면 시스템이 이미 중지된 로컬 포트를 계속 가리킬 수 있습니다. 남아 있는 프록시 설정을 직접 해제한 뒤 클라이언트를 정상적으로 다시 시작하세요. 복구 중에는 이전 값을 기록해 두세요. 업무 환경에서 원래 프록시를 사용했다면 모든 항목을 바로 삭제해서는 안 됩니다. 시스템 프록시와 라우팅의 기본 차이는 빠른 시작 가이드에서 확인할 수 있습니다. 플랫폼별 클라이언트 차이를 확인하려면 클라이언트 비교를 살펴보고 다른 운영체제의 설정을 그대로 복사하지 마세요.

앱 충돌: 먼저 상태를 보존한 뒤 설정을 분리해 확인하세요

화면 종료, 커널 종료, 백그라운드 중지를 구분하세요

창이 보이지 않는다고 프로그램이 충돌한 것은 아닙니다. 트레이로 최소화됐을 수도 있습니다. 반대로 화면이 열려 있어도 커널이 정상 실행 중이라는 보장은 없습니다. 먼저 작업 표시줄, 시스템 트레이, 프로세스 목록을 확인한 다음 로그에 새 요청이 계속 기록되는지 살펴보세요. 프런트엔드는 실행 중인데 커널이 반복해서 시작 후 종료된다면 설정, 포트, 권한을 점검하세요. 시작 버튼을 누르는 즉시 프로그램 전체가 닫힌다면 시스템 앱 오류 기록, 실행 환경, 설정 읽기 상태를 확인해야 합니다. Android 백그라운드 중지는 다음 장을 참고하세요. 데스크톱의 해결 방법을 그대로 적용할 수는 없습니다.

자동 재시작이 반복되지 않도록 중지한 뒤 앱 로그와 오류 발생 시각 전후의 시스템 기록을 저장하세요. Windows에서는 이벤트 뷰어의 애플리케이션 로그에서 관련 오류를 찾을 수 있습니다. macOS에서는 시스템에서 제공하는 충돌 보고서를 확인하세요. Linux에서는 데스크톱 실행 메시지와 사용자 로그를 살펴보면 됩니다. 전체 기록을 업로드할 필요는 없습니다. 오류 모듈, 종료 원인, 발생 시각부터 추려 보세요. 로그에 서버 주소, 사용자 ID, 구독 정보가 포함될 수 있으므로 외부에 전달하기 전에 가리되 오류 유형과 문맥 순서는 보존하세요.

프로세서 아키텍처, 설치 방식, 파일 쓰기 권한을 확인하세요

설치 파일 페이지에서 운영체제와 프로세서 아키텍처에 맞는 클라이언트를 선택하세요. 프로그램이 실행되지 않는다고 여러 출처에서 실행 파일과 커널 파일을 섞어 복사하지 마세요. 필요한 구성 요소의 버전이 맞지 않을 수 있습니다. Windows 데스크톱 버전과 기존 WPF 버전은 서로 다른 화면 구성입니다. 안내에 따라 해당 환경에 맞는 실행 방법을 선택하고, 이전하기 전에 기존 설정을 백업하세요. macOS에서는 칩 종류를, Linux에서는 배포판 패키지 형식과 시스템 아키텍처를 확인하세요. 파일 확장자만으로 사용 가능 여부를 판단할 수 없습니다.

프로그램 설치 폴더, 사용자 데이터 폴더, 로그 폴더에 정상적인 쓰기 권한이 있어야 합니다. 읽기 전용 위치, 접근이 제한된 폴더, 디스크 공간 부족, 동기화 프로그램의 파일 점유 때문에 설정 저장이나 커널 실행이 실패할 수 있습니다. 먼저 오류에 표시된 경로를 확인한 뒤 직접 쓸 수 있는 위치로 데이터를 옮기세요. 디스크 전체의 권한을 완화하지 마세요. 보안 프로그램이 차단 알림을 표시하면 알림과 파일 출처를 확인하고 보호 기능 전체를 끄지 마세요. 조직에서 관리하는 기기라면 관리자의 설치 정책을 따라야 합니다.

최소 설정으로 재현하되 기존 데이터를 바로 지우지 마세요

전체 백업을 마친 뒤 클라이언트를 종료하고 데이터 폴더 안내에 따라 별도의 테스트 설정을 만드세요. 클라이언트가 포터블 모드나 독립 데이터 폴더를 공식 지원한다면 해당 방식을 사용하세요. 폴더 매개변수를 추측해서 지정하지 마세요. 테스트 환경에는 정상 작동이 확인된 설정 하나만 가져오고 Tun, 사용자 지정 라우팅, 추가 덮어쓰기 설정은 잠시 해제하세요. 최소 환경에서 실행된다면 원래 설정이나 확장 옵션에 문제가 있을 가능성이 높습니다. 최소 환경에서도 충돌한다면 설치 환경, 아키텍처, 시스템 오류 기록을 확인하세요.

기존 설정을 복원할 때는 구독, 기본 프록시, 라우팅, Tun 순으로 하나씩 추가하고 매번 실행해 테스트하세요. 특정 단계에서 오류가 재현되면 그 단계 전후의 차이를 보존하세요. 설정 구문 오류는 로그에 필드나 위치가 표시되는 경우가 많습니다. JSON을 직접 수정했다면 큰따옴표, 쉼표, 필드 유형을 확인하되 텍스트 바꾸기로 모든 파일을 일괄 수정하지 마세요. 자동 생성 파일에 문제가 있다면 원본 설정도 찾아야 합니다. 원인을 찾지 못하면 다음에 노드를 바꿀 때 같은 오류가 다시 생성될 수 있습니다.

업데이트 후 문제가 시작됐다면 기억에 의존해 버전을 적기보다 업데이트 전후의 UI 종류, 커널 계열, 설정 변경 사항을 기록하세요. 문제를 보고할 때 운영체제, 프로세서 아키텍처, 실행 방법, 재현 절차, 최소 설정에서도 실패하는지 알려 주세요. 절전 모드에서 깨어난 뒤나 네트워크 전환 후 발생했다면 전원 및 네트워크 상태 변화도 추가하세요. 복구 후에는 종료할 때 시스템 프록시가 해제되는지 먼저 확인해 앱의 문제가 전체 네트워크 장애로 이어지지 않도록 하세요. 그다음 자동 시작을 다시 설정하세요.

모바일 문제: VPN 권한, 백그라운드 실행, 앱별 프록시

앱만 열려 있는 것이 아니라 VPN 서비스가 실제로 연결됐는지 확인하세요

v2rayNG에서 연결을 선택하면 처음 실행할 때 시스템 VPN 권한이 필요합니다. 이 권한은 Android VPN 서비스를 통해 기기의 트래픽을 처리하도록 허용하는 것으로, 원격 서버 연결까지 완료됐다는 뜻은 아닙니다. 권한을 허용한 뒤 실행 알림, 앱 로그, 실제 접속을 확인하세요. 권한 요청이 반복된다면 다른 VPN 앱이 실행 중인지, 업무용 프로필이나 기기 관리 정책에서 제한하는지 확인하세요. 일반적으로 한 사용자 환경에서는 VPN 트래픽 처리 앱끼리 충돌할 수 있으므로 다른 앱을 먼저 중지하고 테스트하세요.

설정에서 VPN 모드와 프록시 전용 모드도 구분해야 합니다. VPN 모드는 시스템 인터페이스를 통해 조건에 맞는 앱의 트래픽을 처리합니다. 프록시 전용 모드는 주로 로컬 프록시 연결 경로를 제공하며 각 앱에서 해당 경로를 직접 사용해야 합니다. 프록시 전용 모드를 잘못 선택하면 클라이언트 자체 테스트는 성공해도 일반 앱에는 변화가 없을 수 있습니다. 현재 모드를 기록하고 VPN 모드에서 기본 접속을 확인한 뒤 고급 설정을 검토하세요. 시스템에서 상시 VPN이나 VPN을 거치지 않는 연결 차단을 설정했다면 현재 사용 중인 클라이언트가 지정되어 있는지도 확인하세요.

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

시스템 설정 → 앱 → v2rayNG → 배터리에서 백그라운드 활동이 제한되어 있는지 확인하고 기기에서 제공하는 옵션에 따라 계속 실행을 허용하세요. 제조사에 따라 백그라운드 실행, 자동 시작, 배터리 최적화 등 메뉴 이름과 경로가 다를 수 있습니다. 먼저 앱에 지속 실행 알림이 표시되는지 확인한 뒤 화면 잠금 상태에서 테스트하세요. 알림이 꺼져도 서비스가 반드시 중지되는 것은 아니지만 상태를 확인하기 어려워집니다. 배터리 설정, 시스템 절전 모드, 백그라운드 데이터 제한은 연결 유지에 직접 영향을 줄 수 있습니다.

화면이 켜진 상태, 잠금 화면 상태, 네트워크 전환 후 상태를 각각 기록하세요. 잠근 뒤 한동안 지나서만 실패한다면 백그라운드 제한을 확인하세요. Wi-Fi에서 모바일 데이터로 전환한 뒤 실패한다면 네트워크 복구와 기존 연결 재설정을 확인하세요. 모바일 데이터에서만 실패하고 Wi-Fi는 정상이라면 데이터 절약 모드, 앱의 모바일 데이터 권한, 해당 네트워크 연결 상태를 살펴보세요. 배터리 설정을 바꾼 뒤에는 연결을 다시 시작하고 같은 화면 잠금 조건으로 재시험해야 합니다. 설정이 저장됐다는 이유만으로 문제가 해결됐다고 판단하지 마세요.

앱별 프록시 목록에서 포함과 제외 방향을 확인하세요

v2rayNG에서 설정 → 앱별 프록시를 열고 선택한 앱만 프록시를 사용할지, 선택한 앱을 프록시에서 제외할지 먼저 확인하세요. 두 방식의 목록 방향은 서로 반대입니다. 선택한 앱만 프록시를 사용하도록 설정한 경우 대상 앱을 선택해야 트래픽이 프록시를 거칩니다. 제외 방식에서는 대상 앱이 목록에 없어야 합니다. 브라우저는 정상인데 특정 앱만 작동하지 않는다면 목록에서 해당 앱과 관련 구성 요소가 어떻게 처리되는지 확인하세요. 웹페이지 전환, 계정 로그인, 다운로드는 시스템 구성 요소가 처리할 수 있으므로 모든 단계가 같은 앱에서 실행된다고 가정하지 마세요.

목록 설정 문제인지 확인하려면 앱별 프록시를 잠시 끄고 대상 앱이 기본 트래픽 처리 범위에 포함되도록 한 뒤 VPN 연결을 중지했다가 다시 설정해 테스트하세요. 정상적으로 작동한다면 목록 방향이나 앱 구성 요소 범위를 다시 확인해야 합니다. 계속 실패한다면 앱 자체 프록시, DNS, 대상 서비스, UDP 지원 여부를 살펴보세요. 여러 필터 규칙을 한꺼번에 켜고 추측해서는 안 됩니다. 규칙이 많을수록 트래픽이 제외된 이유를 찾기 어렵습니다. 업무용 프로필과 일반 사용자 환경에는 같은 앱의 별도 인스턴스가 있을 수 있으므로 시스템에서 허용하는 처리 범위도 각각 확인하세요.

네트워크를 전환한 뒤 연결을 다시 설정하고 커널 호환성을 확인하세요

Wi-Fi와 모바일 데이터를 전환하면 로컬 주소, 라우팅, 연결 경로가 바뀌므로 기존 연결이 바로 복구되지 않을 수 있습니다. 먼저 연결을 중지하고 시스템 네트워크가 안정될 때까지 기다린 다음 다시 시작해 실제 연결을 테스트하세요. 특정 네트워크에서만 실패한다면 앱을 반복해서 재설치하지 말고 노드 시간 초과와 DNS 항목을 확인하세요. 로컬 네트워크 주소 우회를 켰다면 로컬 기기 접속을 별도로 테스트해야 합니다. 이 옵션은 로컬 대상 주소의 라우팅을 처리하며 인터넷 노드를 복구하지 않고 앱별 프록시를 대신하지도 않습니다.

Android에서는 v2rayNG를 우선 사용하세요. v2fly 커널 설정이 필요하다면 구체적인 호환성 요구에 따라 v2flyNG를 선택할 수 있습니다. 두 앱 모두 Android 설치 파일 페이지에서 기기 아키텍처에 맞는 파일을 선택하세요. 전환하기 전에 기존 구독과 필요한 설정을 보존하고 두 VPN이 동시에 트래픽 처리를 두고 경쟁하지 않도록 하세요. 프로토콜 확장 기능이 문제라면 고급 설정 전체를 복사하기보다 서비스 제공자에게 어떤 커널용 설정인지 확인하는 편이 안전합니다. 마지막으로 VPN 권한 및 백그라운드 설정 노트를 참고해 화면 잠금, 네트워크 전환, 직접 중지 상태를 각각 테스트하세요. 연결 버튼을 누른 직후뿐 아니라 이후에도 정상적으로 유지되는지 확인해야 합니다.