troubleshooting manual

V2Ray 문제 해결 가이드

로컬 네트워크부터 시작해 클라이언트, 구독, 노드, 라우팅 및 DNS를 차례로 확인합니다. 한 번에 하나의 조건만 바꾸고 재현 가능한 결과로 문제 범위를 좁혀 보세요.

문제 해결 시작 빠른 튜토리얼 보기 문제 해결 열기

how to use

클라이언트를 처음 설정한다면 먼저 빠른 시작 튜토리얼에 따라 구독 가져오기, 노드 선택 및 시스템 프록시 설정을 완료하세요. 이 가이드는 전체 설치 과정을 반복하지 않고, “설정은 완료했지만 결과가 예상과 다른” 상황을 다룹니다. v2rayN, v2rayNG 또는 v2flyNG를 다시 받아야 한다면 다운로드 센터에서 플랫폼에 맞는 클라이언트를 선택하세요.

문제 해결을 시작하기 전에 세 가지 사실을 기록하세요. 문제가 언제 시작됐는지, 모든 노드가 실패하는지, 클라이언트를 종료하면 일반 네트워크가 정상인지 확인합니다. 그런 다음 현재 증상에 해당하는 장만 실행하세요. 클라이언트 재설치, DNS 변경, 구독 업데이트, 네트워크 변경을 동시에 진행하지 마세요. 여러 변수를 한꺼번에 바꾸면 복구되더라도 실제 원인을 확인할 수 없습니다.

chapter one

인터넷에 연결되지 않음: 로컬 네트워크와 프록시 문제 분리

“프록시를 켠 뒤 모든 웹페이지에 접속할 수 없다”는 사실만으로 노드가 작동하지 않는다고 단정할 수는 없습니다. 브라우저 요청은 애플리케이션에서 대상 사이트까지 시스템 프록시, 로컬 수신 포트, 클라이언트 라우팅, 프로토콜 연결 및 DNS 확인 단계를 거칩니다. 어느 한 단계라도 중단되면 겉으로는 같은 증상이 나타날 수 있습니다. 가장 효과적인 출발점은 재설치가 아니라 클라이언트를 종료했을 때 네트워크가 복구되는지 확인한 뒤, 문제가 프록시 경로에 있는지 기본 네트워크에 있는지 판단하는 것입니다.

프록시를 거치지 않는 기준 결과 만들기

먼저 클라이언트에서 시스템 프록시를 끄거나 연결을 중지하고, 별도 프록시가 설정된 브라우저를 완전히 종료한 뒤 일반 웹페이지를 다시 열어 보세요. 그래도 접속할 수 없다면 Wi-Fi, 유선 네트워크, 라우터 로그인, 네트워크 인증 또는 상위 연결 문제를 우선 처리합니다. 다른 정상 작동이 확인된 네트워크로 잠시 전환해 교차 테스트할 수 있지만, 바로 클라이언트 설정을 변경하지는 마세요. 프록시를 끄면 정상이고 켜는 즉시 실패한다면 클라이언트 연결 경로의 문제입니다.

데스크톱에서는 “클라이언트 창 닫기”와 “백그라운드 프로세스 종료”도 구분해야 합니다. v2rayN은 기본 창을 닫아도 트레이에서 계속 실행되는 경우가 있으며 시스템 프록시가 로컬 포트를 계속 가리킬 수 있습니다. 트레이 메뉴에서 종료한 뒤 시스템 프록시가 꺼진 상태로 돌아왔는지 확인하세요. 브라우저에 별도의 HTTP 또는 SOCKS 프록시를 설정했다면 이전 포트가 계속 요청을 가로채지 않도록 일시적으로 “시스템 설정 사용”으로 되돌리거나 수동 프록시를 끄세요.

로컬 수신 포트가 실제로 존재하는지 확인

시스템 프록시는 요청을 127.0.0.1과 같은 로컬 주소 및 특정 수신 포트로 전달할 뿐이며, 실제 요청을 받는 것은 클라이언트 코어입니다. 코어가 시작되지 않았거나 포트를 다른 프로그램이 사용 중이면 시스템 프록시가 켜져 있어도 작동하지 않습니다. v2rayN에서는 먼저 실행 로그를 확인해 설정이 로드되었고 “address already in use”와 같은 포트 사용 중 메시지가 없는지 확인하세요. Windows에서는 터미널에서 일반적인 로컬 포트가 수신 상태인지 확인할 수 있습니다:

netstat -ano | findstr LISTENING
netstat -ano | findstr 10808

두 번째 명령의 포트는 클라이언트 설정 페이지에 표시된 실제 포트로 바꿔야 합니다. 아무 출력도 없으면 해당 포트를 수신 중인 프로세스가 없다는 뜻입니다. 출력된 프로세스 식별자가 실행 중인 클라이언트가 아니라면 포트 충돌일 수 있습니다. 이 경우 포트를 사용 중인 프로그램을 종료하거나 v2rayN에서 로컬 수신 포트를 변경한 뒤, 브라우저 수동 프록시, 명령줄 환경 변수 및 이전 포트에 의존하는 다른 소프트웨어도 함께 업데이트하세요. 자세한 방법은 로컬 포트 충돌 문제 해결에서 확인할 수 있습니다.

최소 설정으로 라우팅 규칙 간섭 배제

수신 상태가 정상인지 확인한 뒤 라우팅 모드를 잠시 전역으로 전환하고, 사용 가능 여부가 확인된 노드를 선택하세요. 전역 모드는 사용자 지정 규칙, 도메인 분류 및 직접 연결 출구 설정을 우회하므로 분할 라우팅이 원인인지 판단하기에 적합합니다. 전역 모드에서는 작동하지만 기존 모드에서 작동하지 않는다면 기존 모드로 돌아간 후 규칙 순서를 하나씩 확인하세요. 특히 앞쪽에 있는 domain, geosite, geoip 및 기본 규칙을 살펴봐야 합니다. 규칙은 일반적으로 위에서 아래로 매칭되므로, 범위가 지나치게 넓은 직접 연결 규칙은 프록시 출구로 보내야 할 요청을 너무 일찍 처리할 수 있습니다.

전역 모드에서도 작동하지 않으면 같은 구독의 다른 노드로 바꿔 보세요. 한 노드만 실패하고 다른 노드는 정상이라면 로컬 프록시 경로는 대체로 정상이며 노드 매개변수나 서버 상태에 문제가 집중된 것입니다. 모든 노드가 실패한다면 시스템 시간, 방화벽, 프로토콜 매개변수 및 DNS를 계속 확인하세요. “지연 시간 테스트에 값이 표시된다”는 사실을 웹페이지 접속 가능과 동일하게 보지 마세요. 일부 테스트는 TCP 연결만 확인하므로 전체 프로토콜 핸드셰이크, 전송 계층 및 대상 요청까지 검증하지 않습니다.

