V2Ray 문제 해결 가이드

인터넷 연결 안 됨: 연결 경로부터 나눠서 확인

클라이언트가 실행 중으로 표시되더라도 브라우저 요청이 노드를 통해 전달된다는 뜻은 아닙니다. 먼저 모든 앱에서 연결이 안 되는지, 브라우저만 안 되는지 확인하세요. 모든 사이트가 열리지 않는지 특정 도메인만 안 되는지도 비교합니다. 클라이언트를 종료한 뒤 일반 연결이 복구되는지도 확인하세요. 이 세 가지 비교로 시스템 네트워크, 앱 연결 방식, 대상 서비스 중 어느 부분에 문제가 있는지 좁힐 수 있습니다. 테스트할 때는 평소 열리는 HTTPS 페이지 하나를 정해 반복해서 사용하세요. 대상을 계속 바꾸면 웹사이트 자체의 문제를 혼동할 수 있습니다.

최소한의 테스트 환경 구성

다른 프록시 프로그램을 종료하고 브라우저 프록시 확장 프로그램을 일시 중지한 뒤 TUN을 끄세요. v2rayN의 일반 로컬 프록시만 남기고, 설정이 완전한 노드 하나를 선택해 현재 활성 서버인지 확인합니다. 메인 창 로그에서 코어가 정상적으로 시작되었는지도 살펴보세요. 첫 설정을 마치지 않았다면 고급 라우팅부터 변경하지 말고 빠른 시작 가이드에서 기본 연결을 완료하세요. 다른 프로그램을 종료하는 이유는 포트 충돌과 프록시 중복 적용을 배제하기 위해서이지, 평소 사용 방식을 계속 바꾸라는 뜻은 아닙니다.

설정에서 실제 로컬 SOCKS 또는 혼합 리스너 포트를 확인해 기록하세요. 아래 명령의 10808은 해당 포트에서 SOCKS 서비스를 제공할 때만 사용할 수 있습니다. 포트를 변경했다면 명령의 값도 함께 바꾸세요. 리스너 주소가 127.0.0.1이면 이 컴퓨터의 요청만 받으며, 일반적인 로컬 사용 방식입니다. 이 컴퓨터의 브라우저 문제를 해결하기 위해 LAN 연결을 켜거나 리스너 주소를 모든 네트워크 인터페이스로 변경하지 마세요. 불필요하게 접근 범위가 넓어집니다.

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --head https://example.com/

이 명령은 로컬 SOCKS 프록시를 명시적으로 사용하고 대상 도메인 조회를 프록시에 맡깁니다. 브라우저 프록시 설정과 별도로 연결 경로를 비교할 때 유용합니다. Windows에서 같은 이름의 명령을 바로 사용할 수 없다면 터미널에서 curl.exe를 실행하세요. HTTP 응답을 받았다면 요청이 적어도 어느 응답 지점에는 도달한 것입니다. 상태 코드가 성공을 뜻하지 않더라도 바로 프록시 실패로 단정하지 마세요. 인증서 오류, 연결 거부, 연결 시간 초과는 서로 다른 단계의 문제이므로 오류 내용을 빠짐없이 기록하세요. 단순히 '열리지 않음'이라고만 적지 마세요.

결과에 따라 다음 점검 항목 선택

로그도 함께 확인하세요. 명령을 실행한 시각 전후로 해당 대상 요청이 표시되는지 살펴봅니다. 로그가 없다면 현재 로그 수준이 접속 기록을 남기는지 확인하고, 명령이 실행 중인 인스턴스를 가리키는지 점검하세요. 대상 요청은 보이지만 예상과 다른 아웃바운드 태그가 표시된다면 라우팅 규칙과 최종 기본 아웃바운드를 확인합니다. 비교를 위해 잠시 '모두 프록시 사용' 라우팅으로 범위를 좁힐 수 있지만, 테스트가 끝나면 원래 정책으로 되돌리세요. 모드를 바꾸는 것은 모든 문제에 통하는 해결책이 아닙니다.

특정 사이트만 실패한다면 같은 노드로 다른 대상을 열어 보고, 같은 사이트를 다른 노드로도 접속해 보세요. 특정 사이트에서 접근 거부, 캡차 또는 지역 제한 안내가 나타난다면 보통 애플리케이션 계층 연결은 이미 이루어진 것입니다. 로컬 리스너 포트를 계속 바꿔도 대상 측 제한은 해결되지 않습니다. 브라우저에서 인증서 날짜 오류가 표시되면 먼저 시스템 시간과 시간대를 확인하세요. 오류를 숨기려고 인증서 검증을 끄지 말고, 페이지가 표시되기만 하면 안전하고 올바른 연결이라고 판단하지 마세요.

노드 시간 초과: 탐지 결과와 실제 연결 구분

목록에 표시되는 시간 초과는 한 가지 문제만을 의미하지 않습니다. TCP 포트 연결 여부만 확인하는 테스트도 있고, 노드를 통해 지정한 URL에 요청을 보내는 테스트도 있습니다. 측정 대상, 핸드셰이크, 로컬 DNS의 영향도 받을 수 있습니다. 먼저 어떤 테스트를 실행했는지 확인한 다음 정상적으로 열리는 웹페이지에서 재현해 보세요. TCP 연결 성공은 해당 주소의 서비스가 응답한다는 뜻일 뿐, 프로토콜 매개변수, 인증 정보, 전송 설정까지 올바르다는 뜻은 아닙니다. 탐지 시간 초과도 테스트 대상이 응답하지 않았기 때문일 수 있으므로 노드 전체가 작동하지 않는다고 단정하지 마세요.

주소·포트·핸드셰이크 순서로 확인

현재 노드의 편집 창을 열고 서버 주소, 포트, 프로토콜을 먼저 확인한 다음 전송 방식, TLS, 서버 이름과 관련 전송 필드를 살펴보세요. 구독에서 가져온 설정은 노드 이름만 보고 추측하지 말고 서비스 제공자가 안내한 원래 매개변수와 대조하는 것이 좋습니다. 노드 이름은 화면에 표시되는 명칭으로 자유롭게 지정할 수 있으며 실제 프로토콜이나 회선을 나타내지 않습니다. 주소를 복사할 때 앞뒤 공백, 한글 문장부호, 줄바꿈이 들어가지 않았는지 확인하세요. 포트 필드에는 숫자만 입력하고 프로토콜 접두사나 URL 경로를 넣지 마세요.

서버 주소가 도메인이라면 원격 연결 전에 클라이언트가 먼저 해당 주소를 조회해야 합니다. 서버에 연결하기도 전에 로그에 조회 실패가 표시된다면 대상 웹사이트의 분할 라우팅을 변경하지 말고 노드 도메인 조회부터 확인하세요. 시스템 터미널에서 서버 도메인을 조회해 현재 네트워크와 신뢰할 수 있는 다른 네트워크의 결과를 비교할 수 있습니다. 조회된 특정 IP 주소를 일반적인 해결책인 것처럼 영구 고정하지 마세요. 접속 지점은 여러 주소로 분산될 수 있으며 고정 주소를 사용하면 이후 변경 사항을 놓칠 수 있습니다.

Test-NetConnection -ComputerName example.com -Port 443

위 명령은 Windows PowerShell에서 TCP 연결을 확인하는 구문이며 예시 도메인은 실제로 사용할 수 있는 노드가 아닙니다. 점검할 때는 실제 노드 주소와 서비스 포트를 사용하세요. 이 명령은 프록시 프로토콜 인증을 수행하지 않고 UDP 전송도 확인하지 않습니다. TCP 테스트는 성공했는데 클라이언트 핸드셰이크가 실패한다면 TLS 서버 이름, 전송 경로, 인증 필드와 기기 시간을 중점적으로 확인하세요. REALITY 설정은 서버 이름, 공개 키, 짧은 ID를 제공자 자료와 하나씩 대조해야 합니다. 값을 무작위로 바꾸며 맞는 설정을 찾으려 하지 마세요.

교차 테스트로 문제 범위 좁히기

원래 작동하던 노드 두 개를 선택해 현재 네트워크에서 각각 연결해 보세요. 그런 다음 같은 노드를 다른 네트워크에서도 연결합니다. 모든 노드가 한 네트워크에서만 실패한다면 로컬 네트워크, 라우터 또는 네트워크 경로 문제일 가능성이 큽니다. 특정 노드가 여러 네트워크에서 계속 실패한다면 원격 서비스나 해당 노드 설정을 살펴보세요. 네트워크를 바꿀 때는 대상 URL과 클라이언트 설정을 그대로 유지해 코어, 프로토콜, 라우팅을 동시에 변경하지 않도록 합니다. 모바일 핫스팟 테스트는 데이터를 사용할 수 있으므로 요청을 적게 보내고 대용량 파일을 내려받지 마세요.

로그의 connection refused는 대상 포트에서 서비스가 실행되지 않거나 연결이 명시적으로 거부된 경우에 흔히 나타납니다. timeout은 대기 시간이 초과되었다는 뜻일 뿐 어느 쪽에서 데이터가 차단됐는지는 알려 주지 않습니다. EOF 또는 연결 재설정은 연결이 일찍 끝났다는 의미이므로 다이얼링, TLS 핸드셰이크, 인증 중 어느 시점에 발생했는지 함께 확인해야 합니다. 오류에 표시된 대상 주소가 현재 활성 노드와 일치하는지 살펴 구독 업데이트나 백그라운드 탐지 로그를 잘못 읽지 않도록 하세요. 계속 재시도하면 로그만 늘어납니다. 같은 요청 전후의 로그 몇 줄을 확인하는 편이 더 유용합니다.

컴퓨터가 절전 모드에서 깨어난 뒤나 유선에서 무선 네트워크로 전환한 뒤 시간 초과가 발생한다면 연결을 중지하고 코어를 다시 시작해 이전 연결과 라우팅을 정리하세요. 필요한 경우 서버를 전부 삭제하는 대신 클라이언트를 종료했다가 다시 실행합니다. 네트워크가 바뀐 뒤 장시간 연결에 이전 경로가 남아 있을 수 있으며 연결을 다시 만들면 해결되기도 합니다. 재시작 후 잠시만 복구된다면 연결이 끊기기까지 걸리는 시간과 화면 절전의 연관성을 기록하고 네트워크 절전 설정과 백그라운드 정책을 확인하세요. 잠깐 복구된 것을 원격 문제 해결로 오해하지 마세요.

구독 실패: 가져오기와 파싱을 나눠서 확인

구독 업데이트는 두 단계로 이루어집니다. 먼저 클라이언트가 구독 URL에 요청을 보내고, 받은 내용을 노드 설정으로 파싱합니다. 다운로드 실패, 빈 응답, 형식 인식 실패, 노드 중복은 각각 다르게 처리해야 합니다. 업데이트 버튼을 눌렀는데 노드가 늘지 않았다고 해서 반드시 네트워크 문제인 것은 아닙니다. 내용이 바뀌지 않았거나 그룹 필터가 결과를 숨겼을 수도 있고, 구독에 현재 코어가 지원하지 않는 필드가 포함됐을 수도 있습니다. 먼저 사용 중인 설정을 보관하고 현재 그룹 이름과 노드 수를 기록한 뒤 업데이트하세요. URL 유효성을 확인하려고 목록을 비우지 마세요.

구독 항목과 URL 유형 확인

v2rayN의 구독 그룹 설정에서 해당 그룹의 URL을 확인하세요. 로그인 페이지, 결제 페이지, 단일 노드 공유 문자열이 아닌 전체 구독 링크를 복사해야 합니다. v2rayNG에서는 구독 설정을 열어 해당 항목의 주소와 활성화 상태를 확인한 뒤 업데이트하세요. 단일 노드 공유 링크와 여러 노드를 반환하는 구독 URL은 용도가 다릅니다. 구독 URL만 받는 입력란에 단일 노드 링크를 넣으면 지원하지 않는 주소 또는 빈 응답이 표시될 수 있습니다. 업데이트를 반복해도 형식은 바뀌지 않습니다.

URL의 쿼리 매개변수는 구독을 식별하는 데 사용되는 경우가 많습니다. 끝부분이 누락되면 서버가 로그인 페이지나 오류 응답을 반환할 수 있습니다. 메신저나 메모 앱에서 줄바꿈, 문장부호, 자동 링크 처리로 주소가 잘릴 수 있으므로 원본에서 다시 복사하세요. 전체 주소는 로컬에서만 확인하고 스크린샷에서는 매개변수를 가리세요. 브라우저에서 주소를 열 수 있다는 것은 브라우저의 네트워크 경로로 응답을 받았다는 뜻일 뿐입니다. 클라이언트도 같은 프록시와 요청 헤더를 사용한다거나 응답이 노드 목록이라는 뜻은 아닙니다.

먼저 업데이트 로그에서 HTTP 상태를 확인하세요. 인증에 실패했다면 링크 만료나 권한 변경 여부를 확인합니다. 요청이 너무 잦다는 응답이 오면 계속 누르지 말고 제공자의 업데이트 제한에 따라 기다리세요. 서버 오류는 발생 시간을 기록하고 잠시 뒤 다시 시도합니다. 상태는 성공인데 파싱이 실패한다면 응답이 웹페이지, 접근 안내 또는 다른 형식의 설정일 수 있습니다. 구독 URL과 노드 인증 정보가 노출될 수 있으므로 응답 전체를 공개 변환 도구에 붙여 넣지 마세요. 출처가 분명하고 로컬에서 처리할 수 있는 방법으로 형식을 변환하세요.

업데이트 요청의 연결 경로 확인

일부 클라이언트는 구독 업데이트에 직접 연결 또는 프록시 사용을 설정할 수 있습니다. 옵션 위치와 기본 동작은 화면마다 다를 수 있으므로 현재 버전의 설정과 로그를 기준으로 확인하세요. 기존 노드가 작동하지 않고 구독 업데이트도 해당 노드에 의존하면 연결을 복구하려면 업데이트가 필요하지만 업데이트하려면 연결이 필요한 순환 문제가 생깁니다. 먼저 직접 연결로 업데이트를 시도하세요. 구독 주소에 프록시로만 접근할 수 있다면 작동이 확인된 연결을 임시로 사용합니다. 업데이트 경로만 한 번에 바꾸고 구독 URL은 동시에 변경하지 않아야 어떤 변경이 효과가 있었는지 알 수 있습니다.

TLS 또는 인증서 오류가 표시되면 먼저 기기 시간, 시스템 인증서 환경, 주소 철자를 확인하세요. 회사 네트워크나 웹 로그인이 필요한 공용 네트워크에서는 인증 페이지가 반환될 수 있습니다. 브라우저에서 네트워크 로그인을 완료한 뒤 구독을 업데이트하세요. 인증서 오류 무시로 구독 문제를 해결하려 하지 마세요. 구독 내용은 이후 원격 연결에 영향을 주므로 다운로드 성공 여부보다 출처가 올바른지가 중요합니다. 주소가 다른 곳으로 리디렉션된다면 낯선 중간 주소로 바로 바꾸지 말고 제공자에게 최종 접속 주소가 변경됐는지 확인하세요.

내용을 가져왔는데 노드가 없다면 그룹 필터, 검색 조건, 중복 제거 옵션, 노드 유형을 확인하세요. 일부 구독은 다른 설정 체계를 대상으로 하므로 확장자가 비슷하다고 바로 가져올 수 있는 것은 아닙니다. 특정 코어 기능에 의존하는 필드도 있어 오래된 코어에서는 파싱 또는 실행 단계에서 거부될 수 있습니다. 먼저 시스템 아키텍처에 맞는 클라이언트를 업데이트한 다음 원본 구독을 다시 가져오세요. 알 수 없는 필드를 전부 수동으로 삭제하지 마세요. 저장은 되지만 인증할 수 없는 불완전한 노드가 만들어질 수 있습니다.

업데이트에 성공한 뒤에는 활성 노드가 그대로 있는지, 라우팅이 이전 그룹을 참조하는지, 자동 선택으로 서버가 바뀌었는지 확인하세요. 이름이 같아도 주소가 같다는 보장은 없고, 이름이 달라져도 서버 측 설정이 바뀌었다는 뜻은 아닙니다. 자세한 절차와 형식 차이는 구독 링크 가져오기를 참고하세요. 다른 사람에게 문제를 설명할 때는 응답 상태, 파싱 오류, 클라이언트 이름만 공유하고 실제로 사용할 수 있는 구독 URL은 공개하지 마세요.

속도 저하: 지연 시간·처리량·변동 구분

'느리다'는 현상은 페이지 응답이 시작되기까지 오래 걸리는 경우, 다운로드 속도가 계속 낮은 경우, 연결 속도가 오르내리는 경우로 나눌 수 있습니다. 목록의 지연 시간 숫자 하나로 전체 사용 경험을 판단할 수 없습니다. 병목이 연결 과정에 있는지 데이터 전송 중에 있는지 먼저 확인하고, 같은 시간대·대상·네트워크에서 비교하세요. 짧은 시간에 수십 개 노드를 반복해서 바꾸면 비교할 만한 결과를 얻기 어렵고 대상 서비스의 속도 제한을 유발할 수도 있습니다. 대규모 자동 속도 측정보다 통제된 소수의 비교가 원인을 파악하는 데 더 유용합니다.

일반 연결 속도 기준부터 확인

시스템 업데이트, 클라우드 동기화, 기타 대용량 작업을 일시 중지하고 Wi-Fi 신호와 로컬 네트워크가 정상인지 확인하세요. 클라이언트를 끈 상태에서 평소 직접 연결되는 서비스를 열어 같은 문제가 있는지 살펴봅니다. 이때도 느리다면 로컬 대역폭 사용량, 무선 간섭, 라우터 부하부터 점검하세요. 기준 테스트는 네트워크 연결 상태만 보여 주며 노드의 실제 속도를 예측할 수는 없습니다. 다운로드 테스트는 서비스 데이터도 사용합니다. 사용량 한도가 있는 구독이라면 짧고 중단 가능한 테스트를 선택하고 요금 부과 방식을 미리 확인하세요.

그다음 노드를 고정하고 같은 페이지를 반복해서 열어 첫 방문과 이후 방문을 비교하세요. 처음에만 느리고 이후 정상이라면 DNS, TLS 연결 설정 또는 연결 재사용의 영향일 수 있습니다. 매번 느리다면 로그에서 재연결이 잦은지, 대상 주소가 반복해서 바뀌는지 확인하세요. 브라우저 개발자 도구를 사용하면 첫 바이트 대기와 콘텐츠 다운로드 시간을 구분하는 데 도움이 됩니다. 페이지 자체의 스크립트와 광고 요청도 로딩 시간에 영향을 줍니다. 프록시 경로를 테스트할 때 복잡한 페이지 전체가 로드되는 시간만을 유일한 기준으로 삼지 마세요.

추가 경로와 리소스 경쟁을 단계별로 제외

브라우저 프록시 확장 프로그램, 시스템 프록시, TUN을 동시에 사용하는지, 별도의 프록시를 앞단에 추가했는지 확인하세요. 여러 경로가 겹치면 핸드셰이크 비용이 커지거나 루프가 발생할 수 있습니다. 명확한 연결 방식 하나만 남기고 같은 요청을 테스트하세요. 일반 시스템 프록시는 정상인데 TUN에서 느리다면 모든 노드를 즉시 바꾸기보다 가상 네트워크 어댑터 라우팅, DNS 가로채기, 다른 네트워크 프로그램과의 충돌을 먼저 확인하세요. 노드에서 대상 서비스까지의 경로와 이 컴퓨터에서 노드까지의 경로 모두 성능 병목이 될 수 있습니다.

특히 사양이 낮은 기기, 동시 연결이 많은 환경, 복잡한 라우팅 규칙에서는 코어 프로세스의 CPU·메모리·네트워크 사용량을 확인하세요. 리소스 사용량이 높다면 동시에 실행 중인 작업과 불필요한 디버그 로그를 줄인 뒤 다시 측정합니다. 무작정 멀티플렉싱을 켜거나 암호화 검증을 끄고 출처 불명의 매개변수를 추가하는 방식으로 속도를 높이려 하지 마세요. 멀티플렉싱 효과는 프로토콜, 서버 지원 여부, 연결 형태에 따라 다릅니다. 설정이 맞지 않으면 실패율이 오히려 높아질 수 있으므로 안정적으로 연결되고 호환성이 확인된 상태에서 성능을 조정하세요.

다운로드 시작 후 몇 초 동안은 정상인데 이후 계속 느려진다면 대상별·시간대별로 비교해 대상의 속도 제한, 서비스 사용량 정책, 공유 회선 혼잡 여부를 확인하세요. 같은 시간에 모든 대상이 느려진다면 시간대를 기록하고 다른 노드로 비교합니다. 다운로드 출처 하나만 문제라면 노드를 바꿔도 해결되지 않을 수 있습니다. 속도 측정 사이트는 서로 다른 서버를 선택할 수 있으므로 결과가 일상적인 앱 사용 경험과 같지는 않습니다. 같은 출처의 같은 파일로 짧게 비교할 수 있지만 출처가 불분명한 대용량 파일을 내려받을 필요는 없습니다.

UDP를 사용하는 앱은 웹페이지의 TCP 경로와 다르게 동작할 수 있습니다. 웹은 정상인데 실시간 통신이 끊기거나 느리다면 해당 프로토콜, 노드, 연결 방식이 필요한 UDP 트래픽을 지원하는지 확인하고 패킷 손실과 네트워크 전환 여부도 살펴보세요. 특정 기능이 느리다는 이유만으로 모든 트래픽을 가로채도록 설정하지 마세요. MTU가 맞지 않으면 일부 연결이 멈출 수 있지만 근거 없이 값을 낮추지 마세요. TUN에서만 큰 응답이 멈춘다면 기존 값을 기록하고 다른 설정은 유지한 채 소폭으로 하나씩 시험한 뒤 개선이 없으면 즉시 원래대로 되돌리세요.

한동안 사용한 뒤에만 느려진다면 기기 온도, 절전 모드, 백그라운드 작업, 로그 파일 증가도 확인하세요. 컴퓨터를 오래 켜 둔 뒤 연결을 다시 만들어 비교해 볼 수 있지만 재시작은 원인을 좁히기 위한 방법일 뿐입니다. 문제가 반복된다면 매번 재부팅하지 말고 발생 조건을 기록하세요. 어떤 코어가 더 빠른지 비교하기 전에 두 번의 테스트에서 같은 노드 매개변수, 라우팅, 대상을 사용했는지 확인해야 합니다. 그렇지 않으면 네트워크 조건 변화일 뿐 코어 차이를 증명하지 못할 수 있습니다.

DNS 문제: 먼저 조회 주체 확인

DNS 문제 해결은 공개 DNS 주소를 바꾸는 것부터 시작하지 말고 어떤 구성 요소가 조회를 수행하는지 확인해야 합니다. 시스템 리졸버, 브라우저의 암호화 DNS, 클라이언트 코어 DNS, TUN DNS 가로채기가 동시에 작동할 수 있습니다. 노드 서버 도메인과 최종 웹사이트 도메인도 서로 다른 두 번의 조회입니다. 전자는 프록시 진입점을 찾고 후자는 대상에 연결할 때 사용합니다. 진입점 도메인을 조회할 수 없다면 대상 도메인의 DNS 설정이 올바르더라도 인터넷에 연결할 수 없습니다. 두 경로를 혼동하면 설정을 계속 바꾸면서도 문제가 해결되지 않습니다.

통제된 요청으로 조회 위치 비교

오류에 표시된 도메인과 요청을 보낸 프로세스를 기록해 구독 URL, 노드 진입점, 대상 웹사이트 중 무엇인지 구분하세요. 시스템 터미널에서 실행한 조회는 현재 시스템의 DNS 경로만 테스트하며 브라우저나 코어의 실제 결과를 보여 주지는 않습니다. 브라우저는 정상인데 다른 프로그램이 실패한다면 브라우저에서 자체 암호화 DNS를 사용하는지 확인하세요. 프록시를 명시하면 정상인데 직접 연결이 실패한다면 시스템 DNS 또는 직접 연결 네트워크 문제일 수 있습니다. 비교할 때는 같은 대상을 사용하고 다른 도메인의 성공 결과로 현재 도메인의 문제를 대신 판단하지 마세요.

nslookup example.com

curl --proxy socks5://127.0.0.1:10808 --connect-timeout 10 --head https://example.com/
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --head https://example.com/

두 프록시 명령의 차이는 대상 도메인을 어느 쪽에서 조회하는지입니다. socks5는 보통 로컬에서 먼저 조회하고, socks5h는 도메인 조회를 프록시에 맡깁니다. 후자는 성공하고 전자는 실패한다면 로컬 DNS를 우선 확인하세요. 둘 다 실패한다면 원격 연결과 코어 로그를 계속 살펴봅니다. 명령에 지정한 로컬 포트가 실제 설정과 일치해야 합니다. 이 비교가 모든 앱의 동작 방식까지 증명하는 것은 아닙니다. 앱이 직접 조회하거나 캐시된 주소를 사용할 수도 있습니다.

DNS 경로와 라우팅 관계 확인

v2rayN에서 DNS 및 라우팅 설정을 찾아 현재 값을 먼저 확인한 뒤 DNS 요청을 직접 연결할지 프록시로 보낼지 판단하세요. 원격 암호화 DNS를 설정해도 해당 DNS 서비스에 연결할 수 있어야 합니다. 주소를 입력하기만 하면 사용할 수 있는 경로가 자동으로 만들어진다고 가정하지 마세요. DNS 서비스의 도메인 조회가 아직 연결되지 않은 동일한 프록시에 의존하면 시작 단계에서 의존성 순환이 생길 수 있습니다. 한꺼번에 모든 DNS 항목을 바꾸지 말고 진입점 조회, DNS 서비스 연결, 대상 조회 결과를 각각 확인하세요.

아래는 V2Ray 호환 설정에서 흔히 볼 수 있는 DNS 필드 구조로, 서버와 조회 정책의 역할을 이해하기 위한 예시입니다. 바로 가져올 수 있는 완성된 노드 설정은 아닙니다. GUI 클라이언트는 시작할 때 설정 파일을 다시 생성할 수 있으므로 해당 설정 화면에서 변경하고 실행 중인 임시 파일을 직접 편집하지 마세요. 코어와 클라이언트에 따라 확장 필드 지원 여부가 다릅니다. 로그에서 알 수 없는 필드나 유효하지 않은 정책이 표시되면 다른 설정 체계의 전체 구성을 복사하지 말고 현재 코어가 지원하는 범위로 돌아가세요.

{
  "dns": {
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

주소를 조회했다고 해서 실제로 사용할 수 있는 것은 아닙니다. 결과에 IPv4와 IPv6가 모두 포함되는지, 현재 네트워크에서 해당 주소 계열로 실제 연결할 수 있는지 확인하세요. IPv6 주소를 반환한 뒤에만 연결이 실패한다면 IPv4만 사용하는 조회 정책으로 잠시 비교한 다음 로컬 IPv6 경로를 복구할지 결정할 수 있습니다. IPv6를 영구적으로 끄는 것을 기본 해결책으로 권하지 말고, 사이트 하나의 문제 때문에 시스템 전체 설정을 변경하지 마세요. 라우팅에서 도메인으로 매칭할 때와 조회된 IP 주소로 매칭할 때 결과가 다를 수 있으므로 최종 아웃바운드도 확인하세요.

캐시 삭제는 경로를 수정한 다음에 해야 합니다. 그렇지 않으면 잘못된 결과가 다시 캐시에 저장될 수 있습니다. Windows에서는 ipconfig /flushdns로 시스템 DNS 캐시를 비울 수 있지만 브라우저, 코어, 각 앱의 개별 캐시까지 삭제되지는 않습니다. 변경 후 관련 연결이나 앱을 다시 시작하고 같은 테스트를 반복하세요. TUN 가상 주소 매핑과 관련된 경우 이전 연결이 기존 매핑을 계속 사용할 수 있으므로 전환 전후 로그를 섞어 결론을 내리지 마세요. 먼저 연결을 중지하고 초기화된 테스트 환경에서 확인하세요.

시스템 프록시가 작동하지 않음: 앱 연결 방식 확인

시스템 프록시는 앱에 프록시 설정을 제공하는 기능이지 모든 네트워크 트래픽을 강제로 가져오는 기능은 아닙니다. 시스템 설정을 읽는 앱도 있고 자체 설정을 사용하는 앱도 있으며, 일부 터미널 프로그램은 환경 변수만 확인합니다. TUN은 가상 네트워크 어댑터와 라우팅을 통해 트래픽을 전달하므로 시스템 프록시와 같은 스위치가 아닙니다. 먼저 연결하려는 앱이 어떤 방식을 사용하는지 파악한 뒤 해당 설정을 선택하세요. 프로그램 하나가 시스템 프록시에 반응하지 않는다고 노드나 코어가 작동하지 않는 것은 아닙니다.

포트부터 확인한 뒤 시스템 설정 점검

먼저 TUN을 끄고 이 페이지 첫 번째 장의 프록시 지정 명령으로 로컬 진입점을 확인하세요. 이 요청도 실패한다면 시스템 설정을 계속 변경하지 말고 코어와 노드를 점검하세요. 프록시 지정 요청이 성공하면 v2rayN의 시스템 프록시 메뉴에서 시스템 프록시 자동 설정을 선택한 다음 운영체제의 네트워크 프록시 화면에서 주소와 포트가 클라이언트와 일치하는지 확인합니다. 일부 클라이언트는 하나의 진입점에서 HTTP와 SOCKS를 모두 지원하고, 다른 클라이언트는 포트를 나누어 사용합니다. SOCKS만 제공하는 포트를 HTTP 프록시만 받는 항목에 입력하지 마세요.

설정을 적용한 뒤 테스트 앱을 종료하고 다시 열어 프록시 설정을 새로 읽게 하세요. 브라우저 확장 프로그램, 앱 내부에 고정된 프록시, 조직의 관리 정책이 시스템 설정을 덮어쓸 수 있으므로 비교할 때는 먼저 해당 설정을 일시 중지합니다. 시스템 프록시 값이 이전 포트로 되돌아간다면 다른 네트워크 프로그램이 백그라운드에서 실행 중인지 확인하세요. 관리되는 기기라면 정책이 주기적으로 값을 복구할 수도 있습니다. 레지스트리를 반복해서 수정하거나 설정을 계속 강제로 바꾸지 마세요. 설정을 관리하는 실제 주체를 확인해야 클라이언트 종료 후 작동하지 않는 프록시가 남는 일을 막을 수 있습니다.

라우팅 문제와 앱 미연결 구분

로그에 대상 요청이 없다면 앱이 프록시에 연결되지 않은 것일 수 있습니다. 요청은 보이지만 직접 연결로 표시된다면 라우팅 규칙, 우회 목록, 기본 아웃바운드를 확인하세요. 시스템 프록시 예외 목록에서 로컬 주소나 일부 도메인을 우회하도록 설정했을 수도 있습니다. 이는 클라이언트 내부 라우팅과는 별도의 판단 단계입니다. 테스트할 때 해당 사용자 지정 예외를 잠시 제거할 수 있지만 시스템 기본 항목을 전부 삭제하지는 마세요. LAN 기기, 프린터, 내부 도메인은 예상 경로를 먼저 확인해 웹 연결을 고치는 과정에서 로컬 서비스가 끊기지 않도록 합니다.

터미널 도구가 시스템 프록시를 사용하지 않는다면 먼저 일회성 명령 옵션으로 확인한 뒤 프록시 환경 변수를 설정할지 결정하세요. 환경 변수는 현재 터미널과 이후 실행되는 하위 프로세스에만 영향을 줄 수 있으므로 이미 실행 중인 앱에는 적용되지 않을 수 있습니다. 도구에 따라 대소문자나 프로토콜별 변수를 구분하기도 합니다. 점검이 끝나면 임시 변수를 삭제해 클라이언트가 종료된 뒤에도 터미널이 연결되지 않는 로컬 포트를 가리키지 않도록 하세요. 계정 정보가 포함된 프록시 주소를 공개 스크립트나 명령 기록에 넣지 마세요.

TUN은 따로 켜고 따로 확인

프록시 설정을 읽지 않는 앱을 연결해야 하는 경우에만 TUN을 테스트하세요. 먼저 현재 라우팅을 저장하고 클라이언트 안내에 따라 필요한 권한을 허용한 뒤 가상 네트워크 어댑터가 생성됐는지 확인합니다. 권한 부족, 남은 가상 어댑터, 다른 터널 프로그램, 네트워크 필터링 소프트웨어가 연결을 방해할 수 있습니다. 클라이언트에서 노드로 나가는 연결은 올바르게 우회해야 합니다. 자동 라우팅이 잘못되면 트래픽이 다시 가상 인터페이스로 돌아가 루프가 발생할 수 있습니다. 범위가 넓은 고정 라우팅을 바로 추가하지 말고 클라이언트에서 지원하는 기본 정책으로 확인하세요.

TUN을 켠 뒤 로컬 네트워크까지 작동하지 않으면 즉시 TUN을 끄고 기본 라우트, DNS, LAN 우회 설정을 확인하세요. 네트워크 전환이나 절전 복귀 뒤에는 이전 어댑터 인덱스나 라우팅이 더 이상 유효하지 않을 수 있으므로 연결을 다시 만들어 확인할 수 있습니다. 트래픽 가로채기가 끝나기 전에 가상 네트워크 어댑터를 전부 수동 삭제하지 마세요. 먼저 클라이언트를 정상 종료한 뒤 남아 있는 항목을 확인합니다. 시스템 네트워크를 복구해야 한다면 기존 설정을 기록하고 이번에 변경한 내용만 되돌리세요. 복구 명령이 정상적으로 사용 중인 다른 네트워크 서비스에 영향을 주지 않도록 주의해야 합니다.

클라이언트 충돌: GUI와 코어 구분

화면이 열리지 않는 경우, 화면이 갑자기 종료되는 경우, 화면은 정상인데 코어가 중지되는 경우는 서로 다른 문제입니다. GUI 클라이언트는 설정을 관리하고 프로세스를 시작하며 코어는 연결을 처리합니다. 하나가 정상이라고 다른 쪽도 정상이라는 뜻은 아닙니다. 프로그램 시작, 노드 선택, 구독 업데이트, TUN 활성화 중 어느 시점에 문제가 발생하는지 관찰하고 매번 재현되는지도 기록하세요. 사용자 디렉터리 전체를 먼저 삭제하지 마세요. 로그, 구독, 설정이 들어 있을 수 있어 증거를 잃고 복구도 어려워집니다.

설치와 실행 환경부터 확인

다운로드 페이지에서 운영체제와 프로세서 아키텍처를 다시 확인하세요. macOS에서는 Apple Silicon과 Intel을 구분해야 합니다. Linux에서는 아키텍처와 패키지 형식을, Windows에서는 현재 시스템에 맞는 v2rayN 데스크톱 버전과 클래식 WPF 버전을 선택하세요. 한 플랫폼의 프로그램 폴더를 다른 플랫폼으로 복사해 사용하지 마세요. 압축 배포판은 쓰기 가능한 위치에 완전히 압축을 풀어 실행해야 합니다. 압축 파일 탐색 창에서 바로 실행하면 종속 파일이나 작업 디렉터리가 제대로 준비되지 않을 수 있습니다.

설치 프로그램과 포터블 배포판은 실행에 필요한 런타임이 다를 수 있으므로 설치 안내와 현재 패키지 설명을 따르세요. 출처를 알 수 없는 곳에서 개별 종속 파일을 내려받지 마세요. 시스템 보안 프로그램이 파일을 격리했다면 탐지 기록, 파일 출처, 조치 사유를 먼저 확인하세요. 모든 보안 기능을 끄는 것을 일반적인 해결책으로 삼지 마세요. 프로그램이 보호된 디렉터리, 읽기 전용 저장 장치 또는 동기화 도구가 관리하는 폴더에 있으면 설정을 기록하지 못할 수 있습니다. 기존 폴더는 그대로 두고 사용자 쓰기 권한이 있는 위치에 별도의 테스트 환경을 만들 수 있습니다.

코어 시작 실패: 첫 번째 관련 오류부터 확인

v2rayN 메인 창에서 코어 로그를 확인하고 시작 시점에 나타난 첫 오류를 찾으세요. 마지막의 '프로세스 종료' 메시지만 보지 마세요. 흔한 원인으로는 포트 충돌, 잘못된 설정 형식, 코어 파일 누락, 호환되지 않는 매개변수, 권한 부족이 있습니다. 접속 로그는 요청 내용을, 시작 로그는 프로세스가 작동 상태에 들어가지 못한 이유를 보여 줍니다. 더 자세한 오류 확인 방법은 코어 시작 실패 로그 진단을 참고하되, 실제 판단은 현재 로그에 표시된 필드를 기준으로 하세요.

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

위 명령은 Windows PowerShell에서 지정한 TCP 포트의 리스너 프로세스를 확인합니다. 포트는 실제 값으로 바꾸고, 환경에 따라 필요한 권한을 사용하세요. 프로세스 ID가 나오면 작업 관리자에서 어떤 프로그램인지 확인한 뒤 알 수 없는 시스템 프로세스를 종료하지 마세요. 다른 클라이언트 인스턴스라면 중복 실행된 인스턴스를 정상 종료합니다. 다른 서비스가 해당 포트를 사용해야 한다면 클라이언트 리스너 포트를 변경하고 시스템 프록시와 앱 설정도 함께 바꾸세요. 리스너만 변경하고 연결 진입점을 업데이트하지 않으면 새로운 연결 오류가 발생합니다.

설정 오류는 로그에 표시된 필드 경로를 기준으로 처리하세요. 사용자 지정 JSON의 쉼표, 따옴표, 필드 유형이 잘못됐거나 지원하지 않는 매개변수가 있으면 코어가 시작을 거부할 수 있습니다. GUI에서 생성한 설정은 해당 설정 화면으로 돌아가 수정하는 것이 좋습니다. 임시 설정 파일은 다음 시작 때 덮어써질 수 있으므로 장기 해결책으로 직접 수정하지 마세요. 필드 간 관계는 설정 파일 구조 해설에서 확인할 수 있지만 글의 일부를 현재 설정 전체에 덮어쓰지 마세요.

전체 상태를 덮어쓰지 말고 단계적으로 복구

화면이 계속 갑자기 종료되면 먼저 설정과 로그를 백업한 뒤 별도의 사용자 디렉터리나 클라이언트가 지원하는 새 설정 환경에서 실행하세요. 빈 환경에서 실행된다면 기존 설정, 창 상태, 가져온 항목이 원인일 가능성이 큽니다. 계속 실패한다면 설치, 종속성, 시스템 이벤트를 확인하세요. 복구할 때는 노드 하나를 먼저 추가해 연결을 확인한 다음 구독, 라우팅, 기타 설정을 하나씩 되돌리며 단계마다 테스트합니다. 백업을 한꺼번에 전부 복원하면 문제를 일으킨 설정까지 함께 복구할 수 있습니다.

프로그램을 업데이트하기 전에 GUI와 코어를 정상 종료하세요. 프로세스가 실행 중인 상태에서 파일을 덮어쓰지 마세요. 문제가 생겼을 때 이전 폴더를 복구용으로 보관할 수 있지만 빌드가 다르면 설정 호환성이 보장되지 않으므로 먼저 복사한 뒤 읽기를 시도하세요. 시작 오류 하나를 해결하려고 Xray와 V2Fly를 반복해서 바꾸지 마세요. 현재 코어가 노드에 필요한 기능과 호환되는지 먼저 확인하세요. 문제를 문의할 때는 운영체제, 아키텍처, 재현 단계, 민감 정보를 가린 오류를 첨부하고 노드 인증 정보, 구독 URL, 개인 디렉터리 이름은 숨기세요.

모바일 문제: 권한·백그라운드·네트워크 전환

Android에서는 v2rayNG를 우선 사용하세요. V2Fly 코어 호환 경로가 필요한 경우 v2flyNG를 대안으로 사용할 수 있습니다. 두 클라이언트의 화면과 사용 가능한 매개변수는 완전히 같지 않을 수 있으므로 실제 사용 중인 앱을 기준으로 확인하세요. 모바일 기기는 데스크톱보다 배터리 정책, 앱 적용 범위, 네트워크 전환의 영향을 더 많이 받습니다. 한 번도 연결되지 않는 문제, 화면이 켜져 있을 때는 정상이나 잠금 후 끊기는 문제, Wi-Fi에서는 되지만 모바일 데이터에서는 실패하는 문제를 구분해 해당 항목을 점검하세요. 모든 문제를 노드 불안정으로 단정하지 마세요.

연결 권한과 현재 활성 설정 확인

처음 연결을 시작하면 시스템에서 VPN 연결 권한을 요청하는 경우가 많습니다. 권한을 거부했거나 기기 정책에서 차단하면 화면에는 시작된 것처럼 보여도 트래픽은 실제로 전달되지 않을 수 있습니다. 다시 연결을 시작하고 시스템 안내를 읽어 현재 앱에 권한이 부여됐는지 확인하세요. 시스템 VPN 아이콘은 연결 서비스가 어떤 상태로 활성화됐는지만 보여 줄 뿐 원격 접속을 보장하지 않습니다. 활성 서버가 선택됐는지, 코어에서 시작 완료를 보고하는지 확인한 뒤 내장 연결 테스트나 브라우저의 고정 페이지로 검증하세요. 알림 문구만으로 판단하지 마세요.

Android의 VPN 서비스는 보통 같은 유형의 앱 여러 개가 동시에 각각 트래픽을 가져가도록 허용하지 않습니다. 다른 네트워크 필터링, 터널, 프록시 앱이 해당 기능을 사용 중이면 정상적으로 중지한 다음 현재 클라이언트를 시작하세요. 이전 앱에 항상 켜기 연결이나 VPN 미사용 트래픽 차단이 설정되어 있으면 전환 후 네트워크가 비정상적으로 동작할 수 있습니다. 시스템 VPN 설정에서 현재 연결된 앱을 확인하세요. 다른 앱의 데이터를 무작정 삭제하지 말고 테스트 후 원래 용도에 맞게 설정을 복구해 기기 네트워크 정책을 실수로 바꾸지 않도록 하세요.

일부 앱만 실패할 때 적용 범위 확인

클라이언트의 앱별 프록시 설정에서 선택한 앱만 프록시를 사용할지, 선택한 앱을 우회할지 확인하세요. 두 목록은 의미가 반대이므로 앱 아이콘을 선택했다고 해서 트래픽이 반드시 프록시로 전달되는 것은 아닙니다. 테스트 앱 하나를 정해 연결을 중지했다가 다시 시작하여 앱 적용 범위를 갱신하세요. 필요한 경우 테스트 앱도 완전히 종료한 뒤 다시 여세요. 해당 앱이 자체 DNS, 고정 주소, 자체 네트워크 구성 요소를 사용한다면 요청이 클라이언트에 들어왔는지 로그로 확인해야 합니다. 브라우저가 연결된다는 이유만으로 모든 앱이 프록시에 연결됐다고 판단하지 마세요.

잠금 후 연결이 끊기면 시스템 배터리 관리, 백그라운드 실행, 자동 시작 권한부터 확인하세요. 기기마다 메뉴 이름은 다르므로 현재 클라이언트가 백그라운드에서 연결을 유지할 수 있도록 설정하는 것이 중요합니다. 시스템 전체의 절전 기능을 끄지는 마세요. 클라이언트의 실행 알림을 유지하고 서비스가 시스템에 의해 종료되는지 살펴보세요. 알림이 사라지는 것, 프로세스가 다시 시작되는 것, 원격 연결 시간 초과는 서로 다른 증거입니다. 같은 네트워크와 노드를 사용해 화면을 켠 상태와 잠근 상태를 비교하고 몇 분 후 실패하는지 기록한 다음 배터리 최적화 예외를 조정하세요.

네트워크 전환과 모바일 데이터 별도 확인

Wi-Fi에서 모바일 데이터로 전환하면 기존 연결이 끊기거나 DNS와 진입점 주소가 달라질 수 있습니다. 먼저 연결을 중지하고 휴대전화 자체가 네트워크에 연결됐는지 확인한 뒤 다시 시작하세요. 공용 Wi-Fi에서 웹 로그인이 필요하다면 먼저 해당 네트워크 인증을 완료해야 합니다. 인증되지 않은 네트워크가 요청을 로그인 페이지로 리디렉션하면 구독 업데이트와 연결이 모두 실패할 수 있습니다. 모바일 데이터에서만 문제가 생긴다면 현재 SIM의 데이터 사용 권한과 제한, 클라이언트의 모바일 네트워크 사용 허용 여부를 확인하고 노드 프로토콜부터 바꾸지 마세요.

일부 모바일 네트워크는 IPv6를 주로 제공하거나 주소 변환을 사용합니다. 데스크톱의 IPv4 테스트 결과만으로 휴대전화의 연결 경로를 판단하지 마세요. 클라이언트 로그의 주소 계열과 DNS 오류를 기록하고 같은 노드를 Wi-Fi와 모바일 데이터에서 비교하세요. 시스템 비공개 DNS 설정도 진입점 조회에 영향을 줄 수 있습니다. 비교를 위해 잠시 시스템 자동 DNS로 바꿀 수 있지만 테스트가 끝나면 원래 설정을 복구하세요. 접속 지점, DNS, 노드 필드를 한꺼번에 변경하지 마세요. 원인을 확인할 수 없을 뿐 아니라 정상적인 데이터 연결을 망가뜨릴 수 있습니다.

설치에 실패하면 먼저 패키지 아키텍처와 시스템 안내를 확인하세요. 최신 기기는 보통 arm64를 선택할 수 있습니다. 확인하기 어렵다면 Android 다운로드 안내에서 알맞은 항목을 확인하세요. 범용 패키지는 용량이 더 클 수 있지만 연결 성능이 더 좋다는 뜻은 아닙니다. 업데이트 전 같은 클라이언트의 설정을 백업하고 v2rayNG와 v2flyNG의 전체 백업을 서로 덮어쓰지 마세요. 기기 간 설정을 옮길 때는 호환되는 구독 또는 노드 공유 방식을 우선 사용하고 자세한 제한 사항은 데스크톱과 Android 설정 이전을 참고하세요.

마지막으로 앱이 연결 범위에 들어왔는지, 코어가 요청을 받았는지, 노드가 연결됐는지, 대상이 응답했는지 단계별로 확인하세요. 데스크톱과 휴대전화가 같은 Wi-Fi와 노드를 사용해도 결과가 다르다면 권한, 앱 적용 범위, DNS를 집중적으로 비교합니다. 두 기기에서 모두 실패한다면 노드와 네트워크 경로를 다시 확인하세요. 도움을 요청할 때는 운영체제 버전, 클라이언트 이름, 네트워크 유형, 잠금 화면과의 연관성, 민감 정보를 가린 오류만 제공하면 됩니다. 여러 클라이언트를 계속 바꾸기보다 재현 가능한 최소 환경을 유지해야 실제 문제 단계를 찾기 쉽습니다.