V2Ray 문제
해결 가이드

인터넷 연결이 안 될 때: 먼저 문제 범위 확인

클라이언트가 실행 중이라고 표시되어도 앱이나 브라우저의 요청이 원격 서버에 도달했다는 뜻은 아닙니다. 먼저 TUN 모드를 잠시 끄고 시스템 프록시를 해제한 뒤 평소 직접 접속할 수 있는 사이트를 열어 보세요. 이 상태에서도 연결되지 않으면 Wi-Fi, 게이트웨이, 로그인 인증 또는 운영체제 네트워크 설정부터 확인하세요. 서버 설정은 그다음에 점검하면 됩니다. 클라이언트를 종료한 뒤에도 인터넷이 되지 않는다면 시스템에 로컬 주소를 가리키는 프록시 설정이 남아 있는지 확인하고, 원래 설정으로 되돌린 후 다시 테스트하세요.

재현 가능한 기준 테스트 만들기

현재 클라이언트, 선택한 서버, 라우팅 모드, 시스템 프록시 상태, 로컬 수신 포트를 기록하세요. 로그 창에서 기존 기록을 지운 다음 고정된 HTTPS 페이지를 열어 보세요. 브라우저 캐시가 결과를 왜곡할 수 있으므로 새 시크릿 창을 이용하되, 확장 프로그램이 별도로 프록시를 관리하지 않는지도 확인하세요. 한 번에 한 페이지만 테스트하고 시간을 기록하세요. 서버 변경, TUN 활성화, DNS 수정 등을 동시에 하면 연결이 복구되어도 어떤 변경이 효과가 있었는지 알 수 없습니다.

v2rayN에서는 먼저 서버 목록에서 사용할 항목이 선택되어 있는지, 코어 시작 직후 오류가 발생하지 않는지 확인하세요. 데스크톱 버전에서는 보통 하단 상태 표시줄이나 트레이 메뉴에서 시스템 프록시 모드를 확인할 수 있습니다. 로컬 포트와 앱에 입력한 포트가 정확히 일치하는지 비교하세요. 원격 서버 포트를 로컬 프록시 포트로 착각하면 안 됩니다. 혼합 수신을 사용하면 여러 프록시 프로토콜을 받을 수 있지만, 실제 지원 범위는 사용하는 코어와 설정에 따라 다릅니다. 포트 번호만으로 기능을 단정하지 마세요.

앱이 프록시에 연결되지 않은 경우와 원격 서버에 도달할 수 없는 경우 구분하기

이번 접속 기록이 로그에 전혀 없다면 브라우저가 시스템 프록시를 따르는지, 자체 프록시가 설정되어 있는지, 현재 라우팅 규칙이 대상 주소를 직접 연결로 보내는지 확인하세요. 요청 기록 직후 원격 연결 오류가 표시된다면 다음 장을 참고하세요. 로그에 직접 연결이 표시되어도 서버가 고장 났다는 뜻은 아닙니다. 로컬 네트워크나 사용자 지정 규칙을 우회하는 정상적인 결과일 수 있습니다. 테스트할 때는 프록시 경로를 거치는 것이 확실한 대상을 선택하고, 원래 우회 대상인 주소로 판단하지 마세요.

아래 명령으로 로컬 HTTP 프록시를 직접 지정하면 시스템 프록시 자동 검색을 거치지 않고 테스트할 수 있습니다. 예시의 10808은 해당 포트에서 실제로 수신하도록 설정된 경우에만 사용할 수 있습니다. 포트가 다르면 클라이언트 설정에 맞게 바꾸세요. Windows에서는 터미널에서 curl.exe를, macOS와 Linux에서는 curl을 사용하면 됩니다. 예시로 공개 사이트를 사용했으며, 실제 점검에서는 접근 권한이 있는 HTTPS 주소로 바꿔도 됩니다.

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

명령에서 로컬 포트에 연결할 수 없다고 나오면 수신 설정, 포트 충돌 또는 코어 시작 문제일 수 있습니다. 로컬 연결은 성공했지만 원격 연결이 시간 초과되면 서버 설정과 네트워크 경로를 확인하세요. HTTP 응답을 받았다는 것은 해당 요청이 프록시를 거쳐 응답을 받았다는 뜻일 뿐, 모든 앱과 대상이 정상이라는 의미는 아닙니다. 브라우저에서만 계속 실패하면 확장 프로그램, 별도 프록시, 브라우저 보안 DNS 및 인증서 경고를 차례로 확인하세요.

최소 설정으로 복구하기

매개변수가 모두 확인된 서버 하나만 사용하고 기본 라우팅 설정을 유지한 채, 추가 트래픽 처리 도구는 끄세요. 문제를 찾는 대신 설정 폴더 전체를 삭제하지 마세요. 구독 그룹, 라우팅 규칙, 개인 설정이 함께 사라질 수 있습니다. 먼저 백업한 뒤 항목별로 복원하면 충돌 원인을 찾기 쉽습니다. 인증서 경고가 표시되더라도 인증서 검증을 바로 끄지 마세요. 기기 시간, 대상 도메인, 인증서가 서로 맞는지 확인하고 네트워크에 승인이 필요한 검사 프록시가 있는지도 살펴보세요.

서버 연결 시간 초과: 포트와 핸드셰이크를 나눠서 확인

시간 초과는 하나의 원인으로 발생하지 않습니다. 서버 도메인 확인, 전송 연결, 암호화 핸드셰이크, 프록시 연결 이후 대상 사이트 요청 중 어느 단계에서도 발생할 수 있습니다. 테스트 결과와 로그를 펼쳐 어떤 주소에서 어느 단계에 시간 초과가 발생했는지 확인한 다음 서버를 바꿀지 판단하세요. 한 항목만 실패한다면 해당 항목의 설정부터 확인하세요. 같은 네트워크에서 모든 항목이 실패한다면 로컬 네트워크, 시스템 시간, 트래픽을 가로채는 다른 프록시 프로그램을 먼저 점검하세요.

TCPing만으로 연결 전체를 확인할 수 없습니다

TCPing은 주로 TCP 포트 연결 여부를 확인합니다. 연결에 성공해도 인증, TLS, 전송 경로 또는 대상 사이트 접속까지 성공한다는 보장은 없습니다. 다른 전송 방식을 사용하는 설정에는 TCP 결과를 그대로 적용할 수도 없습니다. v2rayN의 실제 연결 속도 테스트는 프록시를 통해 테스트 대상에 접속하므로 실제 요청에 더 가깝지만, 테스트 주소에 접속할 수 있어야 결과가 유효합니다. 테스트는 실패해도 평소 사용하는 대상에 접속할 수 있다면 테스트 주소와 시간 초과 설정부터 확인하세요. 결과 하나만 보고 서버를 삭제하지 마세요.

TCP 서비스를 점검하려면 Windows 터미널에서 아래 시스템 명령으로 포트를 확인할 수 있습니다. 도메인과 포트는 문법 예시일 뿐이므로 실행 전에 서버 설정에 있는 실제 값으로 바꾸세요. 이 결과는 포트 연결 여부만 보여 줍니다. 프로토콜 설정이 올바르다는 뜻은 아니며, 제3자 사이트의 포트 검사로 로컬 테스트를 대신할 수도 없습니다. 검사 사이트와 내 기기는 네트워크 경로가 다르기 때문입니다.

Test-NetConnection -ComputerName example.com -Port 443

연관된 연결 설정 함께 확인하기

서버 편집 창을 다시 열어 주소, 포트, 프로토콜, 인증 정보를 순서대로 확인하세요. 이어서 전송 유형과 해당 전송에 필요한 경로, 호스트 이름 또는 서비스 이름을 점검하세요. WebSocket 경로와 요청 호스트, gRPC 서비스 이름, TLS 서버 이름은 핸드셰이크에 영향을 줄 수 있으며 서로 바꿔 쓸 수 없습니다. 전체 공유 링크를 가져오는 편이 직접 입력하는 것보다 정확하지만, 메신저에서 링크가 잘리지 않았는지와 매개변수의 이스케이프 처리가 변형되지 않았는지는 확인해야 합니다.

TLS 오류가 발생하면 먼저 시스템 날짜와 시간대를 확인하고 서버 이름이 서버 설정과 일치하는지 확인하세요. REALITY를 사용하는 항목은 공개 키, 짧은 ID, 서버 이름, 클라이언트 지원 여부도 확인해야 합니다. 다른 서버의 설정을 섞어 넣지 마세요. 서비스 제공자가 매개변수를 변경했다면 해당 구독 그룹을 업데이트한 뒤 항목을 다시 선택하세요. 이전 편집 창에 남은 수동 복사본을 계속 사용하면 이미 만료된 연결 정보를 쓸 수 있습니다.

비교 테스트로 네트워크 범위 좁히기

기기와 설정은 그대로 두고 현재 Wi-Fi를 모바일 핫스팟으로 바꿔 보세요. 핫스팟에서는 연결된다면 기존 네트워크의 DNS, 외부 연결 경로 또는 접속 정책을 우선 확인하세요. 두 네트워크에서 모두 실패한다면 같은 네트워크에서 정상 작동이 확인된 다른 설정을 테스트하세요. 비교할 때는 변수를 하나씩만 바꾸세요. 기기, 서버, 코어를 동시에 바꾸면 안 됩니다. 서버에서 간헐적으로 시간 초과가 발생한다면 원격 서버의 연결 제한이나 서비스 중단 때문일 수 있습니다. 원격 서버가 수신을 중지한 문제는 클라이언트 설정으로 해결할 수 없습니다.

서버 목록 전체를 짧은 시간에 높은 동시성으로 테스트하지 마세요. 핸드셰이크를 한꺼번에 많이 시도하면 서버의 연결 제한에 걸릴 수 있고, 로컬 대역폭이 소모되어 정상 서버도 실패로 표시될 수 있습니다. 먼저 하나씩 테스트한 다음 소수 항목을 비교하세요. 첫 연결을 더 자세히 확인하려면 실제 연결 속도 측정 및 프록시 작동 확인을 참고하세요. 결과는 막연히 ‘서버가 고장 났다’고 기록하기보다 어느 단계에서 실패했는지 정리하세요.

구독 오류: 주소 가져오기와 데이터 파싱 구분하기

구독 업데이트는 두 단계로 진행됩니다. 클라이언트가 먼저 구독 주소에 요청을 보내고, 응답 내용을 서버 항목으로 파싱합니다. 요청 실패, 빈 응답, 호환되지 않는 형식은 모두 목록이 바뀌지 않는 결과로 나타날 수 있습니다. 업데이트 메시지와 로그를 확인해 유효한 응답을 받았는지 살펴보세요. 기존 서버를 계속 사용할 수 있다면 그룹부터 삭제하지 마세요. 기존 항목을 남겨 두면 일시적인 업데이트 실패로 쓸 수 있는 설정까지 잃는 일을 막을 수 있습니다.

가져오기 메뉴와 링크 유형 확인하기

v2rayN에서는 ‘구독 그룹’으로 구독 주소를 관리합니다. 보통 구독 그룹 설정에서 이름과 주소를 추가한 다음 구독 그룹 메뉴에서 업데이트합니다. v2rayNG에서는 사이드 메뉴의 ‘구독 설정’에 주소를 추가한 뒤 메인 화면으로 돌아와 구독을 업데이트합니다. 화면 버전에 따라 메뉴 위치와 문구가 조금씩 다를 수 있지만 주소 입력과 업데이트는 별개의 작업입니다. 주소를 저장했다고 다운로드까지 완료된 것은 아닙니다. 메뉴를 찾을 수 없다면 먼저 클라이언트 이름을 확인하세요.

구독 주소는 보통 HTTPS 링크이며, 개별 공유 링크에는 프로토콜 접두사가 포함되는 경우가 많습니다. 두 링크의 용도는 다릅니다. 개별 공유 링크를 구독 주소 입력란에 넣으면 클라이언트가 이를 웹 주소로 요청할 수 있어 업데이트되지 않습니다. 복사할 때 앞뒤 공백, 줄바꿈, 한글 문장 부호가 들어갔는지, 링크가 완전한지 확인하세요. QR 코드도 텍스트를 담는 방식일 뿐입니다. 스캔에 성공했다고 해서 해당 내용이 현재 가져오기 메뉴와 호환되는 것은 아닙니다.

요청 실패 시 접속 경로 확인하기

먼저 기기 시간이 정확한지, 일반 웹페이지에 접속할 수 있는지 확인한 다음 구독이 만료되었거나 서버에서 중지되지 않았는지 살펴보세요. 인증 실패 또는 접속 거부가 표시되면 링크 제공자에게 권한을 확인하세요. 로컬 포트를 계속 바꿔도 권한 문제는 해결되지 않습니다. 브라우저에서 구독 주소가 열린다고 해도 브라우저와 클라이언트의 접속 경로가 같다는 뜻은 아닙니다. 브라우저 확장 프로그램과 시스템 프록시 설정 차이로 두 결과가 달라질 수 있습니다.

v2rayN의 구독 업데이트 메뉴에서는 프록시를 사용하거나 사용하지 않고 업데이트하는 옵션을 제공할 수 있습니다. 실제 메뉴 이름은 현재 화면을 기준으로 확인하세요. 구독 서비스에 접속하려면 기존 프록시가 필요한 경우, 먼저 작동하는 서버를 선택하고 연결한 뒤 해당 업데이트 방식을 선택하세요. 사용할 수 있는 프록시가 없다면 끊어진 연결을 통해 업데이트하지 마세요. 직접 연결로 전환하거나 서비스 제공자가 허용하는 다른 네트워크를 이용하세요. 테스트를 위해 개인 구독 주소를 모르는 변환 서비스에 입력하지 마세요.

요청 성공 후에도 서버가 보이지 않을 때

요청은 성공했지만 목록이 비어 있다면 서버가 로그인 페이지, 오류 안내 페이지 또는 리디렉션 페이지를 반환했는지 먼저 확인하세요. HTTP 요청이 성공했다고 해서 응답이 구독 데이터라는 뜻은 아닙니다. 응답에는 여러 공유 링크, 인코딩된 링크 모음, 특정 클라이언트 전용 구조화 설정 등이 포함될 수 있으며 모든 형식이 서로 호환되는 것은 아닙니다. 파일 확장자만 보고 호환성을 추측하지 말고 서버에서 대상 클라이언트용 구독 형식을 명확하게 선택하세요.

다음으로 그룹 필터와 검색창을 확인하세요. 서버를 가져왔지만 다른 구독 그룹에 숨겨져 있거나 현재 검색어에 걸려 표시되지 않을 수 있습니다. 업데이트 후 검색어를 지우고 해당 그룹을 선택한 다음 항목 수와 오류 메시지가 바뀌었는지 확인하세요. 일부 항목만 가져오지 못했다면 해당 항목의 프로토콜, 전송 방식, 코어 지원 여부를 살펴보세요. 다른 항목이 성공했다고 해서 형식이나 매개변수 문제를 배제할 수는 없습니다. 하나의 항목을 먼저 수정한 뒤 일괄 업데이트하세요.

구독을 업데이트하면 그룹 안에서 직접 수정한 내용이 덮어써질 수 있습니다. 개인 설정을 계속 유지해야 한다면 먼저 변경 내용을 기록하고 클라이언트의 업데이트 동작을 확인한 뒤 별도 항목으로 보관할지 결정하세요. 기기를 옮길 때는 구독 주소, 서버 목록, 클라이언트 전체 백업을 구분해야 합니다. 각각 포함하는 정보가 다릅니다. 자세한 주소 및 형식 안내는 V2Ray 구독 링크 가져오기 및 형식 안내를 참고하세요. 처음 가져오는 경우 입문 가이드의 순서에 따라 진행하면 됩니다.

속도 저하: 처리량·지연 시간·부하 구분하기

웹페이지가 느리게 열리는 현상, 다운로드 속도 저하, 동영상 버퍼링은 서로 다른 원인일 수 있습니다. 웹페이지 첫 로딩은 DNS 확인과 핸드셰이크의 영향을 받기 쉽고, 대용량 파일 전송은 지속 처리량에 더 크게 좌우됩니다. 반응 속도가 중요한 앱은 왕복 지연 시간과 패킷 손실에 민감합니다. 먼저 어떤 앱에서 어떤 대상에 언제 문제가 생기는지 기록한 뒤 알맞은 방식으로 테스트하세요. 한 페이지의 로딩 시간과 다른 회선의 대용량 다운로드 속도를 직접 비교하지 말고, 연결 속도 테스트 결과를 대역폭 한계로 간주하지 마세요.

로컬 네트워크와 동시 사용 부하부터 확인하기

시스템 업데이트, 클라우드 동기화, 기타 대용량 작업을 일시 중지해 백그라운드 다운로드가 외부 연결 대역폭을 모두 사용하지 않는지 확인하세요. Wi-Fi 신호가 약하다면 공유기 가까이 이동하거나 유선 연결로 비교해 보세요. 클라이언트 설정은 그대로 두고 일반 직접 연결 대상도 느린지 테스트하세요. 모든 접속이 느리다면 로컬 네트워크부터 확인해야 합니다. 기기 충전 중 온도 제한, 높은 CPU 사용률, 전원 관리 제한으로 지속 전송 속도가 낮아질 수도 있습니다. 특히 모바일 기기를 오래 사용한 뒤 이런 현상이 나타날 수 있습니다.

측정할 때는 한 번에 하나의 작업만 실행하고, 같은 대상과 파일을 비슷한 시간 동안 테스트하세요. 서버 속도 테스트는 대개 작은 요청을 사용하므로 응답 특성 일부만 보여 줍니다. 서버 목록을 한꺼번에 테스트하면 트래픽이 소모되고 테스트 작업 자체가 대역폭을 차지할 수 있습니다. 후보를 소수만 테스트한 뒤 실제 사용하는 작업으로 확인하세요. 앱에 표시되는 속도가 초당 바이트인지 초당 비트인지 확인해야 합니다. 단위가 다르면 직접 비교할 수 없고, 짧은 순간의 최고 속도가 안정적인 속도를 뜻하지도 않습니다.

서버 부하와 대상 사이트의 제한 구분하기

네트워크와 대상 사이트를 고정하고 서버만 바꿔 보세요. 한 서버만 뚜렷하게 느리고 여러 대상에서 문제가 발생한다면 서버 부하, 대역폭 또는 상위 네트워크 회선이 원인일 수 있습니다. 모든 서버에서 특정 대상만 느리다면 해당 서비스의 속도 제한, 캐시, 연결 정책을 확인하세요. 원격 서버의 리소스 부족은 로컬 스레드 수를 높여도 해결되지 않습니다. 혼잡 여부를 비교할 때는 같은 조건으로 사용량이 많은 시간과 적은 시간을 기록하세요. 서로 다른 네트워크의 결과를 비교해 혼잡을 단정하지 마세요.

실제 연결 속도 테스트는 빠른데 다운로드가 느려도 모순은 아닙니다. 짧은 요청은 빠르게 완료되지만 지속적인 전송은 혼잡이나 속도 제한의 영향을 받을 수 있습니다. 반대로 핸드셰이크가 다소 느려도 지속 처리량은 높을 수 있습니다. 중요한 것은 목록의 숫자를 낮추는 게 아니라 실제 작업이 개선되는지 확인하는 것입니다. 자세한 단계별 점검 방법은 서버·회선·로컬 설정별 속도 저하 점검을 참고하세요. 먼저 비교 결과를 기록한 뒤 회선을 바꿀지 결정하세요.

전송 방식·Mux·라우팅 변경은 신중하게

Mux는 여러 논리 요청을 더 적은 수의 하위 연결로 전송해 연결을 반복해서 만드는 비용을 줄일 수 있습니다. 하지만 일부 네트워크와 서비스 조합에서는 여러 요청이 같은 연결의 혼잡 영향을 함께 받게 될 수도 있습니다. 동시 요청을 늘린다고 항상 빨라지는 것은 아니며, 모든 프로토콜에 같은 다중화를 적용할 수 있는 것도 아닙니다. 최근 Mux만 변경했다면 기존 값으로 되돌려 비교하세요. 서버가 전송 매개변수를 지정한 경우 속도를 높이려고 WebSocket을 임의의 다른 전송 방식으로 바꾸면 안 됩니다.

라우팅 때문에 일부 콘텐츠만 느려질 수도 있습니다. 페이지 본문, 이미지, 로그인 API가 서로 다른 도메인을 사용하면 각기 다른 송신 규칙이 적용되어 페이지 틀은 열렸지만 리소스가 나타나지 않을 수 있습니다. 느린 요청의 로그와 규칙을 확인해 예상한 경로를 따르는지 살펴보세요. DNS 캐시와 연결 재사용은 재테스트 결과에 영향을 줍니다. 규칙을 바꾼 뒤에는 영향을 받는 연결을 다시 시작하고, 필요한 경우 앱을 완전히 종료했다가 실행하세요. 기존 연결이 계속 작동한다고 해서 새 규칙이 적용되지 않았다고 잘못 판단하지 마세요.

속도가 회복되면 실제로 효과가 있었던 변경을 기록하고 관련 없는 테스트는 되돌리세요. 불필요한 ‘최적화 설정’을 여러 개 쌓기보다 꼭 필요한 설정만 남기는 편이 안정적입니다. 로컬 문제를 제외한 뒤에도 장기간 속도가 느리다면 단순히 ‘인터넷이 느리다’고 문의하기보다 시간대, 대상 유형, 비교 조건을 서비스 제공자에게 전달하면 원인을 찾기 쉽습니다.

DNS 오류: 도메인 확인 위치 점검하기

DNS는 도메인을 IP 주소로 변환하지만 프록시 환경에서는 확인이 여러 곳에서 이뤄질 수 있습니다. 운영체제가 도메인을 확인할 수도 있고, 브라우저가 별도의 보안 DNS를 사용할 수도 있으며, 클라이언트 코어가 설정에 따라 직접 확인할 수도 있습니다. SOCKS를 사용하면 앱이 도메인 확인을 프록시 쪽에 맡길 수도 있습니다. 먼저 서버 도메인과 대상 도메인 중 무엇이 실패했는지, 요청이 어떤 경로를 따르는지 확인하세요. 모든 DNS 확인 설정을 한꺼번에 바꾸면 단서가 사라지고 새로운 순환 의존성이 생길 수 있습니다.

시스템 DNS와 클라이언트 로그부터 확인하기

로그에 서버 도메인을 확인할 수 없다고 표시된다면 연결이 아직 원격 서버에 도달하지 않았을 수 있습니다. 이때 대상 사이트의 라우팅을 바꿔도 대개 도움이 되지 않습니다. 먼저 운영체제 터미널에서 해당 도메인을 확인할 수 있는지 테스트하세요. Windows에서는 nslookup을 사용할 수 있으며 macOS와 Linux에서는 시스템에 설치된 DNS 확인 도구를 이용할 수 있습니다. 아래는 명령 형식만 보여 주는 예시입니다. 시스템에서는 정상적으로 확인되는데 클라이언트에서만 실패한다면 코어의 DNS 설정과 실제 사용하는 상위 DNS 서버를 확인하세요. 두 설정이 반드시 같은 캐시를 공유하는 것은 아닙니다.

nslookup example.com

여러 주소가 반환되는 것은 흔한 일이며, 다른 기기에서 확인한 주소와 다르다고 해서 오류는 아닙니다. 콘텐츠 전송 서비스는 네트워크 위치와 정책에 따라 서로 다른 결과를 반환합니다. 도메인 확인에 성공했다는 것은 주소를 받았다는 뜻일 뿐, 해당 주소에 접속할 수 있다는 보장은 없습니다. 확인 시간 초과가 발생하면 상위 DNS 응답 없음, 요청 경로 오류, 로컬 네트워크 제한을 구분해야 합니다. 네트워크를 바꾼 뒤에만 문제가 발생한다면 먼저 클라이언트 연결을 다시 설정하고 이전 네트워크 인터페이스의 DNS 설정이 남아 있는지 확인하세요.

SOCKS 요청으로 로컬 DNS와 원격 DNS 비교하기

SOCKS 수신이 실제로 활성화된 상태에서 아래 두 명령을 비교해 보세요. 첫 번째 명령은 보통 로컬에서 대상 도메인을 확인하고, 두 번째 명령은 도메인 확인을 프록시 쪽에 맡깁니다. 포트는 로컬 설정에 맞게 바꾸세요. 원격 DNS 방식에서만 성공한다면 로컬에서 대상 도메인을 확인하는 과정에 문제가 있을 수 있습니다. 다만 로그를 함께 확인해 주소 선택 차이가 원인이 아닌지 살펴보세요. 이 테스트만으로 모든 DNS 트래픽이 같은 경로를 따른다고 판단할 수는 없습니다.

curl --socks5 127.0.0.1:10808 --connect-timeout 10 -I https://example.com/
curl --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 -I https://example.com/

브라우저의 보안 DNS는 시스템 DNS를 우회할 수 있습니다. 따라서 터미널에서는 정상인데 브라우저에서만 문제가 생기면 브라우저 자체 설정을 확인하세요. 테스트할 때는 잠시 시스템 DNS를 사용하도록 바꾸어 비교한 다음 최종 설정을 결정하세요. 브라우저 캐시만 지워도 시스템과 코어의 캐시까지 지워지는 것은 아니며 그 반대도 마찬가지입니다. 먼저 기존 연결을 종료한 다음 문제가 발생한 단계에 맞게 캐시를 정리하세요. 캐시 문제를 라우팅 규칙 미적용으로 오인하지 않도록 주의하세요.

DNS 부트스트랩 순환과 규칙 오류 방지하기

암호화 DNS 서버를 도메인 이름으로 설정한 경우, 해당 서버와 연결하려면 먼저 그 도메인을 확인해야 할 수 있습니다. 확인 과정이 아직 연결되지 않은 프록시에 의존하면 순환이 발생할 수 있습니다. 같은 연결할 수 없는 상위 DNS 서버를 계속 추가하지 말고 코어가 지원하는 방식으로 부트스트랩 DNS를 설정하거나 상위 DNS 서버로 가는 경로를 명확히 지정하세요. 사내 도메인은 로컬 네트워크 DNS에서만 확인할 수 있는 경우도 있습니다. 이런 도메인을 모두 공용 DNS에 맡기면 사내 서비스에 접속하지 못할 수 있습니다.

도메인 규칙과 IP 규칙은 적용되는 시점이 다를 수 있습니다. 아래는 Xray 기본 라우팅에서 로컬 네트워크 주소를 직접 연결하는 규칙 예시로, 필드 간 관계를 설명하기 위한 것입니다. 완전한 설정 파일이 아니므로 클라이언트의 임의 편집란에 그대로 붙여 넣지 마세요. direct는 실제로 존재하는 송신 태그여야 하며, 규칙은 보통 순서대로 적용됩니다. 지리 정보 파일도 정상적으로 사용할 수 있어야 합니다. 그래픽 라우팅 편집기를 쓴다면 해당 필드에 같은 의미를 설정하세요.

{
  "type": "field",
  "ip": ["geoip:private"],
  "outboundTag": "direct"
}

IPv6 전용 또는 듀얼 스택 네트워크에서만 문제가 발생한다면 반환된 주소 유형과 원격 접속 가능 여부도 비교하세요. IPv6를 영구적으로 끄기 전에 주소 선택, 라우팅, 상위 네트워크 지원 중 무엇이 원인인지 확인해야 합니다. TUN의 가상 주소 매핑을 사용했다면 트래픽 처리를 종료한 뒤 앱 연결을 다시 만들어야 할 수 있습니다. 일반 도메인, 사내 도메인, 실제 업무 대상에 모두 접속해 한 테스트 사이트만 고친 뒤 다른 접속을 망가뜨리지 않았는지 확인하세요.

시스템 프록시 미작동: 트래픽이 들어오는 경로 확인

시스템 프록시는 앱이 읽을 수 있는 네트워크 설정 모음이지 모든 트래픽을 강제로 가로채는 스위치가 아닙니다. 시스템 프록시를 따르는 앱도 있고, 자체 설정을 사용하는 앱도 있으며, 아예 해당 설정을 읽지 않는 앱도 있습니다. 따라서 브라우저는 되는데 다른 앱에서 실패한다고 해서 v2rayN이 시작되지 않았다고 단정할 수 없습니다. 먼저 로컬 프록시를 명시한 요청으로 수신 여부를 확인하세요. 다음으로 대상 앱이 프록시 설정을 가져오는 방식을 살펴본 뒤, 필요한 경우에만 TUN을 고려하세요.

시스템 설정이 실제로 적용됐는지 확인하기

v2rayN의 시스템 프록시 메뉴에서 시스템 프록시 자동 설정을 선택한 다음 운영체제 네트워크 설정에 표시된 주소와 포트가 일치하는지 확인하세요. Windows에서는 현재 사용자 프록시, 자동 구성 스크립트, 일부 시스템 구성 요소의 설정이 서로 완전히 같지 않을 수 있습니다. macOS 프록시는 네트워크 서비스별로 적용되므로 Wi-Fi와 유선 연결을 전환한 뒤 현재 서비스를 확인하세요. Linux에서는 데스크톱 환경과 터미널 앱이 서로 다른 프록시 설정을 사용할 수도 있습니다. 클라이언트 메뉴의 체크 표시만으로 적용 여부를 판단하지 마세요.

설정이 적용되자마자 원래대로 돌아간다면 다른 프록시 프로그램, 브라우저 확장 프로그램, 기기 관리 정책 또는 네트워크 보안 도구를 확인하세요. 점검 중에는 시스템 프록시를 수정하는 프로그램을 하나만 사용해 여러 도구가 설정을 덮어쓰지 않도록 하세요. 스위치를 반복해서 누르는 것으로 충돌을 해결하려 하지 마세요. 클라이언트를 종료하기 전에 시스템 프록시를 해제하고 인터넷이 복구됐는지 확인하세요. 비정상 종료 후 설정이 남았다면 이미 중지된 로컬 수신에 의존하지 말고 운영체제에서 직접 원래 설정으로 되돌리세요.

앱 설정과 터미널 환경을 따로 확인하기

자체 프록시를 지원하는 앱에서는 로컬 루프백 주소와 실제 수신 포트를 입력하고 프로토콜도 맞게 선택하세요. HTTP와 SOCKS는 임의로 바꿔 쓸 수 있는 이름이 아닙니다. 같은 포트 번호로 두 프로토콜을 모두 받을 수 있는지는 수신 설정에 따라 다릅니다. 터미널 도구는 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 또는 제외 변수를 읽을 수도 있습니다. 이전 값이 남아 있으면 요청이 이미 중지된 포트로 전송될 수 있습니다. 변수 값에 개인 정보가 포함되어 있는지도 확인하세요.

앱에 직접 연결 제외 목록이 설정되어 있으면 로컬 네트워크나 특정 도메인에 접속할 때 프록시를 거치지 않을 수 있습니다. 이는 앱의 동작이며 클라이언트에서 선택한 서버와는 별개입니다. 같은 대상으로 프록시를 명시한 요청과 앱의 요청을 각각 보내고 로그에 연결 기록이 나타나는지 비교하세요. 앱 요청이 전혀 기록되지 않으면 유입 경로를 확인하고, 기록은 있지만 직접 연결로 처리되면 라우팅을 확인하세요. 요청이 프록시로 들어온 뒤 실패하면 원격 연결을 점검하면 됩니다. 이렇게 세 가지 문제를 구분할 수 있습니다.

TUN 모드에서는 먼저 트래픽 처리 여부를, 그다음 분할 라우팅을 확인하기

TUN은 가상 네트워크 인터페이스로 트래픽을 받습니다. 더 넓은 범위의 트래픽 처리가 필요할 때 유용하지만 권한, 시스템 라우팅, DNS 같은 변수가 추가됩니다. 먼저 다른 VPN이나 겹치는 가상 네트워크 도구를 끈 다음 클라이언트 안내에 따라 필요한 권한을 부여하세요. Windows에서는 관리자 권한이 필요할 수 있으며 다른 데스크톱 운영체제에서는 화면 안내에 따라 권한을 허용해야 합니다. 모든 오류를 해결하는 방법이라며 클라이언트를 항상 높은 권한으로 실행하지 마세요.

TUN을 켠 뒤 직접 연결 사이트에도 접속할 수 없다면 먼저 TUN을 끄고 일반 로컬 프록시가 작동하는지 확인하세요. 그다음 가상 인터페이스가 생성되었는지, 기본 라우팅에 문제가 없는지, DNS가 가로채졌는지 확인합니다. 트래픽을 받을 수 있다고 해서 규칙까지 올바른 것은 아닙니다. 로컬 프린터나 사내 네트워크에 접속할 수 없다면 사설 주소와 사내 도메인의 우회 규칙을 점검하세요. 시스템 라우팅을 함부로 삭제하거나 다른 사람의 네트워크 설정 전체를 그대로 복사하지 마세요. 네트워크 인터페이스 이름과 주소 범위는 환경마다 다릅니다.

점검을 마친 뒤에는 어떤 연결 방식을 사용할지 명확히 정하고 이해할 수 있는 상태로 설정을 복구하세요. 일부 설정에서는 시스템 프록시와 TUN을 함께 사용할 수 있지만, 문제를 찾는 동안에는 각각 따로 테스트하는 편이 좋습니다. ‘시스템 프록시’, ‘라우팅’, ‘코어’의 뜻은 용어집에서 확인할 수 있습니다. 처음 연결할 때는 입문 가이드에 따라 시스템 프록시 경로를 먼저 확인한 뒤 TUN을 설정하세요.

시작 오류 및 충돌: 앱 화면과 코어 구분하기

시작 실패에는 최소 세 가지 유형이 있습니다. 메인 화면이 전혀 열리지 않는 경우, 화면은 정상적으로 열리지만 코어가 바로 종료되는 경우, 사용 중 클라이언트 전체가 종료되는 경우입니다. 먼저 어떤 유형인지 확인한 뒤 관련 증거를 찾으세요. 화면이 열려도 코어 파일을 실행할 수 없는 경우가 있으며 코어가 종료되어도 화면은 계속 열려 있을 수 있습니다. 가능하면 앱 로그, 시스템 이벤트 기록, 시작할 때 표시된 전체 오류 메시지를 확인하세요. ‘실행 안 됨’이라는 설명과 화면 캡처만 남기거나 기존 상태를 덮어쓰며 반복해서 재설치하지 마세요.

설치 파일과 실행 환경이 맞는지 확인하기

데스크톱에서는 v2rayN을 사용하고 다운로드 페이지에서 운영체제와 프로세서 아키텍처에 맞는 파일을 선택하세요. Windows의 Desktop과 WPF는 서로 다른 UI 버전이며 필요한 구성 요소와 오류 양상이 다를 수 있습니다. 두 버전의 파일을 같은 폴더에 섞지 마세요. macOS에서는 Apple Silicon과 Intel을 구분하고, Linux에서는 프로세서 아키텍처와 패키지 형식을 함께 확인하세요. 설치 프로그램과 압축 파일은 사용 방법이 다릅니다. 압축 파일을 열어 보는 창 안에서 프로그램을 바로 실행하지 마세요.

처음 실행할 때 필요한 실행 환경을 안내하면 현재 설치 파일의 설명에 따라 필요한 구성 요소를 설치하세요. 기억에 의존해 비슷해 보이는 런타임을 설치하지 마세요. 운영체제 버전이 현재 프로그램의 요구 사항을 충족하지 않으면 구성 요소를 추가 설치해도 해결되지 않을 수 있습니다. Windows 폴더 권한, macOS 보안 경고, Linux 그래픽 세션 및 라이브러리 의존성이 메인 화면 실행에 영향을 줄 수 있습니다. 안내 메시지에 적힌 구체적인 원인을 확인하고 시스템 보호를 전부 끄거나 모든 파일에 쓰기 권한을 부여하지 마세요.

메인 화면은 열리지만 코어가 종료되는 경우

코어 로그에서 가장 먼저 발생한 오류를 확인하세요. 이후에 나타나는 수많은 연결 실패는 첫 오류의 연쇄 결과일 수 있습니다. 설정 문법 오류, 지원되지 않는 필드, 누락된 데이터 파일, 로컬 포트 충돌, 실행 권한 부족은 각각 해결 방법이 다릅니다. 최근 코어를 바꿨다면 현재 설정의 프로토콜과 전송 방식이 지원되는지 확인하세요. v2rayN에서 여러 코어를 관리할 수 있지만 한 코어가 지원하는 필드를 다른 코어도 지원한다고 볼 수 없습니다. 코어 이름만 바꾸고 설정 호환성을 확인하지 않으면 안 됩니다.

로컬 포트가 충돌하면 다른 클라이언트나 이전 코어가 실행 중인지 먼저 확인하세요. 시스템 프로세스 목록과 포트 사용 정보를 살펴본 다음 중복 실행된 항목은 정상 종료하세요. 프로세스 이름만 보고 강제 종료하지 마세요. 다른 앱이 해당 프로세스를 사용 중일 수 있습니다. 포트를 변경하면 충돌을 피할 수 있지만 시스템 프록시, 브라우저, 앱 자체 설정의 주소도 함께 바꿔야 합니다. 그렇지 않으면 코어는 정상화됐는데 앱이 이전 포트에 연결하는 문제가 생길 수 있습니다.

백업한 최소 설정으로 손상 여부 구분하기

설정 가져오기, 구독 업데이트, 라우팅 수정 직후 충돌이 발생했다면 현재 데이터를 백업한 다음 별도의 테스트 설정으로 확인하세요. 설치 방식이 지원한다면 프로그램 안내에 따라 새 사용자 설정 경로를 지정하세요. 백업 없이 기존 폴더를 바로 삭제하지 마세요. 테스트에는 정상적으로 작동하는 서버 항목 하나와 기본 설정만 남기세요. 새 설정에서 문제가 없다면 구독, 라우팅, 화면 설정을 하나씩 복원해 특정 데이터가 손상됐는지 전체 실행 환경에 문제가 있는지 확인할 수 있습니다.

업데이트 중 보안 프로그램이 파일을 격리했다면 격리 기록을 확인하고 다운로드 출처와 설치 파일 내용을 점검하세요. 다운로드 폴더 전체를 광범위한 예외로 등록하지 마세요. 디스크 공간 부족, 읽기 전용 설정 폴더, 동기화 프로그램의 파일 잠금도 설정 저장 실패나 이전 값 복원의 원인이 될 수 있습니다. 클라이언트 요구 사항에 맞고 현재 사용자가 접근할 수 있는 로컬 경로로 데이터를 옮긴 다음 파일을 쓸 수 있는지 테스트하세요. 이동하기 전에는 클라이언트를 완전히 종료해야 여러 인스턴스가 동시에 데이터를 수정하는 일을 막을 수 있습니다.

간헐적으로 충돌한다면 절전 모드에서 복귀한 뒤인지, 네트워크를 전환한 뒤인지, TUN을 켠 뒤인지도 기록하세요. 시스템이 리소스 부족으로 프로세스를 종료했는지도 확인해야 합니다. 재현하는 동안에만 로그 수준을 높이고 원인을 찾은 뒤에는 원래 설정으로 되돌려 불필요한 기록이 계속 쌓이지 않도록 하세요. 첫 실행 준비 방법은 Windows 및 macOS 초기 설정 안내를 참고하세요. 재설치는 일부 파일 문제만 해결하며 기존 설정이나 권한 충돌까지 자동으로 해결하지 않습니다.

Android 문제 해결: 권한·백그라운드·앱별 프록시

Android에서는 v2rayNG를 우선 사용하고 V2Fly 코어를 사용하는 대안으로 v2flyNG를 선택할 수 있습니다. Android 앱은 데스크톱 시스템 프록시와 연결 방식이 다릅니다. 일반적인 VPN 모드에서는 시스템 VpnService를 사용해 로컬 트래픽 경로를 만듭니다. 상태 표시줄에 VPN 표시가 나타나는 것은 시스템 연결이 존재한다는 뜻일 뿐, 원격 서버와 핸드셰이크가 완료됐다는 의미는 아닙니다. 서버를 선택하고 연결 로그를 확인한 다음 실제 앱 요청으로 테스트하세요. 알림 아이콘만 보고 연결 성공을 판단하지 마세요.

연결 권한과 VPN 간 충돌 확인하기

VPN 모드를 처음 실행하면 운영체제에서 연결 권한을 요청합니다. 요청을 확인한 뒤 허용하세요. 권한 확인 창이 나타나지 않거나 버튼을 누를 수 없다면 화면 오버레이, 화면 필터 또는 시스템 제한이 작동을 방해하는지 확인하세요. 업무용 프로필, 관리 대상 기기, 자녀 보호 기능이 VPN 권한을 제한할 수도 있습니다. 기기 관리 정책을 따르세요. 클라이언트 설정을 바꿔 제한을 우회하면 안 됩니다. 권한이 취소됐다면 구독만 업데이트할 것이 아니라 다시 연결해 시스템의 권한 확인을 완료해야 합니다.

일반적으로 같은 사용자 환경에서는 이러한 VPN 서비스를 여러 개 동시에 사용할 수 없습니다. 다른 VPN, VPN 인터페이스를 사용하는 방화벽, 네트워크 필터링 도구가 실행되면서 현재 연결을 대체할 수 있습니다. 점검할 때는 다른 연결을 사용하는 앱을 정상 종료한 뒤 클라이언트에 연결하세요. 시스템에서 항상 켜져 있는 VPN 또는 ‘VPN 없이 연결 차단’이 활성화되어 있다면 어느 앱에 연결되어 있는지 확인하세요. 기존 앱을 삭제하거나 비활성화한 뒤에도 이 정책 때문에 기기에서 계속 인터넷에 접속하지 못할 수 있습니다.

화면 잠금 후 연결이 끊기면 전원 관리부터 확인

화면이 켜져 있을 때는 정상인데 잠근 뒤 연결이 끊기면 서버보다 백그라운드 관리 설정을 먼저 의심해야 합니다. 클라이언트의 배터리 사용 설정을 확인하고 필요한 백그라운드 실행을 허용한 다음 운영체제의 과도한 절전 제한을 해제하세요. 일부 기기에서는 자동 시작을 허용하거나 최근 앱 목록에서 앱을 유지해야 할 수도 있지만 메뉴 위치는 운영체제마다 다릅니다. 특정 스위치 하나가 모든 기기의 문제를 해결한다고 단정하지 마세요. 잠금 상태로 일정 시간 둔 뒤 로그와 알림이 유지되는지 확인하세요.

서비스는 실행 중인데 화면을 켠 직후 첫 요청이 시간 초과된다면 Wi-Fi와 모바일 네트워크 전환으로 기존 연결이 끊겼을 수 있습니다. 연결을 중지했다가 다시 설정해 바로 복구되는지 비교하고, 대기 중에 운영체제가 Wi-Fi를 끄는지도 확인하세요. 데이터 절약, 백그라운드 모바일 데이터 제한, 저전력 모드도 각각 점검해야 합니다. 한 번에 하나씩만 변경하고 모든 절전 기능을 동시에 끄지 마세요. 점검 목적은 필요한 실행 조건을 확보하는 것이지 기기를 계속 고전력 상태로 두는 것이 아닙니다.

앱별 프록시 선택 방식 확인하기

v2rayNG 설정에서 앱별 프록시를 활성화했다면 목록이 ‘선택한 앱만 프록시 사용’을 뜻하는지, 아니면 선택한 앱을 우회한다는 뜻인지 먼저 확인하세요. 체크 표시만 보면 의미를 반대로 이해하기 쉽습니다. 목록을 변경한 뒤 새 세션에 설정을 적용하려면 VPN 연결을 다시 설정해야 할 수 있습니다. 시스템 구성 요소, 다운로드 서비스, 앱 내부 웹페이지의 요청이 화면에 보이는 앱과 다른 출처에서 발생할 수도 있습니다. 실제로 테스트하고 시스템 항목을 무작정 많이 선택하지 마세요.

브라우저는 되는데 메신저나 미디어 앱에서 실패한다면 먼저 앱별 제한을 끈 상태에서 비교한 뒤 해당 앱이 제외 목록에 있는지 확인하세요. 앱마다 다른 전송 방식이나 장시간 연결을 사용할 수 있으므로 브라우저 결과만으로 모든 프로토콜이 정상이라고 판단할 수 없습니다. 업무용 프로필에서 앱을 사용하는 경우 사용자 공간 경계도 확인하세요. 개인 프로필의 클라이언트가 다른 프로필의 요청을 처리하지 못할 수 있습니다. 운영체제가 지원하는 방식으로 설정하고 권한 경계 문제를 서버 문제로 오인하지 마세요.

설치·업데이트·기기 이전

설치에 실패하면 먼저 아키텍처, 저장 공간, 시스템 안내를 확인하세요. 일반적인 최신 기기에서 해당 아키텍처를 지원한다면 arm64를 선택할 수 있습니다. 확실하지 않다면 다운로드 페이지의 안내에 따라 범용 파일을 선택하세요. 출처를 알 수 없거나 서명이 다른 설치 파일을 기존 앱 위에 설치하지 마세요. 서명 충돌이 발생하면 현재 설치 출처를 확인하고 구독 및 설정을 백업한 다음 이전 방법을 결정하세요. 앱을 바로 삭제하면 로컬 설정을 잃을 수 있으며 재설치해도 개인 구독 주소는 자동으로 복구되지 않습니다.

v2rayNG 또는 v2flyNG를 업데이트하거나 교체한 뒤에는 VPN 권한, 배터리 설정, 선택한 서버, 앱별 프록시 목록을 각각 확인해야 합니다. 이름이 비슷한 앱이라도 데이터가 자동으로 공유되지 않으며 코어 지원 범위도 별도로 점검해야 합니다. 자세한 시스템 설정은 VpnService 권한, 배터리 최적화 제외 및 앱별 프록시를 참고하세요. 이 장의 항목이 모두 정상이라면 설치를 반복하지 말고 앞의 시간 초과 및 DNS 장으로 돌아가 동일한 연결 단계에 따라 원인을 찾으세요.