기준 결과 우선 확인할 범위 다음 단계
프록시를 꺼도 인터넷에 연결되지 않음 로컬 네트워크, 라우터, 네트워크 인증 기본 네트워크부터 복구
프록시를 켜면 모두 실패 수신 포트, 코어 시작, 시스템 프록시 로그 및 포트 확인
일부 노드만 실패 노드 상태, 프로토콜 및 전송 매개변수 노드 시간 초과 장으로 이동
전역 모드는 정상, 분할 라우팅은 실패 라우팅 규칙 순서 및 출구 사용자 지정 규칙 줄이기

chapter two

노드 시간 초과: 연결 단계별로 매개변수 확인

노드 시간 초과는 정해진 시간 안에 클라이언트가 예상 응답을 받지 못했다는 뜻이지만, 시간 초과가 발생한 위치는 다를 수 있습니다. 도메인을 확인할 수 없거나, 대상 포트의 TCP 연결을 만들지 못하거나, TLS 핸드셰이크가 실패하거나, 프로토콜 인증 매개변수가 맞지 않아도 비슷한 오류가 표시됩니다. 문제 해결은 노드 설정과 무관한 조건부터 시작해 프로토콜 세부 사항으로 단계적으로 들어가야 합니다. 로컬 네트워크를 확인하기도 전에 UUID, 경로 또는 전송 방식을 반복해서 수정하지 마세요.

시스템 시간과 대상 주소부터 확인

시스템 시간 오차는 TLS 인증서의 유효 기간 판단에 영향을 주며, 시간 창에 의존하는 인증 절차를 방해할 수도 있습니다. Windows, macOS, Android 및 Linux에서 날짜, 시간, 시간대 자동 설정을 켠 뒤 다시 동기화하세요. 장시간 절전 모드, 듀얼 부팅 전환 또는 메인보드 배터리 이상이 있으면 시간 오차가 더 쉽게 발생합니다. 시간을 수정한 후에는 코어를 완전히 중지하고 다시 연결해야 합니다. 기존 연결이 모든 핸드셰이크를 자동으로 다시 수행하지는 않습니다.

그다음 노드 주소를 확인하세요. 주소가 도메인이라면 기기에서 해당 도메인을 확인할 수 있는지 먼저 확인합니다. IP라면 복사 과정에서 들어간 공백, 포트 구분자 또는 프로토콜 접두사를 제거하세요. 노드 주소 입력란에는 일반적으로 호스트 이름이나 IP만 입력하며, 전체 구독 URL, 웹페이지 경로 또는 https://를 함께 넣지 않습니다. 포트는 구독에서 제공한 대상 포트여야 하며, 로컬 SOCKS 또는 HTTP 수신 포트를 서버 포트란에 입력하면 안 됩니다.

네트워크 불통과 프로토콜 핸드셰이크 실패 구분

데스크톱에서는 시스템 도구로 대상 호스트와 TCP 연결을 만들 수 있는지 확인할 수 있습니다. Windows PowerShell에서는 다음 명령을 실행하세요. 호스트와 포트는 노드 설정의 값으로 바꿉니다:

Test-NetConnection example.com -Port 443

Linux 또는 macOS에서는 다음을 사용할 수 있습니다:

nc -vz example.com 443

이 명령은 대상 포트만 확인하며 VMess, VLESS, Trojan 또는 전송 계층 설정은 검증하지 않습니다. 포트 테스트가 실패하면 먼저 로컬 네트워크, 대상 주소, 포트 및 서버 접근 가능성을 확인하세요. 포트 테스트는 성공하지만 클라이언트 핸드셰이크가 실패한다면 프로토콜 매개변수에 집중합니다. 일부 네트워크 환경에서는 진단 명령이 제한될 수 있으므로 한 번의 실패만으로 결론을 내리지 말고 다른 네트워크에서 재시험하는 것이 좋습니다.

로그를 읽을 때는 오류가 발생한 단계를 확인하세요. 도메인 확인 오류에는 일반적으로 lookup, resolve 또는 DNS 관련 문구가 포함됩니다. connection refused는 대상이 연결을 명확히 거부했다는 뜻이고, timeout은 제한 시간 안에 응답이 돌아오지 않았다는 뜻입니다. certificate, handshake, TLS 관련 오류는 도메인, 인증서 이름, 시스템 시간 또는 TLS 매개변수와 관련된 경우가 많습니다. 마지막 한 줄만 캡처하지 말고 앞뒤 열 줄 이상도 함께 확인하세요. 실제 실패를 유발한 주소와 출구 이름이 그 안에 있을 수 있습니다.

프로토콜 및 전송 항목을 하나씩 대조

노드를 수동으로 입력할 때는 프로토콜 계층과 전송 계층을 나누어 확인해야 합니다. VMess의 주요 항목은 주소, 포트, 사용자 식별자, 암호화 또는 보안 옵션입니다. VLESS는 사용자 식별자, 흐름 제어, 암호화 항목 및 해당 전송 설정을 확인해야 합니다. Trojan은 비밀번호, TLS 서비스 이름 및 전송 매개변수가 핵심입니다. WebSocket은 경로와 Host를, gRPC는 서비스 이름을 확인하세요. REALITY 설정은 구독에서 제공한 서비스 이름, 공개 키, 짧은 식별자 및 지문과 대조해야 합니다. 어느 한 항목이라도 비슷하지만 완전히 일치하지 않으면 핸드셰이크가 실패할 수 있습니다.

노드가 구독에서 가져온 것이라면 필드를 수동으로 고치기보다 먼저 구독을 다시 업데이트하세요. 구독 제공자가 전송 매개변수를 변경해도 기존 노드 이름은 그대로이고 내부 설정만 달라질 수 있습니다. 업데이트 전에 구독 주소 자체가 유효한지 확인하고, 업데이트 후 새로 생성된 노드를 선택한 다음 코어를 재시작하세요. 모든 노드가 동시에 시간 초과된다면 노드 시간 초과 문제 해결 순서에 따라 로컬 네트워크와 시스템 시간을 확인하세요. 한 노드만 실패한다면 다른 노드를 비교 대상으로 남겨 두고 전체 구독 그룹을 삭제하지 마세요.

chapter three

구독 실패: 다운로드, 파싱 또는 덮어쓰기 문제 구분

구독 업데이트는 클라이언트가 구독 주소를 요청하고, 응답 내용을 받은 뒤, 응답을 노드로 파싱해 구독 그룹에 기록하는 세 단계로 이루어집니다. 화면에 “업데이트 실패”만 표시된다면 로그와 업데이트 결과를 통해 어느 단계에서 실패했는지 확인해야 합니다. 구독 주소에 요청할 수 없거나, 로그인 페이지가 반환되거나, 지원되지 않는 형식이거나, 그룹 필터가 노드를 숨겨도 최종적으로는 목록이 비어 있는 것처럼 보일 수 있습니다.

구독 주소가 완전하고 유형이 올바른지 먼저 확인

구독 링크를 복사할 때는 구독을 제공하는 관리 페이지에서 전체를 복사하고 쿼리 매개변수를 임의로 생략하지 마세요. 링크 끝의 token, 매개변수 또는 경로는 일반적으로 구독 식별에 사용되며 문자 하나만 빠져도 오류 페이지가 반환될 수 있습니다. v2rayN, v2rayNG 또는 v2flyNG에 붙여넣은 후 앞뒤에 큰따옴표, 줄바꿈, 공백 또는 메신저가 추가한 문장 부호가 섞이지 않았는지 확인하세요. QR 코드로 가져온 뒤에도 스캔 완료 여부만 확인하지 말고 구독 항목을 직접 확인해야 합니다.

구독 링크와 단일 노드 공유 링크는 용도가 다릅니다. 구독 링크는 여러 설정을 정기적으로 가져오는 데 사용하고, 단일 노드 링크는 일반적으로 프로토콜 이름으로 시작하며 하나의 설정만 나타냅니다. 단일 노드 링크를 구독 관리에 넣으면 클라이언트가 형식 오류를 표시할 수 있습니다. 반대로 구독 주소를 단일 노드로 가져와도 예상한 결과를 얻을 수 없습니다. 여러 기기로 이전할 때는 구독 링크, 설정 내보내기 및 QR 코드 이전 비교를 참고해 업데이트 필요에 맞는 방식을 선택하세요.

응답 현상으로 요청 단계 확인

업데이트할 때 로그의 HTTP 상태, 리디렉션, 시간 초과 또는 파싱 메시지를 확인하세요. 연결 시간 초과는 클라이언트가 아직 응답을 받지 못했다는 뜻이므로 현재 네트워크, 구독 도메인 확인 및 시스템 프록시 경로를 점검해야 합니다. 인증되지 않았거나 접근이 거부되면 유효한 구독 주소를 다시 받아야 하는 경우가 많습니다. 성공 응답이지만 파싱된 수가 0이면 응답 내용이 클라이언트가 지원하는 구독 형식이 아니거나 웹페이지 텍스트일 수 있습니다. 구독 주소에는 유효 기간이나 기기 규칙이 적용될 수 있으므로 만료된 경우 원래 서비스에서 새로 생성해야 하며, 로컬 노드 매개변수를 수정해 해결할 수 없습니다.

일반 네트워크에서 구독을 직접 요청할 수 있다면 먼저 “프록시를 통해 구독 업데이트”를 끄고 테스트하세요. 구독을 받으려면 프록시 연결이 반드시 필요하다면 이미 작동하는 기존 노드를 선택한 후 프록시 업데이트를 활성화합니다. 핵심은 순환 의존을 피하는 것입니다. 사용할 수 있는 노드가 없는데 구독 업데이트까지 프록시를 거치도록 하면 업데이트가 시작될 수 없습니다. 클라이언트마다 이 옵션의 이름은 조금씩 다르므로 구독 설정과 업데이트 로그를 기준으로 확인하세요.

업데이트는 성공했지만 노드가 보이지 않음

로그에 구독을 성공적으로 가져왔다고 표시되면 그룹, 필터 및 덮어쓰기 동작을 계속 확인하세요. 방금 업데이트한 구독 그룹으로 전환하고 이름 필터를 지운 뒤, 키워드로 노드를 포함하거나 제외하는 규칙이 활성화되어 있는지 확인합니다. 필터의 공백, 정규 표현식 또는 대소문자 차이 때문에 모든 노드가 숨겨질 수 있습니다. 클라이언트가 업데이트 시 이전 설정 삭제를 지원한다면 업데이트 결과가 비어 있을 때 기존 목록도 삭제될 수 있으므로, 구독 설정을 조정하기 전에 현재 사용 가능한 설정을 내보내세요.

같은 구독을 반복해서 추가하면 이름은 같지만 출처가 다른 그룹이 생겨 새 노드를 이전 그룹에서 찾기 쉽습니다. 유효한 항목 하나만 남기고 출처를 알아볼 수 있는 이름을 그룹에 지정한 뒤 전체 업데이트를 한 번 실행하는 것이 좋습니다. 구독 내용이 변경되면 현재 선택한 노드가 더 이상 존재하지 않을 수 있으므로 새 목록에서 다시 선택해 연결을 시작해야 합니다. 목록이 업데이트된 것만으로 실행 중인 코어가 새 설정으로 전환되었다고 볼 수는 없습니다.

가져온 후 노드는 존재하지만 모두 시간 초과된다면 구독 자체를 계속 확인하지 말고 이전 장으로 돌아가 네트워크와 노드 매개변수를 확인하세요. 일부 노드만 보이지 않는다면 클라이언트가 지원하는 프로토콜과 전송 유형을 대조합니다. 데스크톱에서는 우선 v2rayN을 사용하고, Android에서는 v2rayNG를 사용할 수 있습니다. v2fly 코어 생태계가 필요할 때 v2flyNG를 선택하세요. 클라이언트 다운로드 경로와 지원 플랫폼은 다운로드 센터를 기준으로 확인합니다.

업데이트 결과 가능한 단계 중점 확인 사항
요청 시간 초과 구독 다운로드 네트워크, DNS, 프록시 업데이트 옵션
인증되지 않은 응답 구독 접근 링크 유효성 및 전체 매개변수
파싱된 항목 수가 0 응답 내용 파싱 응답 형식, 웹페이지 리디렉션, 클라이언트 지원 여부
성공했지만 목록이 비어 있음 기록 및 표시 그룹, 필터, 덮어쓰기 설정

chapter four

속도 저하: 로컬 대역폭, 노드 및 라우팅 영향 분리

속도 저하는 웹페이지를 한 번 여는 데 걸린 시간만으로 판단할 수 없습니다. 첫 접속에는 DNS, TCP, TLS 및 콘텐츠 로딩이 포함되며 브라우저 캐시, 대상 사이트 부하와 로컬 무선 신호도 결과를 바꿉니다. 같은 기기, 같은 네트워크, 비슷한 시간대에 비교 조건을 만들어야 합니다. 프록시를 끄고 기본 네트워크를 측정한 뒤 프록시를 켜 여러 노드를 비교하고, 전역 모드와 분할 라우팅 모드도 비교하세요. 변수를 통제해야 병목이 로컬 네트워크, 노드 또는 규칙 중 어디에 있는지 확인할 수 있습니다.

재현 가능한 비교 테스트 만들기

먼저 대용량 파일 동기화, 시스템 업데이트, 클라우드 업로드 및 다른 기기의 고트래픽 작업을 중지하세요. 프록시를 끈 상태에서 고정된 테스트 대상의 다운로드, 업로드 및 응답 결과를 기록한 다음 프록시를 켜고 같은 대상으로 반복 테스트합니다. 각 상태에서 최소 두 번 실행하고 뚜렷하게 비정상적인 결과 하나는 제외하세요. 테스트 중에는 Wi-Fi 대역, 브라우저, 노드 및 DNS를 동시에 바꾸지 마세요. 그렇지 않으면 결과를 비교할 수 없습니다.

무선 네트워크에서는 신호 품질과 간섭을 특히 확인해야 합니다. 라우터 가까이에서 속도가 크게 회복된다면 프록시가 주요 병목이 아닐 가능성이 큽니다. 컴퓨터는 유선 네트워크로 비교하고, Android는 Wi-Fi와 모바일 네트워크 사이를 한 번 전환해 볼 수 있습니다. 모바일 네트워크로 바꾸면 주소와 라우팅도 달라지므로 현재 Wi-Fi에 이상이 있는지 판단하는 용도로만 사용하세요. 두 네트워크의 절대 속도를 노드 품질 차이로 바로 비교해서는 안 됩니다.

지연 시간 테스트와 실제 처리량을 올바르게 이해하기

지연 시간 테스트는 연결을 만들거나 특정 요청을 완료하는 데 걸린 시간을 나타내며 지속적인 다운로드 속도와는 다릅니다. 지연 시간이 짧은 노드도 대역폭이 제한될 수 있고, 지연 시간이 긴 노드도 대용량 파일 전송에서는 안정적일 수 있습니다. 실제 연결 테스트는 완전히 사용할 수 없는 노드를 걸러내는 데 도움이 되지만, 노드 선택은 대상 접속, 지속적인 전송 및 안정성을 함께 고려해야 합니다. 한 번의 순위만 보고 자주 전환하지 마세요. 연결을 반복해서 새로 만들면 대기 시간도 늘어납니다.

같은 구독에서 두세 개 노드를 선택해 테스트하세요. 모든 노드가 기본 네트워크보다 훨씬 느리다면 추가 체인 프록시, 지나치게 복잡한 라우팅 또는 적절하지 않은 전송 설정이 활성화되어 있는지 확인합니다. 특정 노드만 느리다면 우선 노드를 바꾸세요. 사용량이 많은 시간대에만 느리고 다른 시간에는 정상이라면 경로 또는 서버 부하 변화일 가능성이 높습니다. 로컬에서 클라이언트를 재설치해도 상위 경로의 용량은 바뀌지 않습니다.

분할 라우팅, 동시 처리 및 애플리케이션 프록시 방식 확인

전역 모드에서는 직접 연결할 수 있는 대용량 파일, 시스템 업데이트 및 로컬 네트워크 서비스까지 모든 요청이 프록시를 거칩니다. 이로 인해 노드 부하가 증가하고 로컬 네트워크 접근이 우회될 수 있습니다. 로컬 네트워크 우회 또는 적절한 분할 라우팅 모드로 돌아간 뒤, 로컬 주소, 프린터, 저장 장치 및 자주 직접 연결하는 도메인이 올바른 출구로 향하는지 확인하세요. 사용자 지정 규칙은 구체적인 항목부터 넓은 항목 순서로 배치해야 하며, 지나치게 넓은 프록시 규칙이 모든 트래픽을 먼저 가로채지 않도록 하세요. 규칙 문법과 우선순위는 domain, ip 및 geosite 라우팅 규칙 설명에서 확인할 수 있습니다.

브라우저 확장 프로그램, 다운로드 도구 및 개발 환경은 시스템 프록시를 사용하지 않고 별도의 SOCKS 또는 HTTP 포트를 설정할 수 있습니다. 포트 유형을 잘못 입력하면 일부 요청이 실패 후 재시도되어 속도가 느려질 수 있습니다. 애플리케이션 설정의 프로토콜 유형이 클라이언트 인바운드와 일치하는지 확인하고, SOCKS 프록시를 HTTP 프록시 입력란에 잘못 넣지 마세요. 명령줄 도구는 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY를 읽을 수도 있습니다. 이전 환경 변수가 현재 시스템 설정을 덮어쓸 수 있습니다.

특정 DNS 모드를 켠 뒤에만 느려진다면 DNS 서버 응답 지연, 잘못된 폴백 또는 도메인이 적절하지 않은 출구로 분류된 문제일 수 있습니다. 먼저 클라이언트의 기본 DNS 설정으로 되돌리고 코어를 재시작한 뒤 첫 요청과 이후 요청의 차이를 확인하세요. 첫 요청만 느리고 새로 고친 뒤 정상이라면 DNS 또는 연결 설정 문제에 가깝습니다. 지속적인 전송 속도가 낮다면 회선 대역폭, 노드 부하 또는 로컬 네트워크 품질 문제일 가능성이 큽니다.

chapter five

DNS 문제: 확인 결과부터 라우팅 출구까지 단계별 점검

DNS는 도메인을 연결 가능한 주소로 변환합니다. “IP로는 접속되지만 도메인은 열리지 않음”, “일부 도메인이 간헐적으로 실패함”, “연결 로그에 lookup error가 표시됨”과 같은 경우 DNS를 별도 단계로 확인해야 합니다. V2Ray 클라이언트는 시스템 확인을 사용할 수도 있고, 코어 설정으로 서버, 조회 정책 및 출구를 지정할 수도 있습니다. 시스템 DNS와 클라이언트 DNS를 동시에 변경하면 문제가 서로 겹치기 쉽습니다.

실제로 도메인 확인이 실패한 것인지 먼저 판단

프록시를 끈 상태와 켠 상태에서 같은 문제가 발생한 도메인을 각각 조회하고 주소가 반환되는지 확인하세요. Windows에서는 다음을 사용할 수 있습니다:

nslookup example.com

Linux 또는 macOS에서는 다음을 사용할 수 있습니다:

dig example.com
# 시스템에 dig가 없을 때
nslookup example.com

조회 결과가 있다고 해서 최종 연결까지 성공한다는 뜻은 아닙니다. 하지만 결과가 전혀 없거나 서버 오류가 반환되거나 오래 기다려야 한다면 DNS 경로를 계속 확인할 필요가 있습니다. 브라우저가 자체 암호화 DNS를 사용하면 시스템 명령과 다른 경로로 조회할 수 있으므로 브라우저 설정도 잠시 시스템 기본값으로 되돌린 뒤 비교하세요. 명령은 정상인데 특정 브라우저만 실패한다면 브라우저 캐시, 확장 프로그램 및 독립 DNS 설정을 우선 확인합니다.

캐시를 지우고 단일 제어 지점으로 되돌리기

도메인 레코드가 변경되면 시스템, 브라우저 및 클라이언트가 이전 캐시를 보관할 수 있습니다. Windows에서는 관리자 터미널에서 다음을 실행하세요:

ipconfig /flushdns

캐시를 지운 뒤 브라우저를 완전히 종료하고 클라이언트 코어를 재시작해야 합니다. Linux의 캐시 방식은 시스템 서비스에 따라 다르므로 먼저 systemd-resolved를 사용하는지 확인한 다음 다음을 실행할 수 있습니다:

resolvectl status
sudo resolvectl flush-caches

같은 문제 해결 과정에서 라우터 DNS, 시스템 DNS, 브라우저 DNS 및 클라이언트 DNS를 동시에 변경하지 마세요. 먼저 브라우저를 시스템 설정을 따르도록 되돌리고 클라이언트 DNS도 기본값으로 복원해 시스템 DNS 한 곳만 관찰 가능한 설정으로 남기는 것이 좋습니다. 기본 확인이 정상임을 확인한 뒤 클라이언트의 원격 확인, 도메인 정책 또는 분할 DNS를 하나씩 활성화하세요. 이렇게 하면 어느 계층에서 문제가 생겼는지 명확히 알 수 있습니다.

조회 정책과 출구의 관계 확인

설정의 domainStrategy는 라우팅 규칙이 언제 도메인 확인 결과를 사용할지 결정합니다. AsIs는 도메인을 유지해 매칭에 사용하는 경향이 있고, 다른 정책은 필요할 때 IP로 확인한 뒤 IP 규칙을 적용할 수 있습니다. 이는 단순한 “DNS 스위치”가 아니며 변경하면 라우팅 매칭에도 영향을 줍니다. 규칙이 geoip에 의존하는데 도메인이 IP로 확인되지 않으면 해당 규칙이 예상대로 작동하지 않을 수 있습니다. 반대로 너무 일찍 확인하면 도메인 규칙이 먼저 적용될 기회를 잃을 수 있습니다.

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

위 예시는 도메인을 유지하면서 사설 주소를 직접 연결 출구로 보내는 방식입니다. 실제 클라이언트는 그래픽 인터페이스에서 전체 설정을 생성할 수 있으므로 클라이언트가 관리하는 설정 파일을 직접 덮어쓰지 마세요. 사용자 지정이 필요하다면 현재 설정을 먼저 내보내 참고 자료로 삼고 관련 필드만 수정한 뒤, 코어를 재시작하고 생성 로그를 확인하세요. JSON의 쉼표, 따옴표 또는 계층 오류는 DNS 부분만이 아니라 전체 설정 로드를 실패하게 만들 수 있습니다.

DNS 조회 자체가 어느 출구를 사용하는지도 확인해야 합니다. 지정한 확인 서버가 특정 경로로만 접근 가능한데 DNS 요청이 다른 출구로 잘못 전달되면 “노드는 연결됐지만 도메인을 확인할 수 없음”이라는 현상이 나타날 수 있습니다. 먼저 클라이언트 기본 설정으로 검증한 뒤 필요에 따라 DNS 출구를 지정하세요. 로컬 네트워크 도메인, 기기 이름 및 내부 서비스는 일반적으로 로컬 확인에 의존합니다. 이를 모두 원격 DNS로 보내면 로컬 기기를 찾지 못할 수 있으므로 사설 도메인과 사설 주소에는 직접 연결 경로를 남겨 두세요.

증상 일반적인 원인 확인 방법
모든 도메인 실패 시스템 DNS를 사용할 수 없거나 DNS 출구가 잘못됨 시스템 및 클라이언트 상태를 각각 테스트
브라우저만 실패 브라우저 독립 DNS, 캐시 또는 확장 프로그램 시스템 DNS 복원 및 확장 프로그램 비활성화
로컬 네트워크 이름 작동 안 함 로컬 조회가 원격 확인으로 전달됨 사설 도메인에 로컬 경로 유지
첫 접속이 매우 느림 조회 시간 초과 후 폴백 로그에서 확인 소요 시간과 오류 확인

chapter six

시스템 프록시가 작동하지 않음: 적용 범위와 포트 일치 여부 확인

클라이언트에 “시스템 프록시가 켜짐”이라고 표시되는 것은 운영체제의 프록시 필드가 기록되었다는 뜻일 뿐, 모든 애플리케이션이 해당 필드를 따른다는 의미는 아닙니다. 브라우저는 일반적으로 시스템 프록시를 따르지만 일부 명령줄 도구, 스토어 앱, 게임 및 독립 네트워크 프로그램은 시스템 설정을 무시할 수 있습니다. 문제 해결 시 먼저 로컬 프록시 서비스가 정상인지 확인하고, 대상 애플리케이션이 어떤 프록시 방식을 사용하는지 확인한 뒤, 시스템 프록시 주소와 클라이언트 수신 포트가 일치하는지 점검하세요.

프록시 주소와 수신 포트 확인

v2rayN 설정에서 로컬 HTTP, SOCKS 또는 혼합 인바운드 포트를 확인한 다음 운영체제 프록시 설정을 열어 주소가 로컬 루프백 주소이고 포트가 클라이언트 표시와 일치하는지 확인하세요. 포트를 변경해도 기존 시스템 프록시 값이 항상 자동으로 동기화되는 것은 아닙니다. 시스템이 여전히 이전 포트를 가리키면 시스템 프록시를 먼저 끈 뒤 클라이언트 메뉴에서 다시 켜세요. 서버 포트를 시스템 프록시에 입력하지 마세요. 시스템 프록시는 원격 노드가 아니라 로컬 클라이언트에 연결됩니다.

Windows에서는 PowerShell로 현재 사용자 프록시 설정을 확인할 수 있습니다:

Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" |
  Select-Object ProxyEnable, ProxyServer, AutoConfigURL

ProxyEnable, ProxyServer 및 자동 구성 주소가 동시에 존재할 수 있습니다. 이전에 프록시 스크립트를 사용했다면 AutoConfigURL이 애플리케이션 동작에 계속 영향을 줄 수 있습니다. 먼저 기존 값을 기록한 후 시스템 설정에서 더 이상 사용하지 않는 자동 구성을 끄세요. 내용을 모르는 기업 또는 조직 정책을 직접 삭제하지 마세요. 관리되는 기기라면 먼저 네트워크 정책 요구 사항을 확인해야 합니다.

시스템 프록시, TUN 및 애플리케이션 독립 프록시 구분

시스템 프록시는 주로 운영체제 프록시 설정을 읽는 애플리케이션에 영향을 줍니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 트래픽을 가로채며, 두 기능은 같은 스위치가 아닙니다. 문제가 명확하지 않은 상태에서 두 기능을 번갈아 반복해서 전환하지 마세요. 브라우저는 작동하지만 특정 애플리케이션만 작동하지 않는다면 해당 애플리케이션이 시스템 프록시를 지원하는지 먼저 확인하세요. 애플리케이션에 HTTP 또는 SOCKS 설정이 있다면 클라이언트 인바운드 유형에 맞춰 로컬 주소와 포트를 직접 입력합니다. 애플리케이션이 프록시를 전혀 지원하지 않을 때만 TUN이 필요한지 검토하고, 시스템 프록시 문제를 곧바로 전체 설정 변경으로 확대하지 마세요.

명령줄 도구에는 일반적으로 독립 설정이 있습니다. 임시 환경 변수의 경우 HTTP 프록시와 SOCKS 프록시의 형식이 다릅니다:

# HTTP 프록시 예시
set HTTPS_PROXY=http://127.0.0.1:10809

# PowerShell 현재 세션
$env:HTTPS_PROXY="http://127.0.0.1:10809"

포트는 작성 형식만 보여 주는 예시이므로 반드시 클라이언트의 실제 HTTP 인바운드 포트로 바꿔야 합니다. 환경 변수는 현재 세션 또는 그 하위 프로세스에만 적용되며, 영구 변수는 클라이언트 종료 후에도 남아 있을 수 있습니다. 문제 해결이 끝나면 더 이상 필요하지 않은 변수를 삭제해 “시스템 프록시는 껐지만 명령줄은 계속 이전 포트를 사용함”과 같은 상황을 방지하세요.

프록시 잔여 설정과 로컬 네트워크 예외 처리

클라이언트의 비정상 종료, 시스템 업데이트 또는 계정 전환 후 프록시 필드가 남아 있을 수 있습니다. 대표적인 증상은 트레이에 클라이언트가 없는데도 브라우저에서 프록시 서버가 연결을 거부한다고 표시되는 경우입니다. 이때 시스템 설정에서 프록시를 수동으로 끄고 클라이언트를 다시 시작한 뒤, 코어가 수신 중인지 확인하고 다시 켜세요. 클라이언트를 재시작해도 잘못된 포트가 자동으로 기록된다면 설정의 로컬 포트가 중복되었는지, 여러 v2rayN 인스턴스가 동시에 실행 중인지 확인하세요.

로컬 네트워크 접근에 문제가 있으면 프록시 예외와 라우팅 규칙을 확인하세요. 루프백 주소, 사설 네트워크 대역 및 로컬 도메인은 일반적으로 직접 연결해야 합니다. 프록시 우회 목록은 시스템 설정을 따르는 애플리케이션에만 영향을 주지만, V2Ray 코어의 라우팅 규칙은 코어에 들어온 요청이 어느 출구로 나갈지 결정합니다. 두 설정은 서로 다른 계층이므로 한쪽만 수정해서는 모든 애플리케이션 문제가 해결되지 않을 수 있습니다. 먼저 IP로 로컬 기기에 접속한 다음 기기 이름으로 접속하세요. IP는 정상이고 이름만 실패한다면 DNS 장으로 돌아가 로컬 확인을 처리합니다.

한 브라우저는 정상이고 다른 브라우저만 실패한다면 두 브라우저가 모두 시스템 프록시를 사용하는지 비교하세요. 확장 프로그램이 프록시를 강제로 지정하거나 자동 구성 스크립트 또는 직접 연결 모드를 적용할 수 있습니다. 확장 프로그램을 하나씩 추측하기보다 확장 프로그램을 로드하지 않는 임시 브라우저 프로필을 만들어 테스트하는 편이 빠릅니다. 시스템 프록시를 따르는 모든 애플리케이션이 실패한다면 포트 수신 상태와 코어 로그로 돌아가세요. 특정 애플리케이션 하나만 실패한다면 대개 해당 애플리케이션 자체의 설정 문제입니다.

chapter seven

클라이언트 충돌: 로그를 보존하고 실행 조건 줄이기

클라이언트가 시작되지 않거나, 실행 직후 종료되거나, 설정을 가져올 때 멈추거나, 일정 시간 후 충돌한다면 먼저 그래픽 인터페이스와 코어 프로세스를 구분해야 합니다. 인터페이스가 종료되었다고 코어도 반드시 중지된 것은 아니며, 코어 오류가 반드시 인터페이스 충돌로 이어지는 것도 아닙니다. 처리 전에 문제를 일으킨 동작, 로그 경로 및 시스템 환경을 기록한 뒤 최소 설정으로 시작하고 구독, 라우팅 및 추가 기능을 단계적으로 복원하세요.

인터페이스 종료인지 코어 실패인지 확인

먼저 트레이와 작업 관리자를 확인하세요. v2rayN 기본 창을 닫아도 트레이에 계속 남아 있을 수 있습니다. 실제 충돌이라면 인터페이스 프로세스가 사라지고 시스템 이벤트 기록에 애플리케이션 오류가 남을 수 있습니다. 인터페이스는 실행 중이지만 노드에 연결할 수 없다면 클라이언트 실행 로그를 확인하세요. 코어 시작 또는 설정 로드 실패에 더 가까운 문제일 수 있습니다. 인터페이스 자체가 전혀 나타나지 않는다면 애플리케이션 로그, 시스템 이벤트, 실행 디렉터리 권한 및 의존 환경을 확인하세요.

Windows에서는 “이벤트 뷰어”를 열고 Windows 로그의 애플리케이션 항목에서 오류가 발생한 시간대의 기록을 찾을 수 있습니다. Linux 데스크톱에서는 터미널에서 애플리케이션을 실행해 표준 출력을 확인하고 현재 사용자 서비스 로그도 살펴보세요. 사용자 수준 자동 시작을 설정했다면 다음을 실행할 수 있습니다:

systemctl --user status v2rayn
journalctl --user -u v2rayn --since today

서비스 이름은 실제로 생성된 유닛을 기준으로 해야 합니다. Linux 설치 및 사용자 수준 자동 시작 절차는 v2rayN Linux 데스크톱 버전 설치 튜토리얼을 참고하세요. macOS에서 시작할 수 없다면 애플리케이션이 안정적인 디렉터리에 있는지, 현재 계정이 설정 디렉터리를 읽을 수 있는지 확인하고 시스템 로그에서 시작 시간에 해당하는 오류를 찾으세요.

빈 설정으로 기본 시작 확인

설정 파일을 조작하기 전에 클라이언트와 관련 코어 프로세스를 종료하고 설정 디렉터리를 백업하세요. 유일한 설정을 바로 삭제하지 마세요. 기존 설정 디렉터리의 이름을 바꾸면 클라이언트가 새 기본 설정을 생성합니다. 빈 설정으로 시작할 수 있다면 프로그램 자체는 실행 가능하다는 뜻이며, 문제는 대개 이전 설정, 구독 데이터, 라우팅 규칙 또는 인터페이스 상태에 있습니다. 이후 이전 디렉터리 전체를 한 번에 복사하지 말고 구독, 라우팅, 사용자 지정 DNS, 인터페이스 설정 순서로 하나씩 복원하세요.

특정 설정을 가져온 직후 충돌한다면 백업에서 최근에 수정한 구독 또는 노드를 찾아보세요. 지나치게 긴 노드 이름, 손상된 JSON, 잘못된 인코딩 및 불완전한 가져오기 데이터가 파싱 문제를 일으킬 수 있습니다. JSON을 수동 편집할 때는 UTF-8을 지원하는 텍스트 편집기를 사용하고 먼저 기본 문법을 확인하세요. 다음 명령은 Python이 설치된 데스크톱 시스템에서 JSON을 파싱할 수 있는지 확인합니다:

python -m json.tool config.json

이 명령은 JSON 문법만 확인하며 V2Ray 필드가 클라이언트 요구 사항에 맞는지는 검증하지 않습니다. 문법을 통과한 뒤에도 로그를 바탕으로 아웃바운드 태그, 라우팅 참조, DNS 서버 및 프로토콜 필드를 확인해야 합니다. 클라이언트가 자동 생성하는 파일은 종료 시 덮어써질 수 있으므로 클라이언트 실행 중에 직접 편집하지 마세요.

권한, 파일 점유 및 리소스 부담 확인

애플리케이션 또는 설정 디렉터리에 쓰기 권한이 없으면 클라이언트가 설정 저장, 구독 업데이트 또는 실행 파일 압축 해제를 수행하지 못할 수 있습니다. 현재 사용자가 정상적으로 읽고 쓸 수 있는 위치에 애플리케이션을 두고 압축 파일 미리보기에서 직접 실행하지 마세요. 기업 기기, 보호된 디렉터리 및 동기화 드라이브에는 추가 권한이나 파일 잠금이 적용될 수 있으므로 테스트할 때 일반 사용자 디렉터리로 옮겨 보세요. 디렉터리 문제를 관리자 권한으로 장기간 숨기지 말고 실제로 어떤 파일에 쓰기가 필요한지 먼저 확인하세요.

보안 소프트웨어가 새 프로세스 시작, 로컬 수신 또는 실행 파일을 차단할 수 있습니다. 시스템 기록에서 명확한 차단 이벤트가 있는지 확인한 뒤 조직 정책에 따라 처리하세요. 모든 보호 기능을 무작정 끄면 안정적인 결론을 얻을 수 없고 실제 포트 또는 권한 오류를 가릴 수도 있습니다. 시스템 기록에 차단이 없다면 포트 점유, 설정 파싱 및 의존성 오류를 계속 확인하세요.

노드와 구독 수가 많으면 시작 시 파싱, 인터페이스 렌더링 및 지연 시간 테스트로 리소스 사용량이 증가합니다. 먼저 자동 테스트를 끄고 중복 구독을 정리하며 필터 범위를 줄이세요. 일괄 테스트 중에만 충돌한다면 동시 작업 수를 줄입니다. 일정 시간 실행한 뒤 메모리 사용량이 계속 증가한다면 문제를 일으킨 동작과 리소스 변화를 기록한 후 현재 플랫폼용 클라이언트를 다시 받아 덮어 설치하세요. 덮어 설치 전에 설정을 백업하고, 설치 후에는 먼저 기본 설정으로 시작한 다음 필요한 내용만 가져오세요.

chapter eight

모바일 문제: Android 백그라운드, VPN 및 네트워크 전환

Android의 v2rayNG와 v2flyNG는 일반적으로 시스템 VPN 인터페이스를 통해 애플리케이션 트래픽을 가로챕니다. 모바일 문제는 노드와 구독뿐 아니라 배터리 절전 정책, 백그라운드 제한, 항상 켜진 VPN, 비공개 DNS, Wi-Fi와 모바일 네트워크 전환의 영향도 받습니다. 문제 해결 순서는 기본 네트워크부터 시작하되, 시스템이 클라이언트를 백그라운드에서 계속 실행하도록 허용하는지와 현재 VPN 인터페이스를 다른 애플리케이션이 사용 중인지도 추가로 확인해야 합니다.

시스템 VPN 인터페이스와 기본 네트워크 확인

먼저 클라이언트 연결을 중지하고 현재 Wi-Fi 또는 모바일 네트워크에서 브라우저로 일반 웹페이지에 정상 접속할 수 있는지 확인하세요. 그런 다음 v2rayNG 또는 v2flyNG를 실행해 시스템 VPN 연결 요청을 승인하고 상태 표시줄에 VPN 표시가 나타나는지 확인합니다. 시스템에 이미 VPN이 실행 중이라는 메시지가 표시되면 VPN 인터페이스를 사용하는 다른 애플리케이션을 먼저 종료하세요. Android에서는 동일한 사용자 공간에 일반적으로 하나의 주요 VPN 인터페이스만 유지할 수 있으므로 여러 애플리케이션이 동시에 제어할 수 없습니다.

연결 버튼에는 시작됨으로 표시되지만 상태 표시줄에 VPN 표시가 없다면 시스템이 권한을 철회했거나 인터페이스 생성 중 클라이언트가 즉시 오류를 냈는지 확인하세요. 시스템 VPN 설정에서 “항상 켜진 VPN”과 “VPN을 사용하지 않는 연결 차단” 옵션을 확인합니다. 이 옵션이 다른 애플리케이션에 연결되어 있으면 현재 클라이언트가 정상 작동하지 않을 수 있습니다. 현재 클라이언트에 연결되어 있지만 노드를 사용할 수 없다면 직접 연결 차단 때문에 모든 네트워크가 끊긴 것처럼 보일 수 있습니다. 문제 해결 중에는 강제 옵션을 잠시 끄고 기본 연결을 확인한 뒤 필요에 따라 다시 활성화하세요.

백그라운드 종료와 화면 잠금 후 연결 끊김 처리

앞에서는 정상적으로 사용되지만 화면을 잠근 뒤 몇 분 후 연결이 끊긴다면 배터리 최적화와 백그라운드 활동 제한을 우선 확인하세요. 현재 클라이언트를 제한 없음 또는 백그라운드 실행 허용 범위에 추가하고 필요한 전면 서비스 알림을 허용합니다. 기기마다 백그라운드 정책 이름은 다르지만 판단 방법은 같습니다. 화면을 켜 두면 연결이 안정적이고 화면을 잠그면 프로세스나 VPN 표시가 사라진다면 노드 문제보다 시스템 회수 가능성이 큽니다.

일부 시스템은 애플리케이션별로 백그라운드 데이터를 제한하기도 합니다. 클라이언트가 Wi-Fi, 모바일 데이터 및 백그라운드 데이터를 사용할 수 있는지 확인하세요. 모바일 네트워크에서만 실패한다면 해당 애플리케이션의 모바일 데이터 권한이 꺼져 있는지 확인합니다. 데이터 절약 모드는 백그라운드 연결을 제한할 수 있으므로 테스트 중에는 클라이언트를 제한 없이 허용해 보세요. 조정 후에는 최근 앱 화면에서 클라이언트를 밀어 닫고 다시 열어 새 프로세스에 시스템 정책이 적용되도록 하세요.

여러 “자동 시작” 또는 “백그라운드 보호” 도구를 동시에 켜 시스템 상태를 반복해서 변경하는 것은 권장하지 않습니다. 먼저 시스템 배터리 및 데이터 권한만 조정하고 일정 시간 관찰하세요. 문제가 사라지면 다른 제한을 하나씩 복원합니다. 연결 로그의 EOF, network changed 또는 인터페이스 종료 메시지를 VPN 표시가 사라진 시점과 함께 보면 네트워크 전환, 시스템 회수 또는 원격 측의 능동적 연결 종료를 구분하는 데 도움이 됩니다.

비공개 DNS, 애플리케이션별 프록시 및 네트워크 전환 확인

Android의 비공개 DNS는 시스템 네트워크 설정에 있으며 클라이언트 내부 DNS와는 다른 계층입니다. 도메인을 확인할 수 없다면 비공개 DNS를 잠시 자동으로 설정하고 클라이언트 DNS도 기본값으로 되돌린 뒤 다시 연결하세요. 정상으로 돌아오면 두 설정 중 하나만 다시 활성화해 원인을 확인합니다. 비공개 DNS 호스트 이름 자체를 확인하거나 연결할 수 없으면 시스템이 클라이언트 VPN을 만들기 전부터 도메인 문제가 발생할 수 있습니다.

애플리케이션별 프록시는 어떤 애플리케이션을 VPN에 포함할지 지정합니다. 브라우저는 정상인데 대상 애플리케이션만 연결되지 않는다면 해당 애플리케이션이 포함 목록에 있는지, 제외되지 않았는지 먼저 확인하세요. 규칙 모드를 전환한 뒤에도 일부 기존 연결은 이전 네트워크를 계속 사용할 수 있으므로 대상 애플리케이션을 완전히 종료한 후 다시 열어야 합니다. 시스템 구성 요소, 다운로드 서비스 및 애플리케이션 주 프로세스가 서로 다른 프로세스로 요청을 처리할 수 있으므로 화면에 보이는 애플리케이션만 선택해도 모든 트래픽이 포함되지 않을 수 있습니다. 문제 해결 중에는 일시적으로 모든 애플리케이션을 VPN에 포함해 확인한 뒤 범위를 줄이세요.

Wi-Fi와 모바일 네트워크를 전환하면 기본 연결도 변경됩니다. 전환 후에는 클라이언트가 세션을 다시 만들어야 하므로 잠시 중단되는 것은 연결 재구성 과정일 수 있습니다. 장시간 복구되지 않으면 연결을 수동으로 중지하고 다시 시작하세요. 특정 Wi-Fi에서만 실패한다면 해당 네트워크의 인증 페이지, DNS 및 라우팅을 확인합니다. 모바일 네트워크에서만 실패한다면 클라이언트 데이터 권한, 네트워크 유형 및 대상 주소 접근 가능성을 확인하세요. 네트워크 전환 전후의 테스트 결과를 섞어 비교하지 마세요.

모바일 문제 증상 우선 확인 처리 방향
화면 잠금 후 연결 끊김 배터리 최적화, 백그라운드 제한 백그라운드 및 전면 서비스 실행 허용
VPN을 만들 수 없음 다른 VPN 애플리케이션, 시스템 권한 인터페이스 해제 후 권한 재승인
일부 애플리케이션만 실패 애플리케이션별 프록시 목록 일시적으로 모든 애플리케이션으로 테스트
네트워크 전환 후 복구되지 않음 이전 세션과 기본 네트워크 변경 중지 후 연결 다시 설정
도메인은 실패하지만 연결은 유지됨 비공개 DNS와 클라이언트 DNS DNS 제어 지점을 하나로 복원

이 장을 완료한 뒤에도 원인을 판단하기 어렵다면 문제 해결에서 문제 유형별 짧은 답변을 찾아보세요. 다시 설정해야 한다면 빠른 시작 튜토리얼에 따라 구독 가져오기, 노드 선택 및 연결 확인을 처음부터 진행하세요. 기존 설정에 검증되지 않은 변경을 계속 덧붙이지 마세요.