V2Ray 연결 오류 해결 가이드

인터넷에 연결되지 않음: 먼저 문제 발생 계층 구분하기

‘클라이언트 연결됨’은 보통 프록시 서비스가 시작됐다는 뜻일 뿐, 모든 웹사이트에 접속할 수 있다는 의미는 아닙니다. 요청은 앱의 프록시 진입 경로, 로컬 리스너, 라우팅 판정, 도메인 조회, 서버 연결, 대상 사이트를 차례로 거칩니다. 어느 한 단계에서든 실패하면 브라우저가 계속 로딩되는 것처럼 보일 수 있습니다. 먼저 모든 앱에서 실패하는지, 브라우저에서만 실패하는지, 특정 사이트에서만 실패하는지 범위를 확인하세요. 범위에 따라 우선 점검할 설정이 달라지므로 바로 재설치하거나 노드를 반복해서 바꾸지 마세요.

클라이언트 사용 전후 비교하기

v2rayN에서는 먼저 시스템 프록시를 해제한 뒤 프록시 서비스를 중지하세요. 가상 네트워크 인터페이스 모드를 사용 중이라면 이것도 별도로 끕니다. Android에서는 VPN 연결을 중지하세요. 평소 바로 열리던 사이트에 접속해 현재 네트워크에 로그인 인증이 필요한지 확인합니다. 학교·호텔·공공 Wi-Fi는 먼저 인증을 완료해야 할 수 있으며, 프록시를 시작해도 네트워크 로그인을 대신할 수 없습니다. 클라이언트를 중지한 상태에서도 접속되지 않으면 Wi-Fi 연결, 게이트웨이 또는 네트워크 계정부터 복구한 뒤 클라이언트를 다시 확인하세요.

기본 네트워크가 복구되면 클라이언트를 시작하고 설정이 완전한 서버를 하나 선택하세요. 로그에서 설정 불러오기 실패, 리스너 시작 실패, 프로세스 종료 메시지가 있는지 확인합니다. v2rayN 창이 열려 있다고 코어 프로세스가 계속 실행 중인 것은 아닙니다. Android 알림창에 서비스 알림이 표시되어도 실제 접속 테스트를 대신할 수 없습니다. 시작 버튼을 누르자마자 로그에 오류가 나타난다면 로컬 서비스부터 확인하고, 웹사이트를 바꿔가며 테스트할 필요는 없습니다. 서비스가 안정적으로 실행된 뒤에야 접속 결과를 비교할 수 있습니다.

앱이 프록시 진입 경로를 사용하는지 확인하기

데스크톱에서 시스템 프록시를 켠 뒤 시스템 프록시 설정을 따르는 브라우저로 고정된 페이지에 접속하고, 접속 로그를 확인하세요. 새 요청이 전혀 없다면 브라우저 설정, 프록시 확장 프로그램 또는 앱 자체의 연결 방식이 원인일 가능성이 큽니다. 로그에 요청이 있지만 연결에 실패했다면 진입 경로는 대체로 작동하므로 다음으로 아웃바운드를 확인하세요. Android에서는 앱별 설정도 확인해야 합니다. 제외된 앱은 VPN으로 들어가지 않으므로 다른 앱이 프록시를 사용하더라도 해당 앱은 직접 연결될 수 있습니다.

라우팅 영향을 분리하려면 테스트할 트래픽을 프록시 아웃바운드로 보내는 규칙 모드로 잠시 전환한 뒤 같은 페이지에 접속하세요. 일부 클라이언트의 ‘전역’은 라우팅 선택일 뿐, 시스템 트래픽을 가로채는 설정이 아닙니다. 트래픽이 클라이언트에 들어오지 않으면 라우팅을 바꿔도 효과가 없습니다. 테스트 모드에서는 접속되지만 기존 모드에서 실패한다면 도메인 규칙, 규칙 순서, 기본 아웃바운드를 확인하세요. 테스트가 끝나면 임시 진단 설정을 그대로 두지 말고 평소 규칙으로 되돌리세요.

최소한의 작동 설정 유지하기

이전에 연결에 성공한 적이 있다면 모든 설정을 한꺼번에 초기화하지 말고 최근 변경 사항부터 되돌리세요. 새로 추가한 라우팅, DNS, 가상 네트워크 인터페이스, 브라우저 확장 프로그램을 각각 끄고 테스트합니다. 어느 단계에서 접속이 복구됐는지 기록한 뒤 해당 설정만 다시 구성하세요. 새 구독을 가져온 경우에도 기존 그룹을 바로 삭제하지 마세요. 이전 설정과 비교하면 클라이언트 공통 설정이 바뀐 것인지 새 서버 매개변수가 달라진 것인지 판단하는 데 도움이 됩니다.

복구 여부는 페이지의 주요 콘텐츠가 로드되는지, 브라우저를 다시 열어도 접속되는지, 클라이언트를 중지한 뒤 네트워크가 예상한 상태로 돌아오는지 확인해야 합니다. 한 번 접속에 성공한 것만으로 완전히 복구됐다고 볼 수는 없습니다. 작업 기준을 다시 잡으려면 구독 가져오기 및 첫 연결 가이드를 참고하세요. 개념별 차이는 자주 묻는 질문에서 확인할 수 있습니다. 시스템 프록시, 라우팅 모드, 코어 실행을 같은 설정으로 혼동하지 마세요.

노드 시간 초과: 연결과 핸드셰이크 구분하기

시간 초과는 특정 단계가 제한 시간 안에 응답하지 않았다는 뜻이며, 서버가 오프라인이라는 증거만으로 볼 수는 없습니다. 클라이언트의 테스트 기능은 TCP 연결 수립 시간을 측정할 수도 있고, 프록시를 통해 테스트 주소에 요청을 보낼 수도 있습니다. 두 결과의 의미는 다릅니다. 포트 연결에 성공해도 이후 인증이나 전송은 실패할 수 있고, 테스트 주소가 일시적으로 응답하지 않아 정상 설정이 시간 초과로 표시될 수도 있습니다. 실제 접속과 로그의 실패 단계를 함께 확인하고, 목록의 테스트 결과 하나만 보고 설정을 삭제하지 마세요.

서버 항목과 기기 시간부터 확인하기

현재 서버의 편집 화면을 열고 주소, 포트, 프로토콜, 전송 방식, 보안 설정이 같은 설정에서 가져온 값인지 확인하세요. 복사해 붙여넣을 때 공백이 섞이거나 구독 주소를 서버 주소 칸에 잘못 입력하기 쉽습니다. 해당 항목에서 전체 URL을 요구하지 않는 한 주소 칸에 웹 경로나 프로토콜 접두사가 포함되어서는 안 됩니다. 포트, 사용자 식별자, 비밀번호는 설정 제공자가 안내한 값을 사용하고 다른 항목을 보고 추측하지 마세요. 구독을 업데이트했다면 현재 선택한 항목이 여전히 유효한지도 확인하세요.

이어서 운영체제의 날짜, 시간, 시간대를 확인하세요. 시간이 크게 어긋나면 인증서 검증이나 일부 프로토콜 인증에 영향을 줄 수 있습니다. 자동 시간 설정을 켠 뒤 프록시 서비스를 다시 시작하고 같은 요청을 재현하세요. 로그에 인증서가 아직 유효하지 않거나 만료됐다는 메시지가 있다면 기기의 시간 오류인지 서버 인증서 문제인지 먼저 구분해야 합니다. 인증서 검증을 건너뛰어 오류를 덮지 마세요. 이는 보안 범위를 바꾸며 서버 이름이나 연결 주소 오류를 해결하지도 않습니다.

로그에 표시된 실패 단계에 따라 조치하기

연결 거부는 보통 대상이 연결을 거부했거나 해당 포트에서 서비스가 실행되지 않는다는 뜻입니다. 네트워크에 연결할 수 없다는 오류가 나타나면 기기의 네트워크, 주소 체계, 라우팅을 확인하세요. 계속 기다린 뒤 시간 초과가 발생했다면 경로의 패킷 손실, 서버 무응답, 로컬 보안 소프트웨어 차단이 원인일 수 있습니다. TLS 핸드셰이크 단계까지 진행됐다면 서버 이름, 보안 유형, 전송 설정을 중점적으로 확인하세요. 코어마다 오류 문구가 다를 수 있으니 전체 문맥을 보존하고 마지막 영어 단어만 잘라 판단하지 마세요.

VLESS와 REALITY 설정에서는 공개 키, 짧은 ID, 서버 이름 및 해당 항목에서 요구하는 기타 필드도 확인해야 합니다. WebSocket은 경로와 Host를, gRPC는 서비스 이름을 확인하세요. 이 값들은 서로 바꿔 쓸 수 있는 장식 요소가 아닙니다. 주소와 포트가 같아도 설정 전체가 같은 것은 아닙니다. 일부 구독 변환 과정에서 필드가 누락될 수 있으므로, 이때는 온라인에서 찾은 매개변수 조합을 하나씩 시험하지 말고 완전한 설정을 다시 받아야 합니다.

네트워크와 설정을 교차 테스트하기

같은 서버, 같은 대상 페이지, 같은 클라이언트 설정을 유지한 채 사용 가능한 네트워크 두 곳에서 각각 테스트하세요. 한 네트워크에서만 실패한다면 해당 네트워크의 DNS, 주소 체계, 인증, 접속 경로를 확인하세요. 모든 네트워크에서 실패하지만 다른 항목은 정상이라면 현재 서버나 매개변수를 우선 점검해야 합니다. 반대로 한 기기에서 모든 항목이 실패하고 다른 기기에서는 정상이라면 서버 전체가 동시에 고장 났다고 단정하기보다 해당 기기의 프록시 진입 경로, 시간, 코어 상태, 보안 소프트웨어를 먼저 확인하세요.

프로토콜 지원 여부는 현재 코어와 클라이언트의 설정 생성 방식에도 달려 있습니다. 가져오기에 성공했다는 것은 클라이언트가 링크를 인식했다는 뜻일 뿐, 선택한 코어가 모든 필드를 처리할 수 있다는 의미는 아닙니다. 코어를 바꾸기 전에 해당 항목에 필요한 프로토콜과 전송 방식을 지원하는지 확인하고 기존 설정을 보존한 뒤 같은 요청으로 검증하세요. 코어 계열과 설정 호환성은 Xray 코어와 V2Fly 코어의 차이를 참고하세요. 전환에 실패하면 되돌리고, 상태가 불분명한 채로 변경을 계속 쌓지 마세요.

설정 제공자에게 문의해야 한다면 연결 단계와 핸드셰이크 단계 중 어디서 실패했는지, 특정 네트워크에서만 발생하는지, 다른 항목은 사용할 수 있는지 설명하세요. 민감한 정보를 가린 오류 메시지만 전달하고 전체 구독 주소나 계정 매개변수는 공개하지 마세요. 복구 후 실제 웹페이지와 재연결을 다시 테스트해 우연히 성공한 것이 아닌지 확인하세요. 목록의 테스트 결과는 참고 자료일 뿐 유일한 판단 기준은 아닙니다.

구독 오류: 가져오기와 파싱 단계 나누기

구독 업데이트는 콘텐츠 가져오기, 콘텐츠 파싱, 그룹에 저장하기의 세 단계 이상으로 이루어집니다. 다운로드할 수 없다면 주소나 네트워크 문제일 가능성이 큽니다. 가져오기는 성공했지만 항목이 없다면 응답 형식이 클라이언트와 맞지 않을 수 있습니다. 업데이트 후 항목은 있지만 연결되지 않는다면 서버 설정을 점검해야 합니다. 이 세 가지 상황을 구분하면 그룹을 반복해서 삭제해 정보를 잃는 일을 막을 수 있습니다. 시작하기 전에 그룹 이름, 업데이트 방식, 오류 발생 시각을 기록하고 기존에 작동하던 설정을 보존하세요.

주소가 여전히 구독 링크인지 확인하기

구독 주소를 다시 복사할 때 마지막 매개변수가 빠지지 않았는지, 메신저가 삽입한 공백·줄바꿈·문장 부호가 붙지 않았는지 확인하세요. 구독 링크와 계정 로그인 페이지는 다릅니다. 브라우저에서 열리는 로그인 페이지를 구독 콘텐츠로 가져올 수는 없습니다. 일부 링크는 유효한 계정 상태나 인증 매개변수가 필요하므로 계정 만료, 주소 재설정, 데이터 사용량 변경이 응답 결과에 영향을 줄 수 있습니다. 상태는 원래 관리 페이지에서 확인하고, 출처가 불분명한 온라인 변환 페이지에 주소를 입력하지 마세요.

오류 코드는 범위를 좁히는 데 도움이 되지만 지나치게 단정해서는 안 됩니다. 인증되지 않았거나 접근이 금지됐다는 응답은 권한이나 접근 제한과 관련된 경우가 많고, 리소스를 찾을 수 없다는 응답은 주소가 바뀌었을 수 있습니다. 서버 오류라면 잠시 후 다시 시도해야 할 수도 있습니다. 성공 상태가 반환돼도 설정을 받았다는 뜻은 아닙니다. 로그인 페이지, 인증 안내 또는 점검 페이지가 실제 응답일 수 있습니다. 클라이언트 로그에 HTML 파싱 오류가 표시되면 요청이 어디로 전달됐는지 먼저 확인하세요. 아직 코어가 관여하지 않은 단계이므로 코어를 바로 바꿀 필요는 없습니다.

구독 업데이트의 네트워크 경로 확인하기

구독 다운로드는 직접 연결을 사용하거나 기존 프록시를 거칠 수 있으며, 구체적인 방식은 클라이언트의 업데이트 옵션에 따라 다릅니다. 현재 네트워크에서 구독 링크에 직접 접속할 수 있다면 직접 업데이트를 먼저 시도하세요. 프록시로만 접속할 수 있다면 먼저 작동하는 설정이 하나 필요합니다. 모든 설정이 작동하지 않는데 그 설정을 통해 구독을 업데이트해야 한다면 순환 의존이 생깁니다. 이때는 링크에 접속할 수 있는 다른 네트워크를 이용하거나 기존 관리 경로로 유효한 설정을 받으세요. 상태가 저절로 바뀌길 바라며 업데이트 버튼을 연속해서 누르지 마세요.

프록시를 통해 업데이트한다면 선택한 서버가 일반 웹페이지에 접속할 수 있는지, 로컬 리스너 포트가 바뀌지 않았는지 확인하세요. 일부 환경에서는 구독 요청에 네트워크 인증 페이지를 반환할 수 있으므로 다른 웹사이트가 브라우저에서 열린다고 문제가 완전히 배제되는 것은 아닙니다. 같은 구독 링크를 유지하고 직접 업데이트와 프록시 업데이트를 각각 테스트해 성공하는 경로만 사용하세요. 둘 다 실패하면 네트워크 경로 문제로 단정하지 말고 계정 상태와 서버 응답을 확인하세요.

파싱 성공 후 그룹과 필터 확인하기

업데이트가 완료됐는데 목록이 비어 보인다면 검색어와 유형 필터를 지운 뒤 해당 그룹으로 전환하세요. 일부 클라이언트는 마지막으로 선택한 그룹을 기억하므로 새 항목이 다른 그룹에 저장되어 표시되지 않을 수 있습니다. 업데이트 전후 항목 수가 달라졌다면 별칭, 주소, 프로토콜을 비교하고 정렬 순서만 보고 콘텐츠가 사라졌다고 판단하지 마세요. 구독 제공자가 내용을 변경하면 기존 항목이 교체되거나 클라이언트가 목록을 다시 정렬할 수 있습니다. 현재 선택된 서버가 유효한지 다시 확인하세요.

형식 호환성 문제는 원본에서 해결해야 합니다. 링크를 복사할 수 있다고 해서 현재 클라이언트가 모든 프로토콜과 전송 필드를 인식하는 것은 아닙니다. 가져오기 중 지원되지 않는다는 안내가 명확히 표시되면 해당 클라이언트의 지원 범위를 확인하거나 호환되는 구독 형식을 요청하세요. 오류를 없애려고 보안 필드를 임의로 삭제하지 마세요. 목록에 항목이 표시되어도 필수 매개변수가 빠져 연결되지 않을 수 있습니다. Android에서 가져오는 구체적인 방법은 구독 가져오기 가이드에서 확인하세요.

복구 후 그룹의 자동 업데이트 설정을 확인해 중복 그룹이 서로 다른 시간에 내용을 덮어쓰지 않도록 하세요. 먼저 수동 업데이트를 한 번 완료하고, 항목을 선택해 연결한 뒤 고정된 페이지에 접속하세요. 마지막으로 이전 그룹을 보존할 가치가 있는지 확인합니다. 잦은 새로고침으로 문제를 해결하려 하지 마세요. 반복 요청은 접근 제한을 유발하고 오류 발생 시점을 파악하기 어렵게 만들 수 있습니다. 구독을 정상적으로 가져왔지만 연결이 계속 시간 초과된다면 노드 시간 초과 섹션을 참고하세요. 이 경우 구독 업데이트 방식을 더 조정할 필요는 없습니다.

속도 저하: 단계별로 병목 측정하기

접속 지연은 도메인 조회, 첫 연결, 페이지 리소스 로딩, 지속 전송 중 어느 단계에서든 발생할 수 있습니다. 사이트를 열기 전에 화면이 오래 비어 있는 현상과 다운로드가 시작된 뒤 속도가 낮은 현상은 서로 다른 문제입니다. 목록의 지연 시간 테스트는 특정 요청의 응답 시간을 주로 보여주며 대역폭, 안정성, 모든 사이트의 성능을 직접 나타내지는 않습니다. 같은 페이지 열기나 같은 공개 파일 다운로드처럼 실제 작업 하나를 고정하고 어느 단계가 느린지 확인하세요.

로컬 네트워크와 백그라운드 사용량부터 점검하기

기기 위치를 유지하고 시스템 업데이트, 클라우드 동기화, 기타 대용량 작업을 잠시 중지한 뒤 Wi-Fi 신호와 재연결 빈도를 확인하세요. 공유 네트워크의 다른 기기가 외부 회선을 사용 중일 수도 있습니다. 프록시는 직접 접속도 느린 경우 Wi-Fi 간섭이나 로컬 회선 혼잡을 해결하지 못합니다. 유선 연결이 가능한 데스크톱은 유선 네트워크와 비교해 볼 수 있습니다. Android에서는 Wi-Fi와 모바일 네트워크를 비교하되 데이터 사용량에 유의하고 대용량 파일을 계속 다운로드할 필요는 없습니다.

테스트할 때마다 조건 하나만 바꾸세요. 같은 서버를 다른 시간대에 비교하면 부하 변화를 볼 수 있고, 같은 시간에 서버 두 개를 비교하면 경로 차이를 확인할 수 있습니다. 같은 서버로 웹사이트 두 곳을 비교하면 대상 사이트 문제인지 판단하는 데 도움이 됩니다. 서버, 코어, 라우팅, DNS를 한꺼번에 바꾼 뒤 속도 변화의 원인을 특정 설정으로 돌리지 마세요. 여러 차례 테스트한 결과는 같은 작업과 네트워크 조건으로 기록해 브라우저 캐시, 백그라운드 업데이트, 일시적인 재시도의 영향을 구분하세요.

로그와 리소스 사용량으로 병목 비용 파악하기

페이지가 빠르게 열리지만 이미지나 동영상이 계속 끊긴다면 패킷 손실, 서버 부하, 대상 사이트의 리소스 전송 경로를 살펴보세요. 첫 접속은 느리지만 새로고침하면 눈에 띄게 빨라지는 경우에는 DNS 조회, 핸드셰이크, 연결 재사용을 확인하세요. 특정 사이트만 느리고 같은 서버에서 다른 사이트는 정상이라면 해당 사이트와 서버의 외부 경로가 원인일 수 있습니다. 이때 로컬 프로토콜 매개변수를 바꿔도 효과가 없을 수 있으므로 사이트와 서버를 교차 비교하는 것이 더 정확합니다.

데스크톱에서는 시스템 작업 관리자에서 CPU, 메모리, 네트워크 사용량을 확인할 수 있습니다. 기기 리소스 부족, 여러 프록시 프로세스의 동시 실행, 가상 네트워크 인터페이스의 중복 처리로 부담이 커질 수 있습니다. 디버그 로그는 추가 디스크 쓰기를 유발하므로 진단이 끝나면 일반 로그 수준으로 되돌리세요. Android에서는 발열과 절전 정책도 확인해야 합니다. 지속적인 고부하로 시스템 스케줄링이 달라질 수 있으며, 화면을 끈 뒤 문제가 생긴다면 모바일 백그라운드 섹션을 확인하는 편이 좋습니다.

복잡한 설정으로 측정을 대신하지 않기

다중화, 동시 연결, 전송 설정은 어디서나 통하는 속도 향상 버튼이 아닙니다. 효과는 프로토콜, 서버 지원 여부, 연결 품질, 요청 유형에 따라 달라지며 설정이 맞지 않으면 연결이 실패할 수도 있습니다. 먼저 구독에서 받은 원래 매개변수를 유지하고, 테스트 목표를 설명할 수 있을 때만 한 항목을 바꾸며 되돌릴 수 있도록 기록하세요. 특히 현재 코어와 맞지 않는 설정 조각을 그대로 복사하지 마세요. 해당 필드가 무시되거나 시작 실패를 일으킬 수 있습니다.

라우팅도 성능에 영향을 줍니다. 같은 웹사이트의 페이지와 리소스가 서로 다른 도메인을 사용할 수 있으며, 규칙에 따라 다른 출구로 나뉘면 페이지가 불안정해질 수 있습니다. 테스트할 도메인을 잠시 동일한 출구로 보내 검증한 다음 규칙을 세분화하세요. 모든 트래픽을 계속 같은 방식으로 처리하도록 바꾸지는 마세요. 시스템 프록시와 라우팅의 역할은 시스템 프록시 모드 자세히 알아보기를 참고하세요. 먼저 트래픽이 어디로 들어가는지 확인한 뒤 경로 비용을 비교하세요.

복구 여부는 하나의 테스트 수치가 아니라 원래 작업을 기준으로 판단하세요. 자주 사용하는 페이지가 안정적으로 열리고 지속 전송이 끊기지 않는다면 설정을 더 추가할 필요는 없습니다. 특정 시간대나 특정 서버에서만 계속 느리다면 재현 조건을 기록해 설정 제공자에게 출구와 부하를 확인해 달라고 요청하세요. 클라이언트의 로컬 설정으로 원격 경로의 대역폭까지 바꿀 수는 없습니다. 따라서 병목이 기기에 있지 않다는 결론도 충분히 의미 있는 점검 결과입니다.

DNS 문제: 이름 조회가 이루어지는 위치 찾기

DNS는 도메인을 IP 주소로 변환하지만 프록시 환경에서는 운영체제만 이름 조회를 담당하는 것이 아닙니다. 브라우저에서 보안 DNS를 사용할 수 있고, 클라이언트에 자체 DNS 설정이 있을 수 있으며, 원격 서버가 도메인을 받아 직접 조회할 수도 있습니다. 시스템 DNS를 바꿔도 변화가 없다고 해서 설정이 저장되지 않은 것은 아닙니다. 해당 요청이 시스템 DNS를 사용하지 않았을 수도 있습니다. 점검을 시작하기 전에 문제가 발생한 도메인, 시각, 앱을 확인한 뒤 어느 계층이 이름 조회를 담당하는지 판단하세요.

DNS 조회 실패와 연결 실패 구분하기

브라우저에 서버를 찾을 수 없다는 메시지가 표시되거나 로그에 조회 오류가 있으면 DNS를 우선 확인하세요. 주소를 얻은 뒤 해당 주소에 연결하는 단계에서 시간 초과가 발생했다면 연결 경로를 점검해야 합니다. 모든 도메인 접속 실패를 DNS 문제로 분류하지 마세요. 웹사이트 도메인을 IP 주소로 바꾸어 접속하는 것도 신뢰할 수 있는 검증 방법이 아닙니다. 많은 사이트가 HTTPS 서버 이름과 가상 호스트에 의존하므로 주소로 접속하면 인증서 오류나 다른 사이트가 표시될 수 있습니다. 이런 현상만으로 원래 도메인의 DNS 문제를 입증할 수는 없습니다.

같은 도메인을 두 앱에서 비교해 브라우저에서만 실패하는지 확인하세요. 브라우저의 보안 DNS, 프록시 확장 프로그램, 별도 네트워크 설정은 시스템 경로를 우회할 수 있으므로 시스템 설정을 따르도록 잠시 되돌린 뒤 다시 테스트하세요. 이어서 직접 접속과 프록시 접속 결과를 비교합니다. 프록시 경로에서만 실패한다면 클라이언트 DNS 서버에 접속할 수 있는지와 DNS 요청의 아웃바운드를 확인하세요. 두 경로 모두 실패한다면 도메인이 유효한지, 현재 네트워크에서 인증을 완료했는지도 살펴보세요.

순환 의존성과 주소 체계 확인하기

흔한 순환 의존 사례는 프록시 서버에 연결하려면 서버 도메인을 먼저 조회해야 하지만, DNS 요청은 아직 연결되지 않은 프록시를 거쳐야 하는 경우입니다. 암호화된 DNS 서버 주소가 도메인인데 해당 주소를 조회할 초기 경로가 준비되지 않은 경우도 있습니다. 시작 후 조회 오류가 연속으로 나타나면 이런 선후 관계가 있는지 확인하세요. 조회 서버를 계속 추가하는 대신 초기 DNS 조회에 사용할 수 있는 경로를 마련해야 합니다. 구체적인 필드와 초기 조회 방식은 현재 코어의 지원 범위에 맞춰 설정하세요.

IPv4와 IPv6도 따로 살펴봐야 합니다. 네트워크에서 IPv6 주소를 받아도 기기에서 대상까지 이어지는 IPv6 경로가 안정적이라는 보장은 없습니다. 특정 네트워크에서만 지연 후 다른 주소 체계로 전환된다면 클라이언트가 지원하는 범위에서 주소 체계 우선순위를 잠시 조정한 뒤 같은 도메인으로 다시 테스트하세요. 결과가 주소 체계 문제를 명확히 가리킬 때만 설정을 유지하세요. 한 번 실패했다고 시스템 전체에서 주소 체계를 영구적으로 끄면 다른 앱과 로컬 네트워크 서비스에 영향을 줄 수 있습니다.

DNS 정책과 라우팅 정책 연결하기

도메인 기반 규칙과 IP 기반 규칙은 서로 다른 조건으로 일치 항목을 찾습니다. 다음은 도메인과 사설 주소를 기준으로 직접 연결을 먼저 선택하는 라우팅 객체 예시입니다. 완전한 클라이언트 설정이 아니므로 기존 설정을 대체할 수 없습니다. 이 예시는 현재 설정에 direct라는 아웃바운드가 있고 코어가 해당 규칙 데이터를 읽을 수 있어야 합니다. 클라이언트가 설정을 자동 생성한다면 생성 파일이 다음 시작 때 덮어써지지 않도록 GUI에서 동일한 규칙을 편집하는 것이 좋습니다.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

AsIs는 라우팅 단계에서 현재 대상 정보를 기준으로 규칙을 적용하며, 모든 IP 규칙을 위해 도메인을 주소로 변환하지는 않는다는 뜻입니다. 연결 과정에서 DNS가 전혀 필요하지 않다는 의미는 아닙니다. IP 조건을 사용하는 규칙에서 인바운드가 도메인을 제공할 때 조회가 발생하는지는 라우팅 정책에 따라 달라집니다. 설정을 바꾸기 전에 목표가 도메인 조회 복구인지 특정 IP 규칙의 일치인지 분명히 하세요. 두 요구사항을 단순히 ‘원격 DNS’ 스위치 하나로 해결할 수는 없습니다.

수정한 뒤 프록시 서비스를 다시 시작하고 테스트 앱도 새로 여세요. 필요하다면 시스템에서 제공하는 방법으로 DNS 캐시를 새로고침합니다. 브라우저, 운영체제, 클라이언트가 각각 결과를 캐시할 수 있으므로 한 번 새로고침한다고 기존 연결이 모두 지워지는 것은 아닙니다. 같은 도메인으로 반복 테스트하고 오류가 조회 단계에서 연결 단계로 바뀌었는지 확인하세요. DNS가 복구됐는데도 대상에 접속할 수 없다면 다음 계층을 점검하고 DNS를 계속 바꾸지 마세요. 용어는 용어 설명에서 확인해 조회 서버, 요청 경로, 라우팅 출구를 구분하세요.

시스템 프록시가 작동하지 않음: 적용 범위 확인하기

시스템 프록시는 운영체제에 프록시 주소를 등록해 앱이 읽도록 하는 설정일 뿐, 모든 프로그램이 이를 사용한다고 보장하지는 않습니다. 라우팅 규칙은 클라이언트에 이미 들어온 트래픽만 처리합니다. 가상 네트워크 인터페이스 모드는 권한, 라우팅, DNS 설정이 별도로 필요한 또 다른 트래픽 처리 경로입니다. 먼저 진입 방식을 하나 선택하고 여러 방식을 동시에 켜지 마세요. 그다음 앱이 해당 경로를 따르는지에 따라 다음 점검을 진행하세요. 클라이언트에 특정 라우팅 모드가 표시된다고 시스템 프록시가 올바르게 설정된 것은 아닙니다.

리스너 주소와 포트부터 확인하기

먼저 v2rayN에서 실제로 활성화된 로컬 인바운드 유형, 리스너 주소, 포트를 확인한 뒤 운영체제의 프록시 설정과 대조하세요. HTTP 프록시, SOCKS 프록시, 혼합 인바운드는 포트 번호만 보고 서로 바꿔 쓸 수 없습니다. 앱에서 요구하는 프로토콜에 맞는 진입 경로를 사용해야 합니다. 리스너가 로컬 루프백 주소를 사용하면 현재 기기에서만 접속할 수 있습니다. 기기의 브라우저 문제를 해결하려고 모든 네트워크 인터페이스에서 수신하도록 바꾸지 마세요. 접속 가능 범위가 넓어집니다.

로그에 포트 사용 중이라는 메시지가 나오면 이전 클라이언트 인스턴스나 다른 프록시 프로그램을 종료한 뒤 다시 시작하세요. GUI에서 로컬 포트를 바꿀 수도 있지만 변경 후에는 수동으로 설정한 모든 앱의 포트도 함께 바꿔야 합니다. 시스템 프록시는 클라이언트가 자동으로 갱신할 수 있지만 브라우저 확장 프로그램, 다운로드 도구, 개발 프로그램의 별도 프록시 설정은 자동으로 따라오지 않습니다. 클라이언트 포트만 바꾸고 앱 설정을 그대로 두는 것은 일부 프로그램만 작동하고 나머지는 실패하는 흔한 원인입니다.

시스템·브라우저·앱 설정의 우선순위 확인하기

브라우저는 시스템 설정을 따르거나 확장 프로그램에서 지정한 프록시 또는 자동 설정 스크립트를 사용할 수 있습니다. 먼저 프록시 관련 확장 프로그램을 잠시 끄고 브라우저의 네트워크 설정이 별도로 시스템 설정을 덮어쓰지 않는지 확인한 뒤 테스트하세요. 일부 프로그램은 시스템 프록시를 읽지 않아 프로그램 자체에서 HTTP 또는 SOCKS 진입 주소를 설정해야 합니다. 다른 프로그램은 별도의 네트워크 서비스를 통해 연결됩니다. 브라우저가 접속된다고 모든 앱이 프록시를 사용하는 것은 아니며, 특정 앱이 직접 연결된다고 시스템 설정 전체가 작동하지 않는 것도 아닙니다.

Windows에서는 네트워크 구성 요소마다 서로 다른 프록시 설정을 읽을 수 있습니다. macOS 프록시 설정은 현재 네트워크 서비스에 연결되므로 유선과 무선 네트워크를 전환한 뒤 다시 확인하세요. Linux 데스크톱 환경의 프록시 설정도 모든 프로그램에 자동 적용되는 것은 아닙니다. 로그인 후에만 문제가 발생한다면 클라이언트에서 코어가 실행됐는지, 시스템 프록시가 여전히 수신 중인 포트를 가리키는지 확인하세요. 자동 시작 절차는 Linux 설치 및 데스크톱 로그인 시 자동 시작 안내를 참고하세요.

프록시 진입 경로와 라우팅 결과를 각각 확인하기

고정된 웹사이트에 요청을 보내고 접속 로그에 해당 대상이 표시되는지 확인하세요. 기록이 없다면 진입 경로부터 점검합니다. 기록이 있고 직접 연결로 분류된다면 라우팅 규칙을 확인하세요. 기록이 있으며 프록시 아웃바운드 오류가 있다면 서버를 확인해야 합니다. 로그가 비활성화됐거나 앱이 기존 연결을 재사용하면 새 기록이 바로 보이지 않을 수 있으므로 테스트 페이지를 닫고 앱을 다시 여세요. 판단은 여러 근거를 조합해야 합니다. 로그 한 줄이 없다는 이유만으로 트래픽이 들어오지 않았다고 단정하지 마세요.

가상 네트워크 인터페이스도 사용한다면 먼저 이를 끄고 시스템 프록시만 남겨 비교하세요. 반대로 가상 네트워크 인터페이스를 테스트할 때는 시스템 프록시를 유지할지 분명히 해야 합니다. 두 방식을 동시에 처리하면 중복 전달, 예외 규칙 불일치, DNS 경로 변화가 발생할 수 있습니다. 가상 네트워크 인터페이스 시작 실패는 시스템 권한과 드라이버 상태에도 관련되므로 라우팅 모드를 반복 전환해 해결할 수 없습니다. 클라이언트가 실제로 요구하는 권한만 부여하고 관련 프로그램 전체를 계속 높은 권한으로 실행하지 마세요.

복구 후 프록시 사용 중, 중지 후, 다시 로그인한 뒤의 세 가지 상태를 각각 확인하세요. 사용 중에는 테스트 앱의 트래픽이 프록시에 들어가는지, 중지 후에는 예상한 직접 연결로 돌아오는지, 다시 로그인한 뒤에는 포트와 시작 상태가 올바른지 테스트합니다. 로컬 프록시를 LAN 기기에서 사용하려면 수신 범위, 접근 권한, 방화벽 규칙을 별도로 설계하세요. 이 요구사항을 현재 기기의 문제 해결과 섞지 마세요. 시스템 프록시와 전역·중국 본토 우회 규칙의 차이는 시스템 프록시 모드 자세히 알아보기에서 확인할 수 있습니다.

시작 실패 및 충돌: 오류 상황 보존하기

GUI가 열리지 않는 문제, 창은 정상인데 코어가 종료되는 문제, 한동안 사용한 뒤 프로그램 전체가 닫히는 문제는 서로 다릅니다. 시작 실패는 설치 파일, 실행 환경, 권한을 먼저 확인해야 합니다. 코어가 종료되면 설정과 포트를 점검하고, 실행 중 충돌이 발생하면 리소스 사용량과 유발 동작도 살펴봐야 합니다. 마지막으로 정상 작동한 시점부터 처음 오류가 발생할 때까지 업데이트, 폴더 이동, 설정 변경, 시스템 보안 알림 등 어떤 일이 있었는지 기록하세요. 단서를 없애지 않도록 모든 데이터를 바로 삭제하지 마세요.

플랫폼, 아키텍처, 설치 위치 확인하기

데스크톱에서는 v2rayN을 우선 사용하고 클라이언트 다운로드 페이지에서 운영체제와 프로세서 아키텍처에 맞는 설치 파일을 선택하세요. macOS는 Apple Silicon과 Intel을 구분해야 하며, Linux는 배포판 패키지 형식과 프로세서 아키텍처를 확인해야 합니다. Windows 데스크톱판과 클래식 WPF판은 서로 다른 UI 계열이므로 실행 환경은 각각의 안내를 따르세요. 패키지 형식이 같아도 아키텍처가 같다는 뜻은 아닙니다. 설치 프로그램이 실행되는지는 프록시 설정 내용과 직접 관련이 없으므로 먼저 프로그램 자체를 실행하세요.

설치 패키지 유형에 맞게 설치하거나 압축 파일 전체를 제대로 해제하세요. 압축 파일 미리보기에서 바로 실행하거나 관련 리소스를 빠뜨린 채 프로그램 파일 하나만 복사하지 마세요. 데이터를 정상적으로 쓸 수 있는 위치에 저장하고 디스크 공간과 폴더 권한을 확인하세요. 보안 소프트웨어가 프로그램을 처리했다면 시스템 기록에서 대상 파일과 감지 이유를 확인한 뒤 조직이나 기기의 보안 정책에 따라 조치하세요. 프록시 클라이언트를 실행하려고 전체 시스템 보호를 끄거나 출처가 불분명한 파일로 누락된 파일을 보충하지 마세요.

UI 문제와 코어 설정 문제 구분하기

UI가 열리지만 연결 버튼을 누르자마자 중지된다면 먼저 코어 로그를 확인하세요. 흔한 원인으로는 JSON 문법 오류, 지원하지 않는 필드, 존재하지 않는 아웃바운드 태그, 규칙 리소스 읽기 실패, 리스너 포트 충돌이 있습니다. 오류 메시지는 설정 위치나 관련 필드를 가리키는 경우가 많으므로 최근 추가한 설정부터 되돌리세요. 구독 업데이트 후에만 문제가 발생했다면 이전에 작동하던 항목과 비교해 특정 항목 생성이 실패하는지 모든 설정에서 실패하는지 확인하세요.

다음은 Xray와 V2Fly 설정에서 흔히 쓰이는 로그 수준을 설명하는 로그 객체 예시이며, 전체 시작 설정은 아닙니다. 클라이언트에서 GUI 로그 수준을 선택할 수 있다면 인터페이스에서 조정하세요. 더 자세한 정보가 필요할 때만 디버그 수준을 잠시 켜고 한 번 재현한 뒤 관련 부분을 저장하고 일반 수준으로 되돌리세요. 상세 로그를 계속 켜두면 디스크 쓰기가 늘고 접속한 대상이 많이 기록될 수 있으므로 기본 문제 해결 설정으로 유지하지 마세요.

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

설정을 직접 편집했다면 따옴표, 쉼표, 괄호도 확인하세요. 표준 JSON은 주석과 마지막의 불필요한 쉼표를 허용하지 않으며, 일부 문서의 설명용 조각은 완전한 설정에 그대로 붙여 넣을 수 없습니다. 클라이언트가 생성한 파일을 임시로 수정하면 다음 시작 때 다시 생성되어 덮어쓰일 수 있으므로 해당 GUI 설정 항목을 우선 찾으세요. 생소한 필드를 프로그램이 시작될 때까지 무작정 삭제하지 마세요. 인증, 보안, 라우팅 동작이 달라질 수 있습니다.

되돌릴 수 있는 방식으로 손상된 설정 분리하기

사용자 설정이 손상됐다고 의심되면 클라이언트를 완전히 종료하고 백그라운드 프로세스가 끝났는지 확인한 뒤 설정 폴더를 백업하세요. 설정 폴더 위치는 플랫폼, 설치 방식, 데이터 모드에 따라 다르므로 클라이언트 설명이나 인터페이스에서 확인하고, 온라인에서 본 고정 경로를 기준으로 파일을 일괄 삭제하지 마세요. 백업한 뒤 별도의 깨끗한 데이터 환경에서 테스트하세요. 실행된다면 구독, 라우팅, UI 설정을 하나씩 복원해 어떤 설정 종류가 문제를 일으키는지 확인합니다.

업데이트 후 문제가 생겼다고 바로 이전 버전으로 되돌릴 필요는 없습니다. 패키지가 완전히 설치됐는지, 이전 프로세스가 계속 실행 중인지, 새 UI가 기존 설정 항목을 지원하는지 먼저 확인하세요. 이전 버전으로 돌아가야 한다면 업데이트 전후의 데이터 백업을 보존하고 서로 다른 계열의 프로그램이 하나뿐인 설정을 번갈아 수정하지 않도록 하세요. 재설치해도 사용자 데이터가 지워지지 않을 수 있으므로 설정을 확인하지 않고 같은 프로그램을 반복 설치하면 오류가 그대로 재현될 수 있습니다. 클라이언트 비교와 계열별 차이는 클라이언트 비교에서 확인하세요.

복구 후에는 구독 업데이트, 서버 전환, 라우팅 설정 열기, 시스템 재로그인처럼 원래 문제를 일으킨 동작을 다시 테스트하세요. 문제를 보고할 때 운영체제, 아키텍처, 설치 방식, 민감 정보를 가린 로그를 제공하고 사용자 데이터 폴더는 공개하지 마세요. 특정 설정에서 오류가 재현된다면 사용한 프로토콜과 전송 유형을 설명하세요. 빈 설정에서도 충돌한다면 설정 문제와 혼동하지 말고 실행 환경이나 프로그램 자체를 우선 살펴보세요.

Android 문제: 권한, 백그라운드 실행, 네트워크 전환

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 사용하고 V2Fly 코어를 사용하는 v2flyNG를 대안으로 선택할 수 있습니다. 모바일에서는 서버와 구독뿐 아니라 VPN 권한, 앱별 규칙, 백그라운드 정책, Wi-Fi와 모바일 네트워크 전환도 점검해야 합니다. 시스템에 VPN 표시가 나타난다는 것은 해당 연결이 존재한다는 뜻일 뿐 프록시 서버로 대상에 접속할 수 있다는 뜻은 아닙니다. 실제로 실행 중인 클라이언트를 먼저 확인한 뒤 이 장의 순서대로 비교하세요. 여러 앱의 상태가 서로 영향을 주지 않도록 주의해야 합니다.

VPN 권한과 연결 충돌 해결하기

처음 연결을 시작할 때 시스템에 표시되는 VPN 권한 요청을 승인해야 합니다. 승인을 완료하지 않았거나 취소했거나 기기 관리 정책에 의해 제한되면 서비스를 시작할 수 없습니다. Android의 일반 앱 VPN 연결은 보통 같은 유형의 여러 앱이 동시에 사용할 수 없으므로 다른 VPN 앱을 먼저 중지하세요. 로컬 VPN 방식으로 필터링하는 앱도 포함됩니다. 업무용 프로필이나 관리 기기에는 별도 제한이 있을 수 있으므로 노드를 바꿔 시스템 관리 정책을 우회하려 하지 마세요.

항상 켜기 VPN 또는 VPN을 사용하지 않는 연결 차단을 켰다면 연결이 끊길 때 어떻게 동작하는지 이해해야 합니다. 프록시 서비스가 중지된 뒤 시스템 설정에 따라 다른 네트워크 접속도 차단될 수 있습니다. 따라서 ‘중지 후에도 인터넷이 안 됨’이 반드시 네트워크 손상을 뜻하지는 않습니다. 원래 정책을 먼저 기록한 뒤 잠시 설정을 바꿔 비교하고, 테스트가 끝나면 필요한 설정으로 되돌리세요. 클라이언트 버튼 상태만 보지 말고 시스템 VPN 설정에서 현재 연결 앱과 제한 옵션을 확인하세요.

화면을 끈 뒤 연결 끊김 및 백그라운드 제한 점검하기

화면이 켜져 있을 때는 접속되지만 일정 시간 화면을 끈 뒤 연결이 끊긴다면 시스템 배터리 최적화와 백그라운드 실행 제한부터 확인하세요. 기기마다 ‘백그라운드 활동 허용’, ‘자동 시작’, ‘배터리 최적화’의 이름이 다르므로 현재 시스템 메뉴에서 찾아보면 됩니다. 계속 실행할 필요가 있는 클라이언트에만 적절한 권한을 부여하고 모든 앱의 절전 기능을 끄지 마세요. 설정 후 화면 켜기, 화면 끄기, 앱 다시 열기의 세 상황을 각각 테스트하고 서비스 알림이 사라지거나 시스템이 다시 생성하는지 확인하세요.

데이터 절약 모드와 백그라운드 모바일 데이터 제한 때문에 서비스는 실행 중이지만 전송이 멈출 수도 있습니다. 현재 클라이언트가 사용 중인 네트워크에서 인터넷을 사용할 수 있는지 확인하고, 특히 Wi-Fi에서 모바일 네트워크로 전환한 뒤 상태를 살펴보세요. 전환할 때마다 다시 연결해야 한다면 이전 연결이 갱신되지 않았는지 DNS 경로가 달라졌는지 먼저 비교하고 구독을 바로 삭제하지 마세요. 비행기 모드를 켰다가 해제하는 방법은 네트워크 재연결을 비교하는 용도일 뿐 장기적인 해결책은 아닙니다.

앱별 설정과 로컬 네트워크 동작 확인하기

앱별 프록시는 포함 목록 또는 제외 목록을 사용할 수 있으며 두 설정의 의미는 반대입니다. 목록을 바꾼 뒤 VPN을 다시 연결해야 새 선택이 적용됩니다. 목록에 포함된 앱과 제외된 앱을 각각 하나씩 테스트하세요. 브라우저에서는 접속되지만 다른 앱에서 실패한다면 해당 앱이 VPN을 사용하는지, 앱 내부에 별도 프록시나 네트워크 설정이 있는지 확인하세요. 특정 앱의 캐시, 계정 연결, 대상 서비스 문제는 모든 트래픽의 라우팅을 바꿔도 정확히 판단할 수 없습니다.

LAN 기기에 접속할 수 없다면 로컬 주소가 프록시로 전달되는지, 클라이언트에 LAN 우회 설정이 있는지 확인하세요. 프린터, 홈 스토리지, 라우터 관리 페이지는 현재 LAN 경로를 사용하며 원격 프록시가 이 경로를 대신할 수 없습니다. 사설 주소 규칙, 시스템 VPN 라우팅, 앱 자체의 장치 검색 기능이 함께 작동할 수 있으므로 VPN을 중지한 상태에서 먼저 비교한 뒤 하나씩 다시 설정하세요. LAN 접속 권한을 넓히는 것을 휴대폰의 로컬 네트워크 접속 문제를 해결하는 일반적인 방법으로 사용하지 마세요.

설치 및 복구 후 확인 순서

설치 파일은 기기 아키텍처에 맞춰 Android 다운로드 페이지에서 선택하세요. 설치가 실패하면 저장 공간, 시스템 설치 안내, 프로세서 호환성, 기존 설치 출처를 먼저 확인하세요. 구독과 사용자 규칙이 삭제될 수 있으므로 바로 앱을 제거하지 마세요. 재설치가 필요하다면 클라이언트가 지원하는 방법으로 필요한 설정을 먼저 저장하고 계정 정보가 포함된 데이터는 안전하게 보관하세요. 범용 패키지와 아키텍처 전용 패키지 중 무엇을 선택할지는 기기의 실제 사양을 기준으로 해야 합니다.

복구 후에는 일반 웹 접속, 앱별 동작, 화면이 꺼진 상태의 백그라운드 유지, 네트워크 전환 순으로 확인하고 매 단계에서 같은 유효 서버를 사용하세요. 모바일 네트워크에서만 실패한다면 DNS 및 시간 초과 섹션에서 접속 경로를 비교하세요. 백그라운드에서만 실패한다면 시스템 제한을 계속 점검하세요. 클라이언트별 차이는 세 클라이언트 비교에서 확인할 수 있습니다. 일상적인 사용 상황에서 안정적으로 작동하는지 확인한 뒤 자동 업데이트와 기타 사용자 설정을 복원하고 다음 진단을 위해 작동하는 설정을 보관하세요.