V2Ray 문제 해결
노드, 구독, 시스템 프록시

인터넷에 연결할 수 없을 때: 기본 네트워크와 프록시 경로 구분하기

‘인터넷에 연결할 수 없음’만으로는 문제를 정확히 파악하기 어렵습니다. 먼저 다음 세 가지를 확인하세요. 프록시를 끄면 일반 웹사이트에 접속할 수 있는지, 프록시를 켜면 모든 웹사이트가 실패하는지, 특정 앱에서만 문제가 발생하는지 기록합니다. 트래픽을 동시에 처리하지 않도록 다른 프록시나 VPN 도구는 잠시 종료하세요. 현재 노드와 라우팅 모드 이름을 기록하고, 이후 테스트에는 같은 페이지를 사용하세요. 노드 변경, 네트워크 전환, DNS 조정을 번갈아 시도하면 어떤 조치가 효과가 있었는지 파악하기 어렵습니다.

프록시를 끄고 직접 연결 상태 확인하기

v2rayN에서 먼저 시스템 프록시를 해제한 다음 TUN 모드를 끄세요. 기본 창만 닫아도 클라이언트가 종료되지 않을 수 있으니 트레이에 백그라운드 프로세스가 남아 있는지 확인합니다. 브라우저를 다시 열어 평소 직접 접속할 수 있는 웹사이트에 연결해 보세요. 이때도 연결되지 않는다면 Wi-Fi, 유선 연결, 게이트웨이, 네트워크 로그인 페이지부터 확인하세요. 공용 네트워크는 먼저 인증해야 사용할 수 있습니다. 기본 네트워크가 복구되기 전에는 노드 설정을 변경하지 마세요. 다른 기기는 같은 네트워크에서 정상인데 현재 PC만 연결되지 않는다면 방화벽, 고정 프록시, 수동 DNS 설정을 확인하세요.

직접 연결이 복구되면 v2rayN을 실행해 노드 목록에 사용할 수 있는 설정이 있는지 확인하고 활성 서버로 선택하세요. 로그에 코어 종료, 설정 파싱 오류, 포트 바인딩 오류가 있는지도 살펴봅니다. 클라이언트 창이 열린다고 해서 그래픽 인터페이스만 실행된 것일 수 있으며, 프록시 코어가 포트를 열었다는 뜻은 아닙니다. 설정에서 실제 로컬 포트를 확인한 뒤 로그에 표시된 수신 주소와 대조하세요. 모든 클라이언트가 같은 포트를 쓴다고 가정하거나 서버 연결 포트를 로컬 프록시 포트로 입력하지 마세요.

로컬 수신과 원격 연결을 따로 확인하기

로컬 HTTP 또는 혼합 포트를 확인한 뒤에는 시스템 프록시 설정을 거치지 않고 프록시를 직접 지정해 테스트할 수 있습니다. 아래 명령어는 Windows PowerShell용이며, 클라이언트의 HTTP 또는 혼합 포트가 10808이라고 가정합니다. 실제 설정이 다르면 해당 포트로 바꾸세요. 테스트 주소는 HTTPS 요청 경로 확인용이며, 실제 서비스 웹사이트에 접속할 수 있다는 뜻은 아닙니다. 해당 포트가 SOCKS만 지원한다면 다음 장의 SOCKS 테스트 방법을 사용하세요. HTTP 매개변수를 그대로 적용하면 안 됩니다.

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

명령어 실행 직후 로컬 주소에 연결할 수 없다는 오류가 뜨면 코어가 실행 중인지, 포트가 일치하는지 먼저 확인하세요. 로컬 프록시에는 연결되지만 이후 원격 핸드셰이크가 실패한다면 노드 항목을 확인합니다. 명령어는 성공하는데 브라우저에서 실패한다면 서버를 계속 바꾸기보다 브라우저 자체 프록시, 확장 프로그램, 시스템 프록시 설정을 확인하세요. 웹사이트가 리디렉션, 액세스 거부 또는 다른 HTTP 상태를 반환한다면 애플리케이션 계층의 응답을 받은 것입니다. 이를 단순히 ‘네트워크 연결 안 됨’으로 처리하지 마세요.

라우팅, 앱, 대상 웹사이트로 범위 좁히기

잠시 클라이언트의 전역 프록시 라우팅으로 전환해 같은 노드로 한 번 더 테스트하세요. 전역 모드에서는 접속되지만 분할 라우팅 모드에서 실패한다면 대상 도메인이 직접 연결 규칙에 걸리는지, 규칙 데이터가 정상적으로 로드되는지, DNS 결과가 IP 규칙에 영향을 주는지 확인하세요. 전역 모드는 진단을 위한 비교 수단이므로 문제를 확인한 뒤 원래 모드로 복구해야 합니다. 특정 앱에서만 실패한다면 시스템 프록시를 따르는 앱인지 확인하세요. 앱 자체 프록시 설정이 필요하거나, 올바른 TUN 또는 VPN 설정으로 트래픽을 처리해야 하는 앱도 있습니다.

복구 후에는 최소 두 가지 접속을 확인하세요. 하나는 직접 연결되어야 하는 페이지, 다른 하나는 프록시를 거쳐야 하는 페이지입니다. 그런 다음 클라이언트를 종료했다가 다시 실행해 설정이 유지되는지 확인하세요. 종료 후 직접 연결이 다시 실패한다면 시스템 프록시나 네트워크 설정이 남아 있을 수 있습니다. 시스템 프록시가 작동하지 않을 때 항목을 이어서 확인하세요. 처음 설정해 익숙하지 않다면 빠른 시작에서 전체 과정을 확인하고, 개념 관련 질문은 자주 묻는 질문을 참고하세요.

노드 시간 초과: 주소, 포트, 핸드셰이크 순서로 확인하기

‘클라이언트 테스트 시간 초과’와 ‘실제 접속 시간 초과’를 구분하세요. 테스트 방식에 따라 TCP 연결, 특정 웹페이지 요청 등 확인하는 항목이 다릅니다. 한 가지 테스트에 실패했다고 노드 전체가 작동하지 않는다고 단정할 수는 없습니다. 브라우저와 프록시를 명시한 명령어를 함께 사용해 확인한 뒤, 특정 노드만 문제인지, 같은 구독의 모든 노드가 문제인지, 출처와 관계없이 모든 노드가 문제인지 판단하세요. 특정 노드만 실패하면 노드 설정이나 서버 상태일 가능성이 높고, 모두 실패하면 PC, 현재 네트워크, 코어 실행 상태부터 확인해야 합니다.

서버 주소와 원격 포트 확인하기

노드 편집 화면에서 서버 주소, 서버 포트, 프로토콜, 전송 방식을 확인하세요. 해당 입력란에 전체 URL을 입력하도록 지정된 경우가 아니라면 주소에 프로토콜 접두사, 경로, 불필요한 공백을 넣지 마세요. 포트는 서비스 제공자가 안내한 접속 포트여야 합니다. 10808을 봤다고 원격 포트도 같은 값으로 바꾸면 안 됩니다. 구독을 업데이트한 직후라면 업데이트된 설정을 선택했는지 확인하세요. 일부 화면은 이전 항목이나 선택 상태를 유지하므로 활성 서버를 다시 선택해야 할 수 있습니다.

Windows PowerShell에서 아래 명령어를 실행하면 지정한 호스트와 TCP 포트의 연결 여부를 확인할 수 있습니다. 예시 도메인은 문서용이므로 실제 점검 시 노드 서버 도메인과 포트로 바꾸세요. 결과는 TCP 연결 여부만 확인하며 프로토콜 인증, 전송 경로, TLS 설정은 검증하지 않습니다. UDP 서비스를 TCP 서비스처럼 판단하는 데에도 사용할 수 없습니다. 연결에 실패하면 먼저 다른 네트워크에서 같은 테스트를 한 뒤 서비스 제공자에게 접속 주소가 변경되었는지 확인하세요.

Test-NetConnection -ComputerName example.com -Port 443

도메인 이름을 확인할 수 없다면 DNS 항목을 먼저 살펴보세요. 이름은 확인되지만 TCP 연결이 실패한다면 네트워크 경로, 원격 서버의 수신 상태, 방화벽, 서비스 중단 등이 원인일 수 있습니다. 로컬 암호화 옵션을 반복해서 변경해도 대개 해결되지 않습니다. TCP 연결은 성공했는데 계속 시간 초과가 발생하면 클라이언트 로그의 핸드셰이크와 인증 정보를 확인하세요. 오류 전후 몇 줄만 남기고, 로그를 공유하기 전에는 구독 주소, 사용자 식별 정보, 인증 항목을 삭제하세요. 전체 설정을 공개하지 마세요.

TLS, 전송 계층, 프로토콜 설정 구분하기

TLS 인증서 오류가 발생하면 시스템 날짜, 시간대, 시간 동기화부터 확인한 뒤 SNI 또는 서버 이름을 점검하세요. 서버 주소와 SNI 값은 다를 수 있으므로 두 값을 무조건 같게 설정하는 방법으로 서비스 제공자의 설정을 대신할 수 없습니다. WebSocket 같은 전송 방식을 사용한다면 경로, Host, 보안 계층도 일치해야 합니다. 경로는 대소문자를 구분할 수 있고 앞의 슬래시도 결과에 영향을 줄 수 있습니다. 핸드셰이크가 종료됐다고 해서 반드시 인증서 문제인 것은 아닙니다. 잘못된 서버 접속 주소로 요청을 보냈을 수도 있습니다.

VLESS, VMess, Trojan은 각각 인증과 전송 요구 사항이 다르므로 프로토콜 이름만 바꾸고 다른 필드를 그대로 사용하면 안 됩니다. REALITY 설정은 서버에서 제공한 공개 키, 짧은 ID, 서버 이름 등의 매개변수도 일치해야 합니다. 원본 설정을 기준으로 삼고 인터넷에서 임의로 값을 조합하지 마세요. 일반적인 해결책이라며 안전하지 않은 연결 허용을 설정하지 마세요. 인증서 검증을 건너뛰어도 잘못된 경로는 해결되지 않으며, 신원 확인만 약해집니다. 인증서 문제는 TLS 핸드셰이크와 시스템 시간 점검을 참고하세요.

변수 하나씩 비교해 문제 원인 확인하기

클라이언트에서 SOCKS 포트를 제공한다면 아래 명령어로 대상 도메인 처리를 프록시에 맡길 수 있습니다. 여기서는 로컬 SOCKS 포트가 10808이라고 가정하므로 먼저 포트 유형을 확인하세요. HTTP 프록시 테스트와 비교하면 앱 프록시 설정이 잘못됐는지 판단하는 데 도움이 됩니다. 다만 모든 라우팅과 DNS 요청이 원격에서 처리된다는 뜻은 아니며, 실제 동작은 코어 규칙에 따라 달라집니다.

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

같은 설정이 다른 네트워크에서 정상 작동한다면 현재 접속 네트워크를 우선 조사하세요. 같은 네트워크에서 노드를 바꾸자 복구됐다면 원래 노드나 해당 경로에 문제가 있을 가능성이 큽니다. 모든 비교 테스트가 실패하면 코어가 설정에 포함된 필드를 지원하는지 확인한 뒤 다운로드 페이지에서 해당 플랫폼용 클라이언트를 선택하세요. 문제를 확인하려고 여러 코어를 무작정 바꾸거나 기존 설정을 덮어쓰지 마세요. 단계별 점검은 노드 시간 초과 문제 해결 가이드에서 확인하고, 문의 시에는 비교 테스트 결과를 함께 제공하세요.

구독 실패: 다운로드 오류와 콘텐츠 파싱 오류 구분하기

구독 업데이트는 콘텐츠를 가져오는 과정과 클라이언트가 지원하는 설정으로 파싱하는 과정, 두 단계로 진행됩니다. ‘업데이트 실패’는 어느 단계에서든 발생할 수 있습니다. 먼저 연결 시간 초과, HTTP 상태 오류, 인증서 오류인지, 형식을 인식할 수 없음 또는 유효한 노드가 없음인지 확인하세요. 앞의 오류는 연결 경로를, 뒤의 오류는 응답 내용과 구독 형식을 점검해야 합니다. 기존 설정과 오류 전후를 비교할 수 없게 되므로 처음부터 구독 그룹 전체를 삭제하지 마세요.

구독 주소와 응답 유형 확인하기

서비스 제공자에게서 구독 주소를 다시 복사하고 앞뒤 공백, 줄바꿈, 메신저가 덧붙인 문장 부호가 있는지 확인하세요. 일부 주소에는 쿼리 매개변수가 포함되어 있어 뒷부분이 빠지면 인증에 실패할 수 있습니다. 복잡해 보이는 매개변수를 임의로 삭제하거나 수정하지 마세요. 계정 페이지, 결제 페이지, 클라이언트 구독 링크는 서로 용도가 다릅니다. 웹페이지를 브라우저에서 열 수 있다고 해서 클라이언트에 가져올 수 있는 구독 링크라는 뜻은 아닙니다. 전체 구독 주소에는 접근 권한이 포함될 수 있으므로 민감 정보로 취급하고 공개 스크린샷, 검색창, 타사 변환 페이지에 입력하지 마세요.

인증되지 않음 또는 접근 금지가 반환되면 구독이 만료됐는지, 링크가 초기화됐는지, 서비스 서버에서 접근 방식을 제한하는지 확인하세요. 리소스를 찾을 수 없다는 응답이 오면 경로가 변경됐는지 확인합니다. 요청은 성공했지만 파싱 결과가 비어 있다면 로그인 페이지, 점검 페이지, 접근 확인 페이지, 오류 안내를 받은 것일 수 있습니다. 성공 상태만 보고 클라이언트가 고장 났다고 판단하지 마세요. 응답 앞부분이 웹페이지 텍스트인지 로컬에서 확인할 수 있지만, 자격 증명이 포함된 전체 내용을 로그나 공개 문의에 복사하지 않도록 주의하세요.

적절한 업데이트 경로 선택하기

현재 네트워크에서 구독 서버에 직접 연결할 수 없지만 사용 가능한 노드가 있다면 해당 노드를 선택한 다음 클라이언트의 프록시를 통한 업데이트 기능을 사용하세요. 일반 업데이트와 프록시 업데이트가 시스템 프록시를 따로 사용하는지는 클라이언트 구현에 따라 다릅니다. 시스템 프록시 스위치만 보고 판단할 수 없습니다. 반대로 클라이언트의 업데이트 요청이 이미 작동하지 않는 노드를 통한다면 직접 연결 업데이트로 바꾸는 편이 나을 수 있습니다. 업데이트 방식만 바꾸고 같은 구독 주소를 유지해야 경로별 차이를 확인할 수 있습니다.

처음 설정하는 중이라 사용할 노드가 없다면 아직 연결되지 않은 프록시로 구독을 가져올 수 없습니다. 접속이 허용된 네트워크에서 다시 시도하거나, 서비스 제공자에게 클라이언트가 지원하는 다른 가져오기 방식을 문의하세요. 실패를 우회하려고 인증서 검증을 무작정 끄거나 출처가 불분명한 구독 변환 서비스를 이용하지 마세요. 업데이트는 적당한 간격으로 실행하세요. 짧은 시간에 반복해서 누르면 서버의 요청 제한에 걸릴 수 있습니다. 명확한 제한 응답이 오면 여러 구독 그룹을 새로 만드는 대신 기다렸다가 다시 시도하세요.

형식, 인코딩, 클라이언트 지원 여부 확인하기

공유 링크, 인코딩된 링크 모음, 구조화된 설정은 서로 다른 형식입니다. 일부 구독 제공자는 클라이언트별로 다른 콘텐츠를 제공하므로 v2rayN, v2rayNG, v2flyNG에 맞는 주소를 선택하세요. 인코딩 데이터를 직접 처리하기 전에는 원문을 보관해 이중 인코딩, 잘림, 줄바꿈의 일반 문자 변환을 방지하세요. 다른 프로그램의 설정 파일은 확장자만 바꿔 가져올 수 없습니다. 파일 이름을 바꿔도 내부 구조는 변하지 않습니다. 지원하지 않는 프로토콜이나 필드라는 오류가 표시되면 클라이언트와 코어의 지원 범위를 확인하세요. 오류 필드를 임의로 삭제하지 마세요.

업데이트 성공 메시지가 표시됐는데 목록이 그대로라면 현재 보고 있는 그룹, 검색 조건, 숨김 규칙을 확인하세요. 즐겨찾기나 다른 필터 결과만 표시되는 것은 아닌지 살펴봅니다. 노드가 삭제된 것은 클라이언트의 가져오기 누락이 아니라 구독 제공자가 목록을 조정했기 때문일 수도 있습니다. 필요한 경우 임시 그룹을 새로 만들어 비교하되 기존 그룹을 바로 덮어쓰지 마세요. 복구 후 노드를 직접 선택해 실제 접속을 확인하세요. 구독 업데이트가 성공해도 노드 연결까지 보장되는 것은 아닙니다. 구체적인 가져오기 방법은 구독 가져오기 가이드를, 콘텐츠 확인 방법은 구독 파싱 오류 자가 점검을 참고하세요.

속도 저하: 연결, 전송 속도, 앱 사용 경험을 따로 측정하기

먼저 어느 단계에서 느린지 구분하세요. 페이지가 열리기까지 오래 걸리는지, 본문이 표시된 뒤 이미지 로딩이 느린지, 다운로드 내내 전송 속도가 낮은지 확인합니다. 연결 대기 시간은 DNS, 핸드셰이크, 대상 서버 응답과 관련될 수 있습니다. 지속적인 전송 속도에는 대역폭, 패킷 손실, 혼잡, 서버 부하도 영향을 줍니다. 클라이언트의 지연 시간은 특정 테스트 방식의 결과일 뿐 사용 가능한 다운로드 대역폭을 의미하지 않습니다. 한 번의 테스트 결과만으로 노드의 장기적인 품질을 판단할 수도 없습니다. 먼저 현재 모드와 노드를 유지한 채 반복 가능한 테스트 환경을 만드세요.

로컬 대역폭과 기기 부하 확인하기

시스템 업데이트, 대용량 다운로드, 클라우드 동기화 등 네트워크를 사용하는 작업을 종료하고 같은 네트워크의 다른 기기도 데이터를 전송 중인지 확인하세요. Wi-Fi 신호가 강해 보여도 간섭이 있을 수 있으므로 공유기 가까이에서 테스트하거나 유선 연결과 비교하세요. 직접 연결도 느리다면 프록시 설정을 계속 바꾸기보다 기본 네트워크부터 해결해야 합니다. 모바일 핫스팟과 유선 네트워크를 비교해 볼 수 있지만, 테스트 시 모바일 데이터 요금과 사용량 제한에 유의하고 대용량 파일을 반복해서 내려받지 마세요.

작업 관리자나 시스템 모니터에서 CPU, 메모리, 디스크 사용량도 확인하세요. 기기 부하가 높거나 저장 공간이 부족하거나 과열되면 브라우저와 클라이언트 응답이 느려질 수 있습니다. 이때 네트워크가 느린 것처럼 보여도 실제 병목은 PC에 있을 수 있습니다. TUN으로 많은 앱의 트래픽을 처리하거나 복잡한 규칙, 잦은 로그 기록을 사용하면 부하가 늘어날 수 있습니다. 먼저 불필요한 작업을 중지한 뒤 일반 시스템 프록시와 TUN 모드를 비교하세요. 검증 기준을 낮추거나 시스템 보호 기능을 꺼서 겉으로만 속도를 높이지 마세요.

노드와 경로를 공정하게 비교하기

노드를 테스트할 때는 대상 웹사이트, 네트워크, 클라이언트 모드, 테스트 시간을 최대한 동일하게 유지하고 한 번에 노드 하나만 바꾸세요. 여러 노드에서 대용량 다운로드를 동시에 진행하면 로컬 대역폭을 서로 나눠 쓰게 됩니다. 지리적으로 가까운 노드가 항상 빠른 것은 아닙니다. 네트워크 간 연결, 원격 출구, 혼잡 상태도 영향을 줍니다. 특정 웹사이트만 느리고 나머지는 정상이라면 해당 사이트, 콘텐츠 전송 경로, 원격 출구에 대한 제한이 원인일 수 있습니다. 모든 프록시 연결의 문제라고 단정하지 마세요.

전역 라우팅은 빠른데 분할 라우팅 모드가 느리다면 느린 요청이 실제로 프록시와 직접 연결 중 어느 쪽을 사용하는지 확인하세요. 웹페이지는 보통 여러 도메인을 사용합니다. 본문은 정상적으로 로드되는데 이미지가 늦게 표시된다면 리소스 도메인이 다른 출구로 연결됐을 수 있습니다. 필요한 범위에서 일시적으로 접속 로그를 켜고 실패하거나 응답이 오래 걸린 리소스 도메인을 확인한 뒤 관련 규칙을 수정하세요. 주소 표시줄에 보이는 기본 도메인만 보고 규칙을 추가하거나, 디스크 공간을 낭비하고 접속 기록이 노출될 수 있는 상세 로그를 다운로드 중 계속 켜 두지 마세요.

연결 다중화, UDP, MTU 범위 확인하기

다중화는 항상 켜야 하는 속도 향상 옵션이 아닙니다. 반복되는 핸드셰이크를 줄일 수 있지만 특정 경로에서는 혼잡을 키우거나 호환성 문제를 일으킬 수 있습니다. 노드 요구 사항을 확인하고 같은 환경에서 켜고 끈 결과를 비교하세요. 웹에서 사용하는 HTTP/3 같은 방식은 UDP를 사용합니다. 시스템 HTTP 프록시가 모든 UDP 요청까지 처리하는 것은 아닙니다. 이 때문에 앱이 다른 연결 방식으로 전환되면서 첫 로딩이 늦어질 수 있습니다. 모든 지연을 노드 대역폭 부족으로 해석하지 말고 앱의 실제 전송 방식과 트래픽 처리 범위를 먼저 확인하세요.

TUN 모드에서만 특정 대형 페이지, 업로드, 장시간 연결이 멈추고 일반 시스템 프록시에서는 정상일 때 MTU를 추가 점검 항목으로 고려하세요. 먼저 기본값을 기록하고 현재 네트워크와 클라이언트 안내를 참고해 조금씩 조정합니다. 값을 바꿀 때마다 연결을 다시 설정하고 테스트하세요. 값이 너무 작으면 패킷 분할과 처리 부하가 늘 수 있습니다. 네트워크 관련 글에 나온 값을 그대로 적용하면 실제 문제를 가릴 수도 있습니다. MTU는 인증 실패, 인증서 오류, 원격 서버 중단을 해결하지 못하므로 기본 연결이 정상임을 확인한 뒤 점검하세요.

복구 여부는 실제 사용 환경을 기준으로 판단하세요. 페이지가 안정적으로 열리는지, 화상 회의나 장시간 연결이 끊기는지, 지속적인 전송 속도가 유지되는지 확인합니다. 특정 시간대에만 느리다면 여러 시간대의 비교 결과를 기록해 서비스 제공자에게 전달하고, PC 설정을 계속 바꾸지 마세요. 첫 접속에서만 대기 시간이 길거나 IP와 도메인 접속 결과가 다르면 다음 장에서 DNS를 확인하세요. 특정 앱만 느리다면 전체 노드를 바꾸기보다 앱 자체 프록시와 분할 라우팅 규칙을 점검하세요.

DNS 문제: 이름 확인 위치와 요청 경로 파악하기

DNS는 도메인 이름을 IP 주소로 변환하지만, 한 번의 접속에도 시스템 리졸버, 브라우저 보안 DNS, 클라이언트 내장 DNS, 프록시 서버 측 DNS가 함께 관여할 수 있습니다. 도메인으로 접속되지 않지만 다른 연결은 정상이라면 어느 단계에서 실패하는지 먼저 확인하세요. 로그에 표시된 서버 도메인 확인 실패와 대상 웹사이트 도메인 확인 실패는 다른 문제입니다. 전자는 프록시 연결 자체를 막을 수 있고, 후자는 출구를 선택한 뒤 발생할 수 있습니다. 공용 DNS 주소 하나만 바꿨다고 전체 DNS 경로가 바뀐 것은 아닙니다.

시스템 이름 확인과 캐시부터 점검하기

아래 Windows 명령어로 시스템에서 사용할 수 있는 이름 확인 결과를 조회하고 로컬 DNS 캐시를 지울 수 있습니다. 예시 도메인은 비교용이므로 실제 문제에서는 대상 도메인과 노드 서버 도메인도 조회하세요. 주소를 확인했다고 해서 대상 서비스가 기대하는 주소라는 뜻은 아닙니다. 리졸버, 네트워크, 지리적 출구가 달라 서로 다른 결과를 반환하는 것도 정상일 수 있습니다. 캐시를 지우기 전에 기존 결과를 기록하세요. 삭제한 뒤 앱을 다시 열고 재조회해야 합니다. 페이지가 우연히 복구된 것만으로 원인을 판단하지 마세요.

nslookup example.com
ipconfig /flushdns

조회가 시간 초과되면 현재 설정된 DNS 서버에 연결할 수 있는지, 오프라인 상태인 로컬 네트워크 장치가 DNS 서버로 고정되어 있는지 확인하세요. 기업이나 학교 네트워크는 내부 도메인을 확인할 때 내부 DNS에 의존할 수 있습니다. 이를 고려하지 않고 공용 주소로 바꾸면 내부 서비스가 작동하지 않을 수 있습니다. 자동으로 주소를 받도록 되돌려 비교할 수 있지만, 변경 전 기존 설정을 기록하세요. 캐시 삭제는 오래된 결과만 지울 뿐 상위 DNS 서버에 연결할 수 없는 문제, 잘못된 라우팅 규칙, 서버에 레코드가 없는 문제를 해결하지 못합니다.

브라우저, 시스템, 프록시 측 DNS 구분하기

브라우저가 별도의 보안 DNS를 사용하면 명령줄 조회는 정상이지만 브라우저에서 실패할 수 있습니다. 브라우저가 사용자 지정 리졸버, 프록시 확장 프로그램, 별도의 네트워크 설정을 사용하는지 확인한 뒤 시스템 설정을 따르는 다른 앱과 비교하세요. 브라우저 보안 DNS, 시스템 DNS, 클라이언트 DNS를 한꺼번에 변경하지 마세요. 어느 단계가 영향을 주는지 알 수 없습니다. 암호화 DNS를 사용하는 경우에는 현재 네트워크나 프록시를 통해 DNS 서비스에 접속할 수 있는지도 확인하세요. 도메인 문제를 해결하려다 새로운 연결 의존성을 만들지 않도록 주의하세요.

SOCKS 테스트에서 socks5h를 사용하면 대상 호스트 이름 처리를 프록시에 맡길 수 있습니다. 일반적인 로컬 이름 확인 방식과는 다를 수 있습니다. 두 방식의 결과가 다르면 로컬과 프록시 측 DNS 처리 차이를 확인하세요. 다만 클라이언트의 모든 도메인이 같은 경로로 처리된다는 뜻은 아닙니다. 라우팅 정책, 코어 DNS, 앱 자체의 이름 확인 방식이 최종 결과에 영향을 줍니다. HTTPS 주소를 IP 주소로 바꿔 단순 확인하지 마세요. 인증서, SNI, 가상 호스트도 원래 도메인에 의존합니다.

분할 라우팅 의존성과 DNS 순환 확인하기

도메인 규칙을 사용하면 요청이 도메인을 기준으로 출구를 선택할 수 있습니다. 주소 규칙을 사용할 때는 규칙을 적용하기 전에 코어가 도메인을 먼저 확인해야 할 수 있습니다. IPIfNonMatch 같은 정책은 도메인 규칙에 일치하지 않을 때만 이름 확인을 시도합니다. ‘항상 원격에서 이름 확인’하는 스위치가 아닙니다. 정책을 바꾸기 전에 규칙 순서를 파악하고, 문제 도메인이 앞선 규칙에서 이미 출구를 선택했는지 확인하세요. 프록시 서버의 도메인을 아직 연결되지 않은 프록시를 통해 확인해야 한다면 시작 단계에서 의존성 순환이 생길 수 있습니다.

TUN 환경에서는 가상 DNS 주소와 주소 매핑도 관련될 수 있습니다. 가상 주소를 실제 서버 주소인 것처럼 노드 설정에 입력하면 안 됩니다. 앱이나 코어를 재시작한 뒤에는 기존 연결이 유지한 매핑이 무효가 될 수 있습니다. 관련 설정을 바꾼 뒤에는 해당 앱 연결을 다시 설정하고, 필요하면 클라이언트를 재시작하세요. 기존 탭의 장시간 연결을 그대로 사용하지 마세요. TUN에서만 문제가 발생한다면 일반 시스템 프록시 모드로 돌아가 확인하세요. 가상 네트워크 인터페이스, DNS 처리, 라우팅 충돌로 범위를 좁힌 다음 고급 매개변수를 살펴보세요.

마지막 확인에서는 프록시 대상뿐 아니라 로컬 네트워크 리소스도 점검하세요. 웹페이지는 복구됐는데 프린터, 내부 도메인, 로컬 서비스가 작동하지 않는다면 분할 라우팅이나 내부 DNS를 추가로 조정해야 합니다. 모든 알 수 없는 도메인을 항상 하나의 출구로 보내는 설정을 최종 해결책으로 사용하지 마세요. 도메인 규칙, 주소 규칙, 코어 이름 관련 개념은 용어 설명을 참고하세요. 로그에서 이름 확인은 정상인데 원격 핸드셰이크가 실패한다면 DNS 설정을 반복해서 바꾸지 말고 노드 항목으로 돌아가세요.

시스템 프록시가 작동하지 않을 때: 모드, 수신 포트, 앱 동작 확인하기

시스템 프록시는 해당 설정을 따르는 앱에 프록시 주소를 알려주는 기능이지, 모든 네트워크 요청을 자동으로 처리하는 기능은 아닙니다. v2rayN의 시스템 프록시 자동 설정, 시스템 프록시 해제, 시스템 프록시 변경 안 함은 각각 시스템 프록시 상태를 설정, 삭제, 유지한다는 뜻입니다. 라우팅의 전역, 중국 본토 우회, 직접 연결과는 별개의 설정입니다. 앞의 설정은 앱이 클라이언트에 연결되는 방법을, 뒤의 설정은 클라이언트에 들어온 요청이 어떤 출구로 나가는지를 결정합니다. 이 둘을 혼동하는 것이 ‘전역 모드를 선택했는데도 작동하지 않음’의 흔한 원인입니다.

코어 수신 상태와 프록시 유형 확인하기

먼저 설정에서 실제 로컬 수신 주소, 포트, 프로토콜을 확인한 뒤 시스템 프록시가 같은 주소를 가리키는지 점검하세요. HTTP, SOCKS, 혼합 포트는 숫자만으로 구분할 수 없습니다. 혼합 포트에서 사용할 수 있는 프로토콜은 클라이언트 안내를 확인하세요. 이전 설정에서 포트를 다르게 썼을 수 있으므로 가이드의 기본값을 무조건 적용하지 마세요. 로컬 루프백 주소에서 수신하면 이 PC에서 사용할 수 있으며, 문제를 해결하려고 모든 네트워크 인터페이스에 수신하도록 바꿀 필요는 없습니다. 수신 범위를 넓히면 추가적인 접근 경계 문제가 생길 수 있습니다.

아래 Windows 명령어로 10808 포트가 수신 중인지, 어떤 프로세스가 사용하는지 확인할 수 있습니다. 첫 번째는 PowerShell 명령어이고 두 번째는 명령 프롬프트와 PowerShell에서 모두 실행할 수 있는 시스템 도구입니다. 결과가 없으면 코어 로그를 확인하세요. 다른 프로세스가 사용 중이라면 프로세스 ID를 기록하고 작업 관리자에서 프로그램 출처를 확인합니다. 정체를 알 수 없는 시스템 프로세스를 바로 종료하지 마세요. 포트가 수신 중이라고 해서 그 프로세스가 현재 클라이언트라고 단정할 수도 없습니다.

Get-NetTCPConnection -LocalPort 10808 -State Listen
netstat -ano | findstr ":10808"

충돌이 확인되면 해당 포트를 사용하는 다른 프록시 도구를 정상적으로 종료하거나 v2rayN 설정에서 사용 중이지 않은 포트를 선택하세요. 변경 후 관련 코어를 재시작하고 시스템 프록시 자동 설정도 다시 실행해야 합니다. 브라우저 자체 프록시, 터미널 환경 변수, 다른 수동 설정도 함께 업데이트하세요. 수신 포트만 바꾸고 앱 연결 주소를 그대로 두면 클라이언트는 정상 실행되지만 요청은 이전 포트로 보내는 문제가 생깁니다. 자세한 확인 방법은 로컬 포트 충돌 해결을 참고하세요.

플랫폼별 시스템 연결 지점 구분하기

프록시를 명시한 명령어는 작동하는데 일반 앱은 작동하지 않는다면 앱 설정부터 확인하세요. 브라우저 확장 프로그램이 시스템 프록시를 덮어쓸 수 있고, 터미널이 이전 프록시 환경 변수를 유지할 수도 있으며, 서비스 프로세스가 별도 설정을 사용할 수도 있습니다. Windows의 netsh winhttp show proxy는 WinHTTP 프록시를 확인하는 명령어이며, 모든 브라우저와 데스크톱 앱의 프록시 상태를 보여 주지는 않습니다. 이 명령어에 직접 연결로 표시된다고 해서 다른 시스템 설정을 반복해서 적용하지 마세요.

종료 후 남은 설정과 TUN 처리 확인하기

클라이언트가 비정상 종료됐는데 시스템 프록시가 로컬 포트를 계속 가리키고 코어는 중지된 상태라면 해당 설정을 따르는 앱은 모두 연결에 실패합니다. 먼저 클라이언트를 다시 실행해 시스템 프록시를 해제한 뒤 시스템 프록시 화면에 수동 주소나 자동 구성 스크립트가 남아 있는지 확인하세요. 조직 정책으로 관리되는 경우 강제로 덮어쓰지 마세요. 정상 종료 후에도 창을 닫는 데 그치지 말고 직접 연결이 복구됐는지 확인하세요. 여러 프록시 도구를 동시에 실행하면 나중에 설정한 도구가 이전 설정을 덮어쓸 수 있으므로 다른 도구를 종료한 뒤 테스트하세요.

TUN은 가상 네트워크 인터페이스를 통해 트래픽을 처리하는 기능으로, 권한과 라우팅, 방화벽 설정이 함께 필요합니다. 시스템 프록시 스위치와 같은 기능이 아닙니다. 일반 프록시가 정상 작동하는 것을 확인한 뒤 TUN을 별도로 켜고 로그를 살펴보세요. 켜자마자 인터넷이 끊기면 TUN을 끄고 정상 작동이 확인된 상태로 돌아간 다음 가상 네트워크 인터페이스, 다른 VPN, 보안 소프트웨어와의 충돌을 확인하세요. 복구 후에는 앱을 하나씩 실행해 트래픽 처리 범위를 확인하고 로컬 네트워크 및 필요한 직접 연결은 유지하세요. ‘모든 요청이 클라이언트로 들어감’이 모든 요청이 원격 프록시를 거쳐야 한다는 뜻은 아닙니다.

클라이언트 충돌: 인터페이스 종료와 코어 실행 실패 구분하기

먼저 어느 단계에서 문제가 생기는지 확인하세요. 실행해도 창이 전혀 뜨지 않는지, 창이 열렸다 바로 종료되는지, 기본 화면은 정상이지만 연결 시작에 실패하는지, 일정 시간 사용한 뒤 프로세스가 사라지는지 기록합니다. 그래픽 인터페이스와 프록시 코어는 별도 프로세스일 수 있습니다. 코어가 종료돼도 기본 창이 닫히지 않을 수 있습니다. 재설치하기 전에 문제를 유발한 동작, 오류 원문, 시스템 아키텍처를 기록하세요. 설정을 연속해서 삭제하고 구독을 다시 만들거나 코어를 바꾸지 마세요. 설정을 잃을 수 있고 기존 문제를 재현하기도 어려워집니다.

실행 실패 시 패키지 종류, 디렉터리, 실행 환경부터 확인하기

클라이언트 다운로드 페이지에서 운영체제와 프로세서에 맞는 항목을 선택하세요. 데스크톱에서는 v2rayN을 우선 권장합니다. Windows 데스크톱 버전과 클래식 WPF 버전은 인터페이스 기술과 실행 요구 사항이 다르므로 각 패키지의 안내를 확인하세요. 한 패키지에 없는 구성 요소 파일을 다른 패키지에 복사하지 마세요. macOS에서는 Apple Silicon과 Intel을 구분하고, Linux에서는 아키텍처뿐 아니라 배포판에 맞는 패키지 유형도 선택해야 합니다. 아키텍처가 다르거나 실행 환경이 빠진 문제는 프록시 규칙을 바꿔 해결할 수 없습니다.

선택한 패키지의 압축을 풀어야 한다면 현재 사용자에게 쓰기 권한이 있는 위치에 전체 압축을 푸세요. 압축 파일 미리보기 창에서 바로 실행하지 마세요. 경로가 너무 길거나 디렉터리가 보호되어 있거나 보안 소프트웨어가 파일을 격리하면 실행 구성 요소가 누락될 수 있습니다. 시스템 안내와 보안 소프트웨어 기록에서 어떤 파일이 처리됐는지 확인하고 모든 보호 기능을 끄지 마세요. 설치 프로그램은 일반적인 설치 절차를 따르고, 휴대용 디렉터리의 개별 파일과 섞지 마세요. Windows에서 패키지를 고르는 방법은 설치 설정 및 패키지 유형 안내를 참고하세요.

코어 종료 시 설정과 포트부터 확인하기

기본 화면은 정상이지만 코어가 시작되지 않는다면 로그에서 처음으로 명확하게 표시되는 오류를 찾으세요. 포트 바인딩 실패는 포트 항목에서 확인합니다. 필드를 인식할 수 없거나 설정 파싱에 실패했다면 사용자 지정 설정을 가져왔거나 고급 매개변수를 수정했거나 코어를 바꾼 적이 있는지 확인하세요. 새 설정에 현재 코어가 지원하지 않는 필드가 있거나 JSON 문법 오류가 있을 수 있습니다. 로그 마지막의 ‘프로세스 종료’ 메시지만 보지 마세요. 보통은 결과일 뿐이며 실제 원인은 앞서 나온 파싱 또는 시작 정보에 있습니다.

아래는 JSON 문법에 맞는 최소 로그 설정 예시입니다. 객체, 필드, 문자열 작성법만 보여 주며 단독으로 실행할 수 있는 완전한 프록시 설정이 아닙니다. 실제로는 클라이언트에서 지원하는 설정 메뉴로 로그 수준을 조정하거나 전체 설정의 올바른 위치를 수정하세요. 이 작은 예시를 설정 파일 전체에 덮어쓰지 마세요. 점검을 마친 뒤에는 일반 로그 수준으로 되돌려 접속 기록이 과도하게 쌓이지 않도록 하세요.

{
  "log": {
    "loglevel": "warning"
  }
}

설정에 쉼표가 하나 더 있거나, 따옴표가 닫히지 않았거나, 불리언 값을 요구하는 필드에 숫자를 넣으면 파싱에 실패할 수 있습니다. JSON 문법 검사로 구조가 유효한지 확인할 수는 있지만, 필드가 현재 코어에서 지원되는지는 검증할 수 없습니다. 명확한 이유가 없다면 방금 변경한 고급 옵션을 되돌리고 그래픽 클라이언트에서 설정을 생성하세요. 코어 변경 문제를 확인할 때는 먼저 해당 코어가 지원하는 노드와 매개변수 조합으로 되돌리세요. Xray와 V2Fly가 모든 필드를 서로 바꿔 쓸 수 있는 같은 프로그램이라고 생각하면 안 됩니다.

백업과 깨끗한 환경으로 비교하기

클라이언트를 완전히 종료한 뒤 해당 클라이언트의 저장 방식에 따라 설정 디렉터리를 백업하거나 설정을 내보내세요. 백업에 구독 및 인증 정보가 포함될 수 있으므로 관리되는 로컬 위치에 보관해야 합니다. 기존 디렉터리는 그대로 두고 별도 디렉터리나 새 앱 설정 환경에서 초기 상태로 실행하세요. 테스트 중에는 같은 포트를 두 인스턴스가 동시에 사용하지 않도록 주의합니다. 초기 환경에서 정상 작동하면 모든 이전 파일을 한 번에 덮어쓰지 말고 구독과 필요한 설정을 차례로 복구하세요. 동일하게 실패한다면 실행 환경, 파일 권한, 시스템 오류 기록을 확인하세요.

업데이트 후 문제가 생겨도 먼저 현재 상태를 보존하고 새 패키지와 이전 패키지가 섞이지 않았는지, 이전 프로세스가 종료됐는지, 설정 이전이 완료됐는지 확인하세요. 클라이언트가 실행 중일 때 사용 중인 파일을 바꾸지 마세요. macOS의 보안 안내가 표시되면 안내 유형과 시스템에서 제공하는 처리 방법을 확인하세요. Linux에서는 무조건 더 높은 권한으로 실행하지 말고 시작 출력과 데스크톱 세션 관련 의존성을 살펴보세요. 복구 후 구독, 시스템 프록시, 종료 시 설정 정리가 정상인지 확인한 뒤 임시 테스트 디렉터리를 삭제하세요. 문의할 때는 필요한 오류 내용, 시스템 아키텍처, 재현 절차만 제공하고 비공개 설정 전체를 첨부하지 마세요.

모바일 문제: VPN 권한, 앱별 설정, 백그라운드 제한 확인하기

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 권장하며, V2Fly 코어 대안으로 v2flyNG를 사용할 수 있습니다. 두 앱은 설정 기능과 메뉴 위치가 완전히 같지 않으므로 화면이 비슷하다고 항목별로 그대로 따라 하지 마세요. 점검 전 사용 중인 앱, 선택한 노드, 작동 모드, 네트워크를 기록하세요. 첫 연결부터 실패하는지, 화면을 잠근 뒤 끊기는지, 네트워크 전환 후 연결되지 않는지, 특정 앱만 접속할 수 없는지 확인합니다. 먼저 하나의 네트워크에서 클라이언트 하나가 안정적으로 작동하는지 확인하고 VPN 연결 두 개를 동시에 실행해 비교하지 마세요.

첫 연결 시 권한과 VPN 점유 여부 확인하기

VPN 모드를 사용하면 시스템에서 로컬 VPN 연결 설정을 확인하라는 메시지를 표시합니다. 이전에 권한 요청을 거부했다면 다시 연결을 시작하고 권한 안내가 표시되는지 확인하세요. 시작 버튼이 켜져 있어도 모든 앱 트래픽이 VPN으로 들어간다는 뜻은 아닙니다. 다른 VPN, 업무 프로필의 네트워크 도구, 항상 켜기 VPN 설정이 사용 중인지 확인하세요. 일부 시스템은 프로필별로 네트워크를 관리합니다. 개인 프로필과 업무 프로필의 앱은 서로 다른 정책을 적용받을 수 있으므로 알림 표시줄의 아이콘만 보고 모든 앱이 트래픽 처리 대상이라고 판단하지 마세요.

프록시 모드는 보통 로컬 프록시 포트만 제공하며 다른 앱의 요청을 자동으로 모두 클라이언트에 전달하지 않습니다. 시스템이나 앱에 해당 포트가 설정되지 않으면 노드 테스트는 성공하지만 브라우저 트래픽은 프록시를 거치지 않을 수 있습니다. VPN으로 트래픽을 처리할지 로컬 프록시만 사용할지 먼저 결정한 다음 대상 앱에서 지원하는 방식으로 설정하세요. 시스템 VPN 페이지에서 VPN을 거치지 않는 연결을 차단하는 옵션이 켜져 있으면 터널을 만들지 못했을 때 기본 네트워크까지 사용할 수 없을 수 있습니다. 옵션의 동작을 확인한 뒤 비교 테스트하고 클라이언트를 반복해서 재설치하지 마세요.

일부 앱에서만 실패하면 앱별 프록시부터 확인하기

앱별 프록시가 활성화되어 있는지, 허용 목록과 우회 목록 중 어떤 모드인지 확인하세요. 같은 앱 목록도 모드에 따라 의미가 반대입니다. 한 모드에서는 목록에 있는 앱만 프록시를 사용하고, 다른 모드에서는 목록에 있는 앱이 프록시를 우회합니다. 새로 설치한 앱, 복제 앱, 업무 프로필 앱은 서로 다른 앱으로 인식될 수 있으므로 목록을 다시 확인하세요. 브라우저는 작동하지만 특정 앱이 실패한다면 해당 앱이 제외되어 있는지, 별도 네트워크 방식을 쓰는지 확인한 뒤 대상 도메인이 라우팅 규칙에 따라 직접 연결되는지 살펴보세요.

특정 앱 하나를 복구하려고 모든 도메인을 같은 DNS나 출구로 보내지 마세요. 앱별 필터를 잠시 끄고 같은 노드와 네트워크에서 대상 앱을 테스트할 수 있습니다. 정상 작동한다면 목록을 하나씩 보완하세요. 앱 내부에 연결 정보가 캐시될 수도 있으므로 설정 변경 후 앱을 완전히 종료했다가 다시 여세요. 시스템 브라우저, 앱 안의 웹페이지, 별도 앱은 네트워크 동작이 서로 다를 수 있습니다. 웹사이트 로그인 성공만으로 실제 대상 앱의 연결을 확인한 것으로 볼 수 없습니다. 계정 세션을 점검할 때 로그인 정보를 공개 로그에 기록하지 마세요.

화면 잠금 후 연결 끊김과 네트워크 전환 실패 구분하기

화면을 잠그거나 앱을 백그라운드로 보낸 뒤에만 연결이 끊긴다면 배터리 최적화, 백그라운드 실행 제한, 제조사 시스템의 프로세스 종료 정책부터 확인하세요. 배터리 소모에 유의하면서 사용 중인 클라이언트에 필요한 백그라운드 실행을 허용하고 알림이 계속 표시되는지 확인합니다. 모든 앱의 배터리 관리를 한꺼번에 끄지 말고 문제가 있는 클라이언트만 비교하세요. 프로세스는 계속 실행 중인데 연결이 끊긴다면 절전 중 네트워크가 전환되는지, 원격 연결을 다시 설정해야 하는지, 시스템 로그에 VPN 연결 해제 기록이 있는지 확인하세요.

Wi-Fi와 모바일 네트워크를 전환하면 기존 연결이 변경된 주소와 네트워크 경로에 의존할 수 있습니다. 먼저 클라이언트 연결을 중지했다가 다시 시작하고 대상 앱을 열어 테스트하세요. 재연결하면 복구되는지, 특정 네트워크에서 계속 실패하는지 구분합니다. 공용 Wi-Fi에서만 실패한다면 네트워크 로그인을 완료하고, 모바일 네트워크에서만 실패한다면 기본 연결, DNS, 접속 경로를 확인하세요. 원인을 기록하는 대신 비행기 모드를 반복해서 켜고 끄거나 근거 없이 APN 및 시스템 네트워크 설정을 바꾸지 마세요.

설치 호환성과 최종 복구 확인

설치에 실패하면 프로세서 아키텍처, 시스템 요구 사항, 저장 공간, 같은 이름 앱 간 서명 충돌 여부를 확인하세요. 최신 기기의 대부분은 arm64에 적합하지만 확실하지 않다면 다운로드 페이지의 설명에 따라 범용 패키지를 선택하세요. 다른 앱 디렉터리에서 파일을 꺼내 수동으로 보충하지 마세요. 덮어쓰기 설치가 되지 않으면 설정을 백업하고 시스템 안내를 확인한 뒤 삭제 여부를 결정하세요. 앱을 삭제하면 구독과 설정이 지워질 수 있습니다. 패키지는 Android 다운로드에서 선택하고 두 클라이언트의 설정 디렉터리를 섞지 마세요.

같은 노드에서 v2rayNG는 정상인데 v2flyNG가 실패한다면 기기 이상으로 단정하기 전에 프로토콜과 매개변수가 해당 코어에서 지원되는지 확인하세요. 문의할 때는 클라이언트 이름, 네트워크 유형, 작동 모드, 앱별 정책, 문제 발생 절차를 적고 민감 정보를 삭제한 오류 일부를 첨부하세요. 설정 과정을 다시 확인하려면 빠른 시작 가이드로 돌아가고, 특정 설정의 의미만 확인하려면 자주 묻는 질문을 참고하세요. 원인을 찾는 대신 재설치하지 마세요.