V2Ray 문제 해결 총정리

‘연결 후 인터넷이 되지 않음’이 곧 노드 자체의 장애를 의미하지는 않습니다. 클라이언트에 시작됨으로 표시되는 것은 로컬 프로세스가 초기화되었다는 뜻일 뿐, 원격 핸드셰이크, DNS 조회, 애플리케이션 트래픽까지 성공했다는 의미는 아닙니다. 먼저 범위를 확인하세요. 모든 웹사이트가 열리지 않는지, 도메인만 열리지 않는지, 시스템 프록시를 끄면 직접 연결이 복구되는지, 같은 노드가 다른 네트워크에서 작동하는지, 브라우저만 문제인지 명령줄과 다른 앱도 문제인지 확인합니다. 이 네 가지 질문으로 네트워크, DNS, 프록시 연결, 노드 설정 중 어디에서 문제가 발생했는지 빠르게 좁힐 수 있습니다.

기준 상태를 복구한 뒤 단계적으로 활성화

v2rayN에서 먼저 시스템 프록시와 TUN 모드를 끄고 클라이언트 프로세스는 실행 상태로 둔 다음, 일반 직접 연결이 정상인지 확인하세요. 직접 연결도 실패한다면 V2Ray 설정을 계속 바꾸지 말고 라우터, 네트워크 인증, 네트워크 어댑터 또는 로컬 DNS부터 점검해야 합니다. 직접 연결이 복구되면 정상 작동이 확인된 노드 하나를 선택해 시스템 프록지만 켜고, 짧게 테스트하기 위해 라우팅을 전역 프록시로 전환하세요. 전역 모드에서는 작동하지만 규칙 모드에서 실패한다면 대개 라우팅 규칙, GeoSite 데이터 또는 DNS 분할이 원인입니다. 전역 모드에서도 작동하지 않으면 노드와 로컬 프록시 포트를 계속 확인하세요.

1. 다른 프록시, 가속기 또는 트래픽 가로채기 프로그램을 종료해 여러 프로그램이 시스템 프록시와 라우팅 테이블을 동시에 수정하지 않도록 하세요.
2. 시스템 시간과 시간대를 확인하세요. 시간 오차는 TLS 인증서 판정을 잘못하게 만들고, 시간 필드가 포함된 인증도 실패시킬 수 있습니다.
3. 클라이언트에서 노드를 다시 선택하고 코어를 시작한 뒤, 로그에 로컬 인바운드 리스너가 나타나는지 확인하세요. 시작 직후 종료되는지 여부도 함께 살펴봅니다.
4. 연결 방식은 한 가지만 사용하세요. 일반적인 브라우저 테스트에서는 시스템 프록시를 우선 사용하고 시스템 프록시와 TUN을 동시에 켜지 마세요.
5. 순수 IP 주소와 자주 사용하는 도메인에 각각 접속해 문제가 DNS에 집중되어 있는지 판단하세요.

Windows에서는 다음 명령으로 로컬 포트가 리슨 상태인지 확인할 수 있습니다. 포트 번호는 v2rayN의 현재 설정을 기준으로 해야 하며, 일반적인 설정에는 SOCKS와 HTTP 인바운드가 함께 존재합니다. 명령 결과가 없으면 코어가 해당 포트를 리슨하지 않는 것입니다. 포트 충돌, 설정 생성 실패 또는 코어 프로세스 종료가 원인일 수 있습니다.

netstat -ano | findstr LISTENING
curl.exe -x http://127.0.0.1:10809 https://example.com/

두 번째 명령은 시스템 프록시 설정을 우회해 로컬 HTTP 프록시로 직접 요청을 보냅니다. 페이지 응답이 반환되면 ‘애플리케이션에서 로컬 프록시를 거쳐 노드로 연결되는’ 기본 경로는 정상이며, 시스템 프록시 스위치나 브라우저 자체 설정이 문제일 가능성이 높습니다. 로컬 포트에 연결할 수 없다는 메시지가 나오면 인바운드 포트를 확인하세요. 로컬 포트에는 연결되지만 원격 요청이 실패하면 코어 로그에서 핸드셰이크, 인증서, 주소 또는 라우팅 정보를 확인하세요.

설정 오류와 네트워크 차단 구분

노드 설정은 서버 주소, 포트, 사용자 식별자, 전송 방식, TLS 스위치, 서버 이름과 경로를 항목별로 확인해야 합니다. VMess, VLESS, Trojan은 필드 의미가 다르므로 주소와 포트만 바꾸고 기존 전송 매개변수를 그대로 사용하면 안 됩니다. 구독에서 클라이언트가 노드를 자동 생성한다면 먼저 구독을 다시 업데이트하고 노드를 다시 선택하세요. 수동 입력 시에는 제공자가 안내한 전체 매개변수를 필드별로 대조하고, 특히 WebSocket 경로의 앞 슬래시, gRPC 서비스 이름, TLS 서버 이름을 주의해서 확인해야 합니다.

같은 설정이 모바일 네트워크에서는 작동하고 가정용 네트워크에서는 작동하지 않는다면, 가정용 네트워크의 DNS 변조, 라우터 필터링, 이중 프록시 또는 비정상적인 IPv6 경로를 확인하세요. 반대로 가정용 네트워크에서는 작동하지만 모바일 네트워크에서 실패한다면 모바일 백그라운드 제한, 비공개 DNS와 현재 접속 지점을 점검해야 합니다. 한 번의 요청만으로 네트워크 측 장애라고 단정하지 말고, 최소 두 개의 서로 다른 네트워크와 두 개의 서로 다른 노드에서 교차 테스트하세요. 교차 결과를 통해 ‘특정 노드 문제’, ‘특정 네트워크 문제’, ‘클라이언트 전역 설정 문제’를 구분할 수 있습니다.

연결이 복구되면 라우팅을 전역 모드에서 실제 사용하는 규칙 모드로 되돌린 뒤, 한국 국내 직접 연결, 프록시 대상, 로컬 네트워크 주소가 각각 예상한 출구로 향하는지 확인하세요. 모드 차이는 시스템 프록시, 전역 모드와 중국 본토 우회 모드의 차이에서 확인할 수 있습니다. 전환 후 다시 인터넷이 끊긴다면 기본 연결은 정상인 것이므로 클라이언트를 재설치하지 말고 라우팅 규칙과 DNS를 집중적으로 점검하세요.

시간 초과는 어느 한 계층이 정해진 시간 안에 유효한 응답을 받지 못했다는 뜻입니다. 하지만 로그의 ‘timeout’은 TCP 연결 설정, TLS 핸드셰이크, 프로토콜 인증, DNS 조회 또는 대상 사이트 응답을 가리킬 수 있습니다. 처리 전에 시간 초과가 발생한 위치와 지속 시간을 기록하세요. 여러 노드에서 동시에 시간 초과가 발생하면 로컬 네트워크, 시스템 시간, DNS와 클라이언트 코어를 먼저 확인해야 합니다. 특정 노드 하나만 시간 초과가 발생한다면 해당 노드의 주소, 포트, 전송 매개변수와 원격 상태를 우선 점검하세요.

교차 테스트로 원인 범위 나누기

2×2 테스트를 구성하세요. 같은 노드를 현재 네트워크와 다른 네트워크에서 각각 테스트하고, 현재 네트워크에서는 다른 노드도 테스트합니다. 노드를 바꿔도 실패하지만 다른 노드는 정상이라면 해당 노드에 문제가 집중됩니다. 현재 네트워크의 모든 노드가 실패하고 네트워크를 바꾸면 복구된다면 로컬 네트워크 경로가 원인입니다. 모든 조합에서 실패한다면 클라이언트 공통 설정이나 구독 매개변수를 확인해야 합니다. 비교가 가능하도록 교차 테스트 중에는 클라이언트 버전, 라우팅 모드와 DNS 설정을 바꾸지 마세요.

‘연결 거부’와 ‘연결 시간 초과’는 의미가 다릅니다. 연결 거부는 대개 패킷이 대상 호스트에 도착했지만 지정 포트에서 서비스가 리슨하지 않거나 중간 장비가 거부를 직접 반환했다는 뜻입니다. 시간 초과는 패킷이 도착하지 않았거나 응답 경로가 끊겼거나 서비스가 응답하지 않는 경우일 수 있습니다. 전자는 포트와 원격 서비스를 먼저 확인하고, 후자는 주소 확인, 네트워크 경로와 방화벽을 먼저 점검하세요. 로그에 짧은 간격의 재시도가 계속 나타나면 클라이언트가 장시간 반복 연결하지 않도록 노드를 일시 중지하세요. 재시도 로그가 실제 최초 오류를 덮을 수 있습니다.

TLS 및 전송 매개변수 확인 순서

TLS를 사용하는 설정에는 최소한 원격 주소, 서버 이름과 인증서 일치 여부가 포함됩니다. 서버 주소는 IP일 수도 도메인일 수도 있지만, 서버 이름은 일반적으로 TLS 핸드셰이크에 사용되므로 둘이 같지 않을 수 있습니다. 수동 편집 시 서버 이름을 비워 두거나 노드 메모를 잘못 입력하거나 잘못된 도메인을 사용하면 핸드셰이크가 실패합니다. WebSocket을 사용한다면 Host와 path도 확인하고, gRPC라면 serviceName을 확인하세요. REALITY를 사용한다면 공개 키, 짧은 식별자, 서버 이름과 흐름 제어 필드를 대조해야 합니다. 인증서 검증을 끄는 방식으로 필드 오류를 숨기지 마세요. 겉으로 드러나는 오류만 사라질 뿐 설정이 올바르다는 증거는 아닙니다.

IPv6도 불안정한 시간 초과를 일으킬 수 있습니다. 도메인이 IPv4와 IPv6 주소를 함께 반환하지만 현재 네트워크의 IPv6 연결이 불완전할 수 있습니다. 보통 최초 연결 대기 시간이 길어진 뒤 IPv4로 전환되거나 같은 노드가 때로는 작동하고 때로는 실패합니다. 클라이언트 DNS나 시스템 네트워크에서 IPv4 우선으로 임시 설정해 확인할 수 있지만, 모든 IPv6 설정을 바로 삭제해서는 안 됩니다. 원인을 확인한 뒤 실제 네트워크 성능에 맞는 우선순위를 선택하세요.

노드는 연결되지만 특정 웹사이트에서 시간 초과가 발생한다면 대상 도메인이 잘못 직접 연결로 분류되었는지, 차단 규칙에 걸렸는지, DNS가 반환한 주소가 라우팅 규칙과 일치하는지 확인하세요. 대상 도메인을 명확한 프록시 규칙에 임시로 추가하고 포괄적인 규칙보다 앞에 배치할 수 있습니다. 규칙을 수정한 뒤 코어를 재시작하거나 설정을 다시 불러오고, 로그에서 적용된 아웃바운드 태그를 확인하세요. domain, ip, geosite의 순서는 V2Ray 라우팅 규칙 설정 실전에서 계속 확인할 수 있습니다.

수정이 끝나면 최소 세 종류의 요청을 확인하세요. 노드 서버의 도메인 확인, 일반 HTTPS 사이트 접속, 수분 동안의 연결 안정성입니다. 핸드셰이크가 한 번 성공한 것만으로 문제가 해결됐다고 볼 수 없습니다. 일정한 간격으로 연결이 끊긴다면 클라이언트의 연결 시간 초과를 단순히 늘리지 말고 네트워크 전환, 라우터 연결 추적, 모바일 절전 정책과 서버의 유휴 시간 초과를 계속 점검하세요.

구독 업데이트에는 클라이언트가 구독 주소를 요청하는 단계, 서버가 콘텐츠를 반환하는 단계, 클라이언트가 이를 해석해 노드 목록에 저장하는 단계가 각각 포함됩니다. 오류 메시지는 마지막 결과만 보여 주는 경우가 많으므로 요청이 실제로 전송됐는지, HTTP 상태가 정상인지, 반환 콘텐츠가 클라이언트가 지원하는 형식인지 확인해야 합니다. 노드 목록이 비어 있다고 해서 반드시 네트워크 문제는 아닙니다. 구독 콘텐츠 만료, 주소 복사 누락, 로그인 페이지 반환, 필터 규칙으로 전체 노드 숨김, 파싱 중 형식 오류도 원인일 수 있습니다.

먼저 주소 자체 확인

구독 주소를 다시 복사할 때는 원본 페이지에서 전체 복사 기능을 사용하고 수동으로 잘라내지 마세요. 주소의 프로토콜, 경로, 쿼리 매개변수와 마지막 문자를 중점적으로 확인합니다. 메신저나 문서 편집기가 연결 기호를 다른 문자로 바꾸거나 끝에 마침표, 줄바꿈 또는 공백을 추가할 수 있습니다. 주소에 임시 인증 정보가 포함되어 있다면 공개 로그나 스크린샷에 남기지 마세요. 시스템 시간이 정확한지도 확인하세요. 일부 구독 서비스는 요청 시간을 검사하며 시간 오차는 HTTPS 인증서 검증에도 영향을 줍니다.

v2rayN에서는 먼저 특정 구독 하나만 업데이트하고 모든 그룹을 동시에 업데이트하지 마세요. 이렇게 하면 특정 주소의 실패인지 전체 네트워크 문제인지 확인할 수 있습니다. 지정한 구독이 실패하면 오류 메시지를 보존하고 로그에서 HTTP 상태를 확인하세요. 모든 구독이 실패한다면 시스템 프록시, 직접 연결, DNS, 그리고 클라이언트가 구독 요청을 아직 사용할 수 없는 노드로 잘못 보내고 있지 않은지 점검합니다. 어떤 환경에서는 구독을 직접 연결로 가져와야 하고, 다른 환경에서는 기존 프록시를 통해 가져와야 하므로 구독 출처의 실제 접근 가능성에 맞춰 방식을 선택하세요.

curl.exe -L --connect-timeout 15 "https://example.com/subscription?token=xxxx" -o subscription.txt

명령에 표시된 주소는 요청 구조만 보여 주는 예시입니다. 실제 점검에서는 공용 터미널에 전체 인증 정보를 기록하거나 공유하지 마세요. 반환 파일이 HTML 로그인 페이지, 오류 안내 또는 빈 파일이라면 클라이언트가 노드를 생성할 수 없습니다. 긴 인코딩 텍스트나 노드 링크가 반환된다면 클라이언트가 해당 형식을 지원하는지 확인하세요. HTTP 301, 302는 리디렉션이며 명령의 -L 옵션은 리디렉션을 따라갑니다. 401, 403은 대개 인증 정보, 권한 또는 요청 조건과 관련됩니다. 404는 경로가 없다는 뜻이고, 429는 요청이 너무 잦다는 뜻이므로 반복 새로고침을 중지하고 잠시 후 다시 시도하세요. 5xx는 구독 서비스 서버의 일시적인 오류일 가능성이 큽니다.

콘텐츠는 다운로드됐지만 파싱에 실패함

로그에 다운로드 성공이 표시되는데 노드가 여전히 비어 있다면 구독 그룹의 필터 조건을 확인하세요. 정규식 필터가 지나치게 좁으면 모든 노드가 제외될 수 있고, 중복 제거 규칙이 이름이 비슷한 노드를 하나로 합칠 수도 있습니다. 먼저 필터를 끄고 다시 업데이트해 원본 노드가 나타나는지 확인하세요. 나타난다면 필터 조건을 하나씩 다시 적용합니다. 노드 이름에 괄호, 더하기 기호 또는 다른 정규식 문자가 포함된 경우 표현식에서 특수한 의미를 가질 수 있으므로 이름을 그대로 복사해도 문자 그대로 일치하지 않을 수 있습니다.

구독 반환 형식과 클라이언트 코어는 별개의 개념입니다. v2rayN은 데스크톱 설정을 관리하고, v2rayNG는 Xray 코어를 사용하며, v2flyNG는 v2fly 코어를 사용합니다. 같은 구독에 포함된 일부 전송 또는 프로토콜 필드는 특정 클라이언트에서만 인식될 수 있습니다. 업데이트는 성공했지만 특정 노드 가져오기에 실패한다면 구독을 반복해서 삭제하지 말고 파싱 로그를 확인하고 노드 유형을 점검하세요. Android에서는 v2rayNG와 v2flyNG를 호환성 비교에 사용할 수 있지만 두 로컬 VPN을 동시에 시작하지 마세요.

구독 주소가 만료됐다면 token을 임의로 수정하거나 경로를 추측하지 말고 원래 제공 채널에서 새 주소를 받으세요. 기존 주소를 삭제하고 즉시 새로 만드는 것만으로는 서버 권한 문제가 해결되지 않습니다. 브라우저에서는 콘텐츠를 가져올 수 있지만 클라이언트에서 실패한다면 클라이언트의 사용자 에이전트 제한, 시스템 프록시 경로와 TLS 로그를 확인하세요. 클라이언트에서는 성공하지만 브라우저에서 실패한다면 브라우저 확장, 캐시 또는 별도 프록시 설정의 차이일 수 있습니다. 다운로드 페이지의 자주 묻는 질문을 참고해 클라이언트 선택을 확인한 다음, 이 장으로 돌아와 요청·응답·파싱의 세 단계에서 원인을 찾으세요.

수정 후 ‘업데이트 성공’ 메시지만 확인하지 말고 노드 수가 적절한지, 업데이트 시간이 변경됐는지, 기존 노드가 예상대로 교체됐는지 확인하세요. 이어서 노드 두 개를 무작위로 열어 서버 주소와 프로토콜 필드를 대조하고, 노드 하나를 선택해 연결 테스트를 실행합니다. 구독 성공은 설정 데이터가 클라이언트에 들어왔다는 뜻일 뿐 모든 노드가 네트워크 연결을 수립할 수 있다는 의미는 아닙니다. 연결에 실패하면 앞 장으로 돌아가 시간 초과와 핸드셰이크 단계를 계속 점검하세요.

속도 문제는 먼저 대역폭 부족, 높은 지연 시간, 패킷 손실, 단일 연결 제한과 클라이언트 리소스 병목을 구분해야 합니다. 웹페이지가 느리게 열리는 것이 다운로드 대역폭이 낮다는 뜻은 아니며, 속도 측정값이 높아도 상호작용 지연이 안정적이라는 보장은 없습니다. 점검할 때는 테스트 시간, 대상 파일, 네트워크와 노드를 고정하고 최소 세 번 반복하세요. 대상 사이트 혼잡이나 일시적인 무선 간섭을 클라이언트 문제로 오해하지 않도록 해야 합니다. 여러 속도 측정 도구를 동시에 실행하지 마세요. 대역폭을 서로 경쟁해 결과가 달라집니다.

직접 연결과 프록시의 기준값 만들기

먼저 프록시를 끄고 같은 네트워크에서 직접 연결의 지연 시간, 다운로드 속도와 패킷 손실을 측정한 뒤 노드 하나를 켜서 동일하게 테스트하세요. 직접 연결 자체가 불안정하다면 Wi-Fi 신호, 라우터 부하, 유선 연결 협상 또는 통신사 네트워크를 먼저 처리해야 합니다. 직접 연결은 안정적이지만 모든 노드가 느리다면 로컬 CPU, 백신의 네트워크 검사, TUN 드라이버와 MTU를 확인하세요. 특정 노드만 느리다면 노드 회선, 원격 부하 또는 노드에서 대상 사이트까지의 경로 문제일 가능성이 높습니다.

속도 측정은 작은 요청과 지속 전송을 모두 포함해야 합니다. 작은 요청은 DNS, 핸드셰이크와 첫 바이트까지의 시간을 관찰하는 데 사용하고, 지속 전송은 안정적인 대역폭을 확인하는 데 사용합니다. 웹페이지 첫 로딩만 느리고 이후 리소스는 정상이라면 DNS 또는 TLS 연결 설정 지연이 흔한 원인입니다. 다운로드가 처음에는 빠르다가 떨어진다면 원격 제한, 무선 혼잡, 패킷 손실에 따른 재전송 또는 CPU 상한이 원인일 수 있습니다. 속도가 주기적으로 0이 됐다가 회복된다면 네트워크 전환, 모바일 절전과 연결 재설정을 확인하세요.

전송, MTU와 라우팅 확인

TUN 모드는 가상 네트워크 어댑터와 라우팅 처리 단계를 추가합니다. 시스템 프록시에서는 정상인데 TUN에서 눈에 띄게 느려진다면 가상 네트워크 어댑터 드라이버, 엄격한 라우팅, IPv6와 MTU를 확인하세요. MTU가 너무 크면 단편화나 일부 경로의 패킷 손실이 발생해 작은 요청은 정상이고 큰 응답은 멈추는 현상이 나타날 수 있습니다. TUN 인터페이스의 MTU를 단계적으로 낮춰 비교할 수 있지만, 한 번에 한 단계만 조정하고 변경 후 다시 연결하세요. MTU를 지나치게 낮추면 추가 단편화로 효율이 떨어집니다.

규칙 기반 분할 라우팅도 ‘일부 웹사이트만 느린’ 원인이 될 수 있습니다. 대상 도메인은 직접 연결되지만 페이지의 이미지, 스크립트 또는 API는 프록시를 거칠 수 있으며 두 출구의 DNS와 연결 상태가 달라 페이지 대기로 이어집니다. 코어 액세스 로그를 열어 같은 페이지의 관련 도메인에 적용된 아웃바운드 태그를 확인하세요. 전역 프록시로 임시 전환했을 때 속도가 회복된다면 노드 자체는 사용 가능하므로 도메인 규칙을 수정해야 합니다. 전역 모드에서도 느리다면 회선과 전송 매개변수를 계속 확인하세요. GeoIP 및 GeoSite 데이터가 오래되어도 규칙 분류가 어긋날 수 있으며, 업데이트 방법은 GeoIP 및 GeoSite 데이터베이스 업데이트 안내를 참고하세요.

클라이언트 코어의 암호화, TLS와 트래픽 전달은 CPU를 사용합니다. 저전력 기기나 라우터에서는 단일 코어가 한계에 도달하면 처리 능력이 대역폭을 제한할 수 있습니다. 데스크톱에서는 전송 중 CPU와 메모리를 관찰해 코어 프로세스가 계속 자원을 사용하는지, 브라우저·동기화 프로그램·보안 검사가 자원을 사용하는지 확인하세요. CPU 여유가 있는데도 속도가 낮다면 동시성이나 연결 수를 무작정 늘려 해결하려 하지 마세요. 높은 동시성은 패킷 손실을 더 악화시킬 수 있습니다.

무선 네트워크는 가능한 한 액세스 포인트 가까이에서 테스트하고 대용량 동기화 작업을 끄세요. 2.4GHz와 5GHz의 결과 차이가 크다면 먼저 로컬 무선 환경을 개선해야 합니다. 네트워크를 바꿔 비교할 때는 네트워크 유형과 시간대를 기록하고, 조건이 다른 결과를 곧바로 프로토콜 탓으로 돌리지 마세요. 조정을 마치면 원래 라우팅 모드로 되돌린 뒤 웹 탐색, 동영상, 대용량 파일과 장시간 연결을 각각 테스트하세요. 특정 업무만 비정상이라면 해당 대상과 연결 방식에 초점을 맞춰 계속 분석합니다.

DNS 문제는 도메인이 열리지 않거나, 같은 웹사이트가 때로는 되고 때로는 안 되거나, 프록시 연결은 성공했지만 대상이 잘못된 경로로 분류되는 형태로 나타납니다. 브라우저와 명령줄에서 결과가 다를 수도 있습니다. 핵심은 DNS 주소 하나를 단순히 바꾸는 것이 아니라 ‘누가 조회를 시작하고, 어디로 보내며, 어떤 주소를 반환하고, 그 주소가 라우팅 매칭에 어떻게 반영되는지’를 확인하는 것입니다. 시스템 DNS, 클라이언트 내장 DNS, 브라우저 보안 DNS와 TUN 가로채기가 동시에 존재할 수 있어 여러 조회 경로가 서로 다른 결과를 만들 수 있습니다.

먼저 DNS 문제인지 판단

클라이언트를 끈 상태에서 시스템 명령으로 대상 도메인을 조회한 뒤 클라이언트를 켜고 다시 조회하면서 반환된 IPv4, IPv6와 조회 시간을 기록하세요. 시스템 조회는 실패하지만 지정한 공개 DNS에서는 성공한다면 로컬 DNS나 라우터 문제일 수 있습니다. 명령줄은 성공하지만 브라우저가 실패한다면 브라우저 캐시, 별도 DNS 설정과 확장 프로그램을 확인하세요. 조회는 성공하지만 접속이 실패한다면 로그에서 실제 연결한 주소가 조회 결과와 일치하는지 비교하세요.

nslookup example.com
nslookup example.com 1.1.1.1
ipconfig /flushdns

nslookup은 시스템 또는 지정한 서버의 조회 결과를 확인하는 명령입니다. 시스템 캐시를 새로 고쳐도 운영체제가 관리하는 기록만 삭제되며 브라우저와 클라이언트 내부 캐시는 지워지지 않습니다. 새로 고침 후에는 테스트 앱을 완전히 종료했다가 다시 실행하세요. 클라이언트에서 FakeDNS를 활성화한 경우 반환 주소가 예약 주소일 수 있으며 이는 매핑 메커니즘의 일부입니다. 일반적인 공인 IP처럼 판단해서는 안 됩니다. 이때 FakeDNS 매핑을 코어가 인계받았는지, 대상 트래픽이 해당 프록시 진입점으로 들어가는지 확인하세요.

DNS와 라우팅의 선후 관계 이해

라우팅 규칙은 도메인으로 매칭할 수도 있고, 확인된 IP로 매칭할 수도 있습니다. 코어에 들어오기 전에 시스템이 도메인을 해석하면 코어에는 IP만 보일 수 있어 도메인 규칙이 예상대로 작동하지 않습니다. 코어가 직접 해석하면 도메인 정보를 유지하면서 규칙에 따라 서로 다른 DNS와 출구를 선택할 수 있습니다. 설정할 때는 DNS 처리 전략을 명확히 하고, 서로 충돌하는 시스템 DNS·브라우저 DNS·클라이언트 DNS를 동시에 의존하지 마세요.

다음은 서버 목록과 조회 전략의 구조를 설명하기 위한 간단한 Xray 스타일 DNS 조각입니다. 실제 주소와 전략은 사용 중인 네트워크에 맞춰 조정해야 합니다. 수정하기 전에 원래 설정을 보존하고, 그래픽 클라이언트가 설정 저장 시 해당 파일을 다시 생성하는지 확인하세요.

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      {
        "address": "223.5.5.5",
        "domains": [
          "geosite:cn"
        ]
      }
    ],
    "queryStrategy": "UseIPv4"
  }
}

queryStrategy는 반환할 주소 체계를 제어합니다. IPv4만 사용하도록 설정하면 IPv6 경로에 문제가 있는지 확인할 수 있지만, 테스트 없이 장기간 고정해서는 안 됩니다. 네트워크에 안정적인 IPv6가 있다면 듀얼 스택을 유지하는 편이 더 적절한 경로를 얻을 수 있습니다. IPv6 주소만 있고 안정적인 출구가 없다면 도메인 조회에서 AAAA 레코드가 반환된 뒤 오래 기다리게 될 수 있습니다. 판단 기준은 네트워크 어댑터에 IPv6 주소가 표시되는지만이 아니라 시스템 라우팅과 연결 테스트여야 합니다.

분할 DNS는 DNS 조회 출구와 실제 접속 출구가 논리적으로 일치하도록 구성해야 합니다. 규칙에 따라 직접 연결하는 도메인은 직접 연결 네트워크에서 안정적으로 접근할 수 있는 DNS를 사용하고, 프록시 도메인은 코어가 프록시 출구를 통해 조회하도록 구성할 수 있습니다. 로컬 DNS로 먼저 지역화된 주소를 얻은 뒤 원격 프록시로 접속하면 대상이 적절하지 않은 콘텐츠 노드를 반환할 수 있습니다. 반대로 모든 도메인을 원격에서 조회하면 로컬 서비스가 불필요하게 원격 주소로 해석될 수도 있습니다. 규칙은 실제 접속 경로를 기준으로 정해야 합니다.

소수의 도메인만 문제가 있다면 전체 DNS를 즉시 다시 작성하지 말고 명확한 도메인 규칙과 지정 DNS로 최소 테스트를 먼저 진행하세요. 규칙이 유효한지 확인한 뒤 geosite 분류로 범위를 넓히면 됩니다. 데이터베이스를 업데이트한 뒤에는 규칙 이름이 여전히 존재하는지, 클라이언트가 올바른 파일을 불러왔는지도 확인하세요. 데이터 파일 위치, 로딩 방식과 업데이트 후 검증 방법은 GeoIP 및 GeoSite 데이터베이스 업데이트 방법에서 확인할 수 있습니다.

최종 검증에는 시스템 조회, 클라이언트 로그와 실제 접속을 모두 포함해야 합니다. 조회 결과가 안정적인지, 로그에 예상한 DNS 서버와 출구가 표시되는지, 브라우저가 해당 주소에 연결되는지 확인하세요. 세 결과가 일치해야 DNS 경로가 명확하다고 볼 수 있습니다. 로그에 대상 도메인의 DNS 요청이 전혀 보이지 않는다면 코어 외부에서 조회가 이뤄졌을 수 있으므로 시스템, 브라우저 또는 TUN 인계 설정으로 돌아가 계속 확인하세요.

시스템 프록시는 운영체제에 프록시 주소와 포트를 기록하는 기능이며, 해당 설정을 읽는 앱만 사용합니다. 클라이언트에 ‘시스템 프록시가 켜짐’으로 표시되어도 모든 프로세스의 트래픽이 인계된 것은 아닙니다. 브라우저는 대체로 시스템 프록시를 지원하지만 일부 명령줄 도구, 게임, 스토어 앱과 자체 네트워크 스택을 사용하는 프로그램은 이를 무시할 수 있습니다. 특정 앱에서만 적용되지 않는다면 먼저 다른 앱이 정상인지 확인한 뒤 시스템 설정 기록 실패인지, 대상 앱이 시스템 프록시를 사용하지 않는 것인지 판단하세요.

로컬 진입점과 시스템 설정 대조

v2rayN에서 HTTP 및 SOCKS 인바운드 포트를 기록한 다음 시스템 프록시가 127.0.0.1과 올바른 포트를 가리키는지 확인하세요. 포트를 다른 프로그램이 사용하고 있거나 원격 노드 포트를 잘못 입력해서는 안 됩니다. 앞 장의 netstat 명령으로 리슨 중인 프로세스를 확인한 뒤 명시적 프록시 매개변수로 테스트하세요. 명시적 프록시는 성공하지만 브라우저가 실패한다면 코어와 노드는 정상이고 시스템 프록시 기록, 브라우저 정책 또는 확장 프로그램이 문제입니다.

curl.exe -x http://127.0.0.1:10809 https://example.com/
curl.exe --socks5-hostname 127.0.0.1:10808 https://example.com/

첫 번째 명령은 HTTP 프록시로 테스트하고, 두 번째 명령은 SOCKS5를 사용해 프록시가 도메인을 해석하도록 합니다. 두 포트는 클라이언트의 실제 설정에 맞게 바꿔야 합니다. HTTP는 성공하고 SOCKS가 실패하면 SOCKS 인바운드를 확인하세요. SOCKS는 성공하고 HTTP가 실패하면 HTTP 인바운드 또는 혼합 포트를 점검합니다. 둘 다 성공하지만 대상 앱에 적용되지 않는다면 대개 앱이 시스템 프록시를 읽지 않거나 앱 내부 설정이 시스템 설정을 덮어쓴 것입니다.

브라우저 프록시 확장 프로그램이 시스템 프록시를 덮어쓸 수 있습니다. 점검할 때는 확장 프로그램을 임시로 끄고 모든 브라우저 프로세스를 종료한 뒤 다시 실행하세요. 일부 브라우저의 보안 DNS는 독립적으로 조회를 수행하므로 HTTP 트래픽이 시스템 프록시를 거쳐도 DNS는 다른 경로로 나가 결과가 달라질 수 있습니다. 기업 정책, 가정용 보안 프로그램과 네트워크 필터링 프로그램도 프록시 설정을 변경할 수 있으므로, 설정을 켠 직후 다시 원래대로 돌아가는지 확인하세요.

시스템 프록시와 TUN 구분

시스템 프록시는 HTTP 또는 SOCKS 프록시를 지원하는 앱에 적합하고 적용 범위가 명확해 문제가 생겨도 되돌리기 쉽습니다. TUN 모드는 가상 네트워크 어댑터와 라우팅을 통해 더 많은 트래픽을 인계하지만 DNS 가로채기, 라우팅 우선순위, MTU와 드라이버 호환성 문제가 추가됩니다. 특정 앱 하나가 시스템 프록시를 무시한다고 곧바로 TUN을 장기간 활성화하지 마세요. 먼저 앱에 독립적인 프록시 설정이 있는지 확인하고, 전역 인계가 꼭 필요할 때 최소 설정으로 TUN을 활성화하세요.

TUN을 켠 뒤 인터넷이 완전히 끊기면 먼저 시스템 프록시를 꺼서 두 연결 경로가 겹치지 않도록 하세요. 그런 다음 가상 네트워크 어댑터가 정상적으로 생성됐는지, 기본 경로가 기록됐는지, 로컬 네트워크 대역이 잘못 프록시로 보내지지 않는지 확인합니다. 원격 데스크톱, 로컬 네트워크 공유와 라우터 관리 주소는 직접 연결 규칙으로 남겨야 합니다. 그렇지 않으면 TUN 활성화 후 로컬 연결이 끊길 수 있습니다. 다른 가상 네트워크 어댑터가 있다면 라우팅 우선순위를 확인하세요. 특히 컨테이너, 가상 머신과 기업용 네트워크 소프트웨어가 만든 인터페이스를 주의해야 합니다.

클라이언트를 종료한 뒤에도 웹 탐색이 되지 않는다면 시스템 네트워크 설정에서 수동 프록시를 끄고 자동 구성 스크립트가 여전히 이전 주소를 가리키는지 확인하세요. 그다음 브라우저를 다시 실행합니다. 프록시 설정이 계속 자동으로 복구된다면 시작 프로그램과 다른 네트워크 도구를 확인하세요. v2rayN에서도 창만 닫지 말고 ‘시스템 프록시 지우기’를 사용해야 합니다. 창을 닫아도 트레이로 최소화되어 코어가 계속 실행될 수 있습니다.

수정 후에는 시스템 프록시를 따르는 브라우저, 명시적 프록시 매개변수를 사용하는 명령줄 요청, 원래 문제가 있던 앱을 각각 확인하세요. 세 결과를 비교하면 문제가 시스템 설정에 있는지 앱 자체에 있는지 알 수 있습니다. 세 가지 프록시 방식의 트래픽 범위와 선택 기준은 시스템 프록시, 전역 모드와 중국 본토 우회 모드의 차이에서 확인할 수 있습니다.

클라이언트 창이 닫히는 문제, 코어 프로세스 종료와 인터페이스 무응답은 서로 다른 세 가지 문제입니다. 창 충돌은 그래픽 런타임, 설정 데이터베이스 또는 UI 구성 요소와 관련될 수 있습니다. 코어 종료는 생성된 설정의 오류, 포트 충돌, 실행할 수 없는 코어 파일 또는 시스템 권한 때문에 발생할 수 있습니다. 인터페이스 무응답은 많은 노드, 로그 갱신, 구독 파싱 또는 보안 프로그램 검사로 인해 발생할 수 있습니다. 점검 전에 종료된 것이 그래픽 클라이언트인지 코어 프로세스인지 먼저 확인하세요.

로그와 재현 조건 저장

첫 충돌 직후 설정을 지우거나 반복해서 재설치하지 마세요. 먼저 코어 시작, 구독 업데이트, 설정 열기, TUN 전환 또는 설정 가져오기처럼 충돌이 발생한 동작을 기록하세요. 클라이언트 로그, 코어 로그와 시스템 이벤트 발생 시점을 저장하고 당시의 라우팅 모드와 노드 유형도 기록합니다. 반복 재현되는 문제는 간헐적인 충돌보다 찾기 쉽습니다. 매번 같은 동작에서 발생한다면 해당 동작이 읽는 설정이나 시스템 구성 요소를 우선 확인하세요.

v2rayN을 시작한 직후 코어가 종료되면 먼저 시스템 프록시를 꺼서 로컬 포트 오류로 인터넷이 끊기는 일을 방지하세요. 코어 출력의 첫 번째 오류를 확인합니다. 흔한 유형으로는 JSON 구문 오류, 잘못된 필드 유형, 존재하지 않는 라우팅 태그, 인바운드 포트 점유와 파일 접근 실패가 있습니다. 이후의 반복 시도 메시지는 대개 결과일 뿐입니다. 그래픽 인터페이스에서 설정을 생성했다면 기본 라우팅과 기본 DNS로 되돌린 뒤 일반 구독 노드 하나를 선택해 사용자 지정 설정이 원인인지 확인하세요.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "port": 10808,
      "listen": "127.0.0.1",
      "protocol": "socks"
    }
  ]
}

위 조각은 필드 유형과 JSON 구두점을 대조하기 위한 올바른 SOCKS 인바운드 구조의 예이며, 전체 아웃바운드 설정은 아닙니다. JSON에는 후행 쉼표를 사용할 수 없고 문자열은 큰따옴표로 감싸야 하며 포트는 숫자여야 합니다. 수동 설정 검증에 실패하면 먼저 클라이언트가 자동 생성한 설정으로 복구하고 여러 위치를 반복해서 편집하지 마세요. 그래픽 클라이언트는 시작 시 임시 파일을 덮어쓸 수 있으므로 생성 파일을 직접 수정해도 장기 설정으로 유지되지 않을 수 있습니다.

포트, 권한과 실행 환경

포트 충돌이 발생하면 코어가 리슨할 수 없습니다. netstat -ano로 점유 프로세스를 찾은 뒤 모든 네트워크 프로세스를 바로 종료하지 말고 해당 프로세스의 용도를 확인하세요. 클라이언트에서 로컬 인바운드 포트를 변경해 테스트할 수 있습니다. 새 포트에서 시작된다면 기존 포트가 이미 사용 중인 것입니다. 새 포트를 유지할지 충돌 프로그램을 종료할지 결정하세요. 포트를 변경한 뒤에는 시스템 프록시와 앱 내 프록시 주소도 함께 변경해야 이전 포트로 계속 연결하지 않습니다.

데스크톱 클라이언트는 해당 실행 환경에 의존합니다. 창이 전혀 열리지 않고 시스템 이벤트에 런타임 오류가 기록된다면 Windows 설치 패키지 페이지에서 데스크톱 버전과 클래식 WPF 버전의 적용 조건을 다시 확인하세요. 서로 다른 디렉터리의 프로그램 파일과 설정 파일을 섞거나 일부 파일만 덮어쓰지 마세요. 업데이트할 때는 클라이언트와 코어를 정상적으로 종료하고 설정을 백업한 뒤 새 설치 패키지를 별도 디렉터리에 설치해 테스트하세요.

보안 프로그램이 코어 프로세스 생성, 로컬 포트 리슨 또는 가상 네트워크 어댑터 생성을 차단할 수 있습니다. 차단 기록과 파일 출처를 확인한 다음 필요한 프로그램만 최소 범위로 허용하세요. 장기적인 해결책으로 시스템 보호 기능 전체를 끄지 마세요. 클라이언트가 일반 모드에서는 정상이고 TUN 모드에서 충돌한다면 가상 네트워크 어댑터 드라이버, 관리자 권한과 다른 네트워크 필터 드라이버를 중점적으로 확인하세요. 구독 업데이트 때만 무응답이 발생한다면 노드 수, 필터 표현식과 구독 반환 콘텐츠를 점검하세요.

설정 파일이 손상됐다면 원래 디렉터리를 백업한 뒤 새 설정을 만들어 클라이언트가 기본 파일을 생성하도록 하고, 노드 하나만 수동으로 추가해 테스트하세요. 새 설정이 정상이라면 구독, 라우팅과 설정을 항목별로 옮기고 이전 디렉터리 전체를 바로 복사하지 마세요. 특정 항목을 옮긴 뒤 다시 충돌하면 문제의 원인을 해당 항목으로 좁힐 수 있습니다. 새 설정에서도 충돌한다면 실행 환경, 권한, 그래픽 드라이버와 시스템 로그를 확인하세요.

문제 처리가 끝나면 콜드 스타트, 구독 업데이트, 노드 전환, 시스템 프록시 활성화와 정상 종료의 다섯 동작을 검증해야 합니다. 정상 종료 후 시스템 프록시가 정리됐는지 확인하고, 다시 시작한 뒤 설정을 읽을 수 있는지도 확인하세요. 한 번 연결에 성공한 것만으로 설정 데이터베이스와 종료 절차가 정상이라고 볼 수 없습니다. Windows 설치와 실행 환경의 전체 점검은 v2rayN Windows 설치 및 설정 전체 과정을 참고하세요.

Android의 v2rayNG와 v2flyNG는 시스템 VPN 인터페이스를 통해 트래픽을 인계하므로, 문제는 노드 설정 외에도 백그라운드 제한, 비공개 DNS, 배터리 정책, 네트워크 전환과 다른 VPN 앱에서 발생할 수 있습니다. v2rayNG는 Xray 코어를 사용하고 v2flyNG는 v2fly 코어를 사용합니다. 두 앱은 서로 다른 코어의 호환성을 비교하는 데 사용할 수 있지만 동시에 활성화할 수 있는 VPN 연결은 하나뿐입니다. 점검할 때는 다른 클라이언트를 완전히 중지하고 화면만 백그라운드로 전환하지 마세요.

연결 버튼은 성공했지만 앱에 접속할 수 없음

먼저 상태 표시줄에 VPN 아이콘이 나타나는지 확인한 다음, 클라이언트 로그에 로컬 VPN 인터페이스가 생성됐는지 확인하세요. 아이콘이 나타나지 않는다면 시스템 권한 승인이 완료되지 않았거나 다른 VPN이 사용 중이거나 클라이언트가 시스템에 의해 차단된 경우가 많습니다. 아이콘은 있지만 모든 앱이 인터넷에 연결되지 않는다면 노드, DNS와 라우팅을 확인하세요. 일부 앱만 문제라면 앱별 프록시, 우회 목록과 앱 자체의 전용 네트워크 설정을 점검하세요.

앱별 프록시는 모드를 잘못 이해하면 반대 결과를 만들기 쉽습니다. ‘선택한 앱만 프록시’와 ‘선택한 앱 우회’는 서로 반대 의미이며, 앱을 업데이트하거나 다시 설치하면 앱 식별자가 바뀔 수도 있습니다. 점검할 때는 먼저 앱별 기능을 끄고 모든 앱이 같은 경로를 사용하도록 하세요. 기본 연결이 정상인 뒤 목록에 앱을 하나씩 추가합니다. 기능을 켠 뒤에도 특정 앱이 직접 연결된다면 독립 프로세스, 시스템 구성 요소 또는 내장 서비스를 사용하는지 확인하세요.

Android의 비공개 DNS가 클라이언트의 DNS 인계와 충돌할 수 있습니다. 노드는 연결 성공으로 표시되지만 도메인 요청이 오래 대기하고 일부 IP에는 직접 접속되는 증상이 나타날 수 있습니다. 비공개 DNS를 자동으로 임시 변경한 뒤 클라이언트를 다시 연결해 테스트하세요. 문제가 사라진다면 시스템 비공개 DNS와 클라이언트 중 어느 쪽이 해석을 담당할지 결정하고 두 경로가 불명확하게 연쇄되지 않도록 하세요. 브라우저 자체에서 보안 DNS를 사용할 수도 있으므로 별도로 확인해야 합니다.

백그라운드 연결 끊김과 네트워크 전환

화면을 잠근 뒤 연결이 끊기는 현상은 대개 배터리 최적화, 백그라운드 활동 제한 또는 시스템 정리 기능과 관련됩니다. 사용하는 클라이언트의 백그라운드 실행을 허용하고 절전 모드가 VPN을 제한하는지 확인하세요. 기기마다 설정 이름은 다르지만 목표는 동일합니다. 화면이 잠긴 뒤에도 클라이언트와 코어 프로세스가 네트워크를 유지하도록 허용해야 합니다. 같은 종류의 클라이언트 여러 개에 자동 시작과 상시 실행을 동시에 설정하지 마세요. VPN 권한을 서로 차지하려 해 상태가 복잡해질 수 있습니다.

Wi-Fi에서 모바일 네트워크로 전환하면 기존 연결의 로컬 주소와 라우팅이 바뀝니다. 일부 노드는 자동으로 재연결되지만 다른 연결은 이전 네트워크에 머물 수 있습니다. 전환 후 트래픽이 없으면 클라이언트에서 연결을 중지하고 시스템 네트워크가 안정될 때까지 기다린 뒤 다시 시작하세요. 자주 발생한다면 로그에서 네트워크 사용 불가, 인터페이스 종료 또는 DNS 시간 초과가 나타나는지 확인하세요. ‘네트워크 전환 후 실패’와 ‘고정 네트워크에서 계속 실패’를 따로 기록해야 합니다. 두 문제의 해결 방향은 다릅니다.

구독 업데이트가 실패하면 먼저 현재 네트워크에서 브라우저로 구독 요청을 열 수 있는지 확인한 뒤 클라이언트 업데이트 로그를 확인하세요. 모바일 네트워크는 백그라운드 데이터, 로밍 데이터 또는 데이터 절약 모드에 제한이 있을 수 있습니다. 구독은 성공했지만 노드에 연결할 수 없다면 이 문서의 시간 초과 장에서 주소, 포트, TLS와 전송 필드를 확인하세요. 2015년 이후 출시된 주요 기기라면 일반적으로 arm64 설치 패키지를 우선 선택합니다. 아키텍처를 확인할 수 없다면 범용 버전을 사용하고, 자세한 경로는 Android 클라이언트 다운로드에서 확인하세요.

v2rayNG와 v2flyNG는 지원하는 코어 범위가 다릅니다. 특정 노드가 v2rayNG에서는 작동하지만 v2flyNG에서 실패한다고 곧바로 네트워크 문제로 단정하지 말고, 먼저 해당 코어가 프로토콜과 전송 필드를 지원하는지 비교하세요. 비교 테스트는 같은 네트워크, 같은 노드와 같은 DNS 조건에서 진행하고 다른 클라이언트는 완전히 중지해야 합니다. 두 클라이언트 모두 실패하면 노드와 시스템 네트워크를 확인하고, 하나만 실패하면 해당 클라이언트의 첫 번째 코어 오류를 저장해 호환성을 판단하세요.

모바일 환경의 최종 검증에는 포그라운드 접속, 화면 잠금 후 복구, Wi-Fi와 모바일 네트워크 전환, 구독 업데이트와 앱별 규칙을 포함해야 합니다. 한 번에 모든 시스템 설정을 바꾸지 말고 각 항목을 따로 테스트하세요. 기본 연결이 안정된 뒤 비공개 DNS, 절전 정책과 앱 목록을 원래대로 복구합니다. 특정 항목을 복구한 뒤 문제가 재현되면 충돌 원인을 확인할 수 있습니다. 최초 구독 가져오기를 아직 완료하지 않았다면 빠른 시작 가이드로 돌아가 기본 설정 절차를 따르세요. 초기화 누락을 실행 중 장애로 오해하지 않도록 해야 합니다.