V2Ray 문제 해결 총정리

1. 재현 가능한 진단 기준선 세우기

원인을 추측하기 전에 현상을 기록하세요

효율적인 문제 해결은 재현 가능한 경로를 기록하는 것에서 시작합니다. 먼저 현재 클라이언트, 선택한 노드, 시스템 프록시 모드, 라우팅 모드, 발생 시각, 오류가 발생한 애플리케이션을 적고, ‘모든 사이트가 열리지 않음’, ‘특정 도메인만 실패’, ‘브라우저는 정상인데 다른 앱만 실패’, ‘연결은 되지만 속도가 눈에 띄게 느림’처럼 현상을 구분하세요. 노드 이름만으로 노드의 정상 작동을 입증할 수 없으며, 목록에 표시된 지연 시간도 전체 연결 테스트를 대신할 수 없습니다. 이전에 작동했던 노드나 설정을 하나 남겨 비교 대상으로 활용하는 것이 좋습니다. 같은 네트워크에서 새 설정과 이전 설정의 결과가 다르면 문제 범위를 노드 매개변수나 라우팅 규칙으로 빠르게 좁힐 수 있습니다.

그다음 최소 조건으로 테스트하세요. 다른 프록시 클라이언트, 브라우저 프록시 확장 프로그램, 패킷 캡처 도구, 임시 네트워크 가속 기능을 끄고 V2Ray 클라이언트 하나만 실행합니다. 사용자 지정 라우팅 규칙은 잠시 중지하고 클라이언트의 기본 프록시 모드로 전환하세요. 노드를 하나 선택한 뒤에는 그대로 유지합니다. 데스크톱에서는 TLS 인증서 검증이 시스템 시간에 의존하므로 시스템 시간, 시간대, 날짜도 정확한지 확인해야 합니다. 모바일 네트워크와 Wi-Fi는 외부 연결 조건이 다르므로 어떤 네트워크를 사용 중인지 명확히 기록하고, 네트워크를 바꾼 뒤 결과를 이전 설정의 문제로 잘못 해석하지 않도록 하세요.

계층별로 장애 위치 판단하기

하나의 요청은 대략 애플리케이션, 시스템 프록시 또는 가상 네트워크 인터페이스, 로컬 인바운드, 라우팅과 DNS, 원격 노드, 대상 서버를 거칩니다. 브라우저 요청이 클라이언트 로그에 전혀 나타나지 않으면 먼저 애플리케이션과 시스템 프록시를 확인하세요. 노드 연결 시간 초과가 로그에 나타나면 로컬 네트워크에서 노드까지의 경로를 중점적으로 봅니다. 노드 핸드셰이크는 성공했지만 대상 도메인 조회가 실패하면 DNS를 확인하고, 특정 도메인 그룹만 잘못된 출구로 나가면 라우팅 매칭 순서를 점검합니다. 이렇게 계층을 나누는 편이 클라이언트를 반복해서 재설치하는 것보다 효과적이며, 서로 다른 문제를 하나로 섞는 것도 막아 줍니다.

로그와 로컬 리스닝 증거 저장

로그는 ‘클라이언트 시작 → 노드 선택 → 실패하는 요청 1회 실행 → 테스트 중지’의 전체 과정을 포함해야 합니다. 마지막 한 줄만 캡처하지 마세요. 실제 원인은 앞부분의 설정 로드나 인바운드 리스닝 단계에 나타나는 경우가 많습니다. v2rayN에서는 메인 창의 로그 영역과 코어 로그를 확인할 수 있고, v2rayNG와 v2flyNG에서는 로그 페이지에서 연결, 라우팅, 오류 정보를 확인할 수 있습니다. 로그를 공유하기 전에는 구독 주소, 노드 인증 정보, 사용자 식별자, 전체 서버 주소를 삭제하고 오류 유형, 발생 순서, 필요한 매개변수만 남기세요.

데스크톱에서는 로컬 프록시 포트가 리스닝 중인지 확인할 수 있습니다. 아래 명령은 로컬 컴퓨터의 포트만 확인하며 원격 노드는 검증하지 않습니다. 포트 번호는 클라이언트 설정에 실제로 표시된 SOCKS 또는 HTTP 포트로 바꿔야 합니다.

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

포트가 리스닝 중이 아니라면 문제는 아직 클라이언트 시작, 포트 충돌, 코어 로드 단계에 있습니다. 명시적 프록시를 사용하는 명령은 성공하지만 브라우저가 접속하지 못한다면 대개 시스템 프록시나 애플리케이션 프록시 계층의 문제입니다. 명시적 프록시도 실패한다면 노드와 DNS를 확인하세요. 이 과정을 마치면 ‘로컬 HTTP 포트는 정상적으로 리스닝 중이고 브라우저 요청은 로그에 들어오지만 노드 주소 연결이 시간 초과됨’처럼 짧은 결론을 작성할 수 있어야 합니다. 이런 결론이 다음 점검의 출발점이지, 막연한 ‘V2Ray이 작동하지 않음’이 아닙니다.

2. 프록시를 시작해도 인터넷이 되지 않음

로컬 단절과 프록시 경로 실패 구분하기

‘연결 후 인터넷이 되지 않음’은 보통 두 가지 경우로 나뉩니다. 첫째, 시스템 프록시는 클라이언트를 가리키지만 클라이언트의 로컬 인바운드가 정상적으로 리스닝하지 않아 시스템 프록시를 따르는 모든 앱이 즉시 실패하는 경우입니다. 둘째, 로컬 인바운드는 정상이고 트래픽도 코어에 들어왔지만 원격 노드, 라우팅, DNS가 요청을 완료하지 못하는 경우입니다. 웹 페이지에 접속할 때 클라이언트 로그에 새 기록이 전혀 없으면 트래픽이 클라이언트에 들어오지 않은 것입니다. 대상 도메인과 아웃바운드 기록이 나타나면 시스템 프록시가 적어도 요청을 로컬 코어로 전달한 것입니다.

먼저 시스템 프록시를 끄고 클라이언트를 종료한 뒤 직접 연결 자체가 정상인지 확인하세요. 직접 연결로도 자주 사용하는 사이트에 접속할 수 없다면 Wi-Fi, 네트워크 카드, 게이트웨이, 로컬 DNS부터 복구하고 노드 설정은 계속 수정하지 마세요. 직접 연결이 복구되면 클라이언트를 시작하되 시스템 프록시는 아직 켜지 말고 코어에 시작 오류가 없는지 확인합니다. 마지막으로 시스템 프록시를 켜고 고정된 테스트 페이지에 접속하세요. 이 순서로 원래 네트워크, 코어 시작, 프록시 전환 이후 중 어느 단계에서 문제가 발생하는지 판단할 수 있습니다.

포트, 모드, 프로세스 확인하기

v2rayN의 HTTP, SOCKS, LAN 리스닝은 서로 다른 설정입니다. 시스템 프록시는 현재 실제로 리스닝 중인 HTTP 포트를 가리켜야 하며 다른 기기나 이전 설정의 포트를 그대로 사용하면 안 됩니다. 포트를 다른 프로그램이 사용 중이면 코어 시작이 실패하거나 자동으로 포트가 바뀌어 시스템 프록시 기록과 불일치할 수 있습니다. 로그에서 address already in use, bind failed, listen failed와 같은 메시지를 확인하세요. 충돌이 발견되면 해당 프로그램을 종료하거나 클라이언트에서 사용하지 않는 포트로 바꾼 뒤 시스템 프록시를 다시 설정합니다.

브라우저는 웹 페이지를 열 수 있지만 명령줄 도구는 실패한다고 해서 반드시 노드 문제인 것은 아닙니다. 많은 명령줄 프로그램은 데스크톱 시스템 프록시를 자동으로 읽지 않으므로 프록시 매개변수나 해당 환경 변수를 별도로 설정해야 합니다. 반대로 일부 앱은 자체 수동 프록시 주소를 저장해 시스템 프록시를 꺼도 이전 포트에 계속 연결할 수 있습니다. 점검할 때는 앱 내부 네트워크 설정에서 ‘시스템 설정 따르기’, ‘수동 HTTP’, ‘수동 SOCKS’, ‘직접 연결’을 구분하세요. 같은 프록시 진입점을 사용해야 테스트 결과를 비교할 수 있습니다.

가장 단순한 라우팅 설정으로 돌아가기

복잡한 분할 라우팅 규칙은 DNS, 노드 도메인, 대상 요청을 잘못된 아웃바운드로 보낼 수 있습니다. 사용자 지정 규칙 세트를 잠시 비활성화하고 기본 전체 프록시 모드로 비교하세요. 전체 모드에서 복구된다면 노드 경로는 정상일 가능성이 높고 문제는 규칙 매칭에 있습니다. 전체 모드에서도 실패하면 노드 매개변수와 DNS를 계속 확인하세요. 분할 라우팅을 복구할 때는 명확한 규칙 몇 개부터 시작해 사설 주소와 로컬 네트워크를 먼저 직접 연결로 지정하고, 확실한 도메인 규칙을 추가한 뒤 마지막에 기본 아웃바운드를 설정하세요. 규칙은 일반적으로 순서대로 매칭되므로 앞의 포괄적인 규칙이 뒤의 정밀한 규칙을 가릴 수 있습니다.

아웃바운드 태그가 실제로 존재하는지도 확인해야 합니다. 규칙에서 참조하는 태그와 현재 설정의 프록시, 직접 연결, 차단 아웃바운드 태그는 대소문자와 철자를 포함해 완전히 일치해야 합니다. 구독을 업데이트하면 클라이언트가 관리하는 아웃바운드 구조가 바뀔 수 있으므로 다른 전체 설정의 태그를 현재 클라이언트에 기계적으로 복사하지 마세요. 코어 로그에 outbound를 찾을 수 없음, invalid field, 설정 파싱 오류가 명확히 표시되면 먼저 클라이언트가 생성한 기본 설정으로 복구한 다음 사용자 지정 항목을 하나씩 추가하세요.

네트워크 상태 복구하기

클라이언트가 비정상 종료된 뒤 시스템 프록시가 로컬 주소로 남아 있고 해당 포트를 아무도 리스닝하지 않으면 브라우저에서 모든 연결이 끊긴 것처럼 보입니다. 클라이언트를 다시 열어 ‘시스템 프록시 지우기’를 실행하거나 시스템 네트워크 설정에서 수동 프록시를 끈 뒤 직접 연결을 다시 테스트하세요. 가상 네트워크 모드를 사용했다면 해당 모드도 정상적으로 중지해 라우팅 테이블과 DNS 설정을 복구해야 합니다. 프로세스만 강제 종료하면 임시 네트워크 상태가 남을 수 있습니다. 복구 후 클라이언트를 다시 시작하고 직접 연결, 명시적 로컬 프록시, 시스템 프록시 순서로 확인하세요.

로컬 네트워크 리소스만 접속할 수 없다면 사설 대역이 프록시로 전송되는지 확인하세요. 가정용 라우터, 프린터, 저장 장치, 사내 서비스는 대개 사설 주소를 사용하므로 직접 연결 아웃바운드로 처리해야 합니다. 사설 주소 규칙을 기본 프록시 규칙보다 앞에 배치하고, 가상 네트워크 모드가 LAN 검색 트래픽을 원격으로 잘못 보내지 않는지 확인하세요. 특정 사이트 하나만 실패한다면 브라우저 시크릿 창에서 캐시와 확장 프로그램의 영향을 배제하고 로그에서 해당 도메인이 최종적으로 어떤 아웃바운드에 매칭됐는지 확인하세요. 이렇게 점검하면 ‘인터넷이 안 됨’을 포트, 규칙, DNS, 노드 문제로 구체화할 수 있습니다.

3. 노드 시간 초과와 핸드셰이크 실패

시간 초과·거부·핸드셰이크 오류 이해하기

노드 목록에 시간 초과가 표시된다는 것은 제한 시간 안에 테스트 요청이 완료되지 않았다는 뜻일 뿐, 서버를 영구적으로 사용할 수 없다는 의미는 아닙니다. 연결 시간 초과는 보통 노드 주소와 포트까지 TCP 또는 UDP 경로가 제때 설정되지 않았음을 나타냅니다. 연결 거부는 대상 주소에는 도달했지만 해당 포트에서 연결을 받아 주는 서비스가 없다는 뜻입니다. 연결 재설정은 경로가 설정된 뒤 어느 한쪽이 연결을 능동적으로 끊었다는 의미입니다. TLS 핸드셰이크 오류라면 서버 이름, 전송 계층, 보안 매개변수, 시스템 시간을 추가로 확인해야 합니다. 오류마다 가리키는 계층이 다르므로 모두 ‘노드가 죽었다’고 단정할 수 없습니다.

먼저 같은 구독의 노드 두 개를 실제로 연결해 비교하세요. 현재 네트워크에서 모든 노드가 동시에 시간 초과되고 다른 네트워크에서는 복구된다면 로컬 네트워크 외부 연결, 방화벽, 라우팅 경로를 우선 확인합니다. 노드 하나만 시간 초과되고 다른 노드는 정상이라면 해당 노드의 주소, 포트, 원격 서비스 문제일 가능성이 높습니다. 같은 노드가 여러 기기와 다른 네트워크에서 모두 실패한다면 클라이언트 설정을 계속 바꾸기보다 설정 제공자에게 노드 상태와 매개변수를 확인하는 편이 직접적입니다.

노드 매개변수 하나씩 확인하기

노드를 수동으로 가져올 때는 주소, 포트, 사용자 식별자, 프로토콜, 보안 계층, 전송 방식, 서버 이름, 경로가 한 세트로 일치해야 합니다. VLESS와 VMess 같은 프로토콜의 필드를 서로 바꿔 사용할 수 없으며, WebSocket, gRPC, TCP 등 전송 방식마다 경로, 서비스 이름, 요청 헤더가 다릅니다. 가장 흔한 문제는 필드가 빠진 것이 아니라 이전 노드에서 설정을 복사한 뒤 주소와 포트만 바꾸고 서버 이름이나 전송 매개변수를 그대로 둔 경우입니다. 클라이언트 편집 화면과 원본 설정을 필드별로 대조하고 노드 이름에 의존하지 마세요.

TLS를 활성화하면 서버 이름은 일반적으로 인증서 검증과 핸드셰이크에 사용되므로 노드 IP로 임의 변경하면 안 됩니다. 시스템 시간 오차가 크면 인증서가 아직 유효하지 않거나 이미 만료된 것으로 잘못 판단할 수 있습니다. 로그에 certificate, handshake, server name, verify failed가 나타나면 먼저 시스템 시간을 맞춘 다음 서버 이름과 보안 설정을 확인하세요. 필수 검증을 꺼서 매개변수 불일치를 숨기지 마세요. 올바른 해결 방법은 서버 측과 일치하는 설정을 확보하는 것입니다. REALITY 같은 보안 방식을 사용한다면 공개 키, 짧은 식별자, 서버 이름, 흐름 제어 매개변수도 일치해야 합니다.

지연 시간 테스트만으로 사용 가능 여부를 판단할 수 없습니다

ICMP ping, TCP 연결, 프록시 핸드셰이크, 다운로드 속도 측정은 서로 다른 단계를 측정합니다. 서버가 ping에는 응답하지 않아도 프록시 포트는 정상일 수 있습니다. TCP 포트 연결은 되지만 프로토콜 인증이 실패할 수도 있고, 실제 연결 지연 시간은 짧아도 지속 전송 대역폭은 제한적일 수 있습니다. 따라서 노드를 선택할 때는 먼저 클라이언트의 실제 연결 테스트로 프록시 핸드셰이크를 확인한 뒤 실제 웹 페이지와 파일 전송으로 안정성을 검증하세요. 세 테스트의 차이는 V2Ray 지연 시간 테스트 원리에서 더 확인할 수 있습니다.

테스트할 때는 동시 실행 수를 과도하게 늘리지 마세요. 많은 노드를 한꺼번에 측정하면 로컬 연결, DNS 조회, 네트워크 외부 연결을 점유하고, 일부 라우터는 짧은 시간에 생성되는 대량의 새 연결을 제한할 수 있어 전체 노드가 시간 초과될 수 있습니다. 적은 수의 노드를 순서대로 테스트하고 이전 연결이 해제된 뒤 결과를 비교하세요. 모바일 네트워크에서는 신호 전환, 백그라운드 절전, 네트워크 유형 변화가 짧은 테스트를 왜곡할 수 있으므로 네트워크가 안정된 뒤 다시 측정해야 합니다.

주소 조회와 프로토콜에 필요한 네트워크 확인하기

노드 주소가 도메인이라면 클라이언트가 먼저 해당 도메인을 조회해야 합니다. 현재 DNS 규칙이 아직 연결되지 않은 프록시를 통해 조회하도록 되어 있으면 시작 의존성이 생길 수 있습니다. 노드가 없으면 DNS를 조회할 수 없고, DNS가 없으면 노드에 연결할 수 없는 구조입니다. 노드 도메인은 프록시가 설정되기 전에 사용할 수 있는 신뢰할 만한 직접 연결 DNS로 임시 조회하고, 대상 도메인은 기존 정책에 따라 처리하세요. UDP를 사용하는 기능은 로컬 네트워크, 클라이언트 인바운드, 원격 노드, 아웃바운드 경로가 모두 지원해야 하며 클라이언트에서 UDP를 선택했는지만 확인해서는 안 됩니다.

최종 기록에는 노드 매개변수를 완전히 가져왔는지, 같은 그룹의 다른 노드가 작동하는지, 네트워크를 바꾼 뒤 복구되는지, 오류가 TCP 연결 단계에서 발생했는지 프로토콜 핸드셰이크 단계에서 발생했는지를 포함하세요. 한 노드에서만 문제가 발생하고 여러 네트워크에서 재현된다면 로그의 오류 유형만 남기고 전체 인증 정보는 공개하지 마세요. 모든 노드가 현재 네트워크에서만 실패한다면 각 노드를 계속 수정하기보다 로컬 방화벽, 라우터, DNS, 네트워크 외부 연결을 중점적으로 확인하세요.

4. 구독 업데이트 및 가져오기 실패

다운로드 실패인지 파싱 실패인지 먼저 구분하기

구독 실패는 최소 세 단계로 나뉩니다. 클라이언트가 구독 내용을 받지 못한 경우, 내용을 받았지만 형식을 파싱하지 못한 경우, 파싱은 성공했지만 노드가 현재 그룹에 들어오지 않은 경우입니다. 업데이트할 때는 로그와 안내 문구를 먼저 확인하세요. HTTP 시간 초과, 연결 실패, 도메인 조회 실패는 대개 다운로드 단계의 문제입니다. base64, JSON, YAML, unsupported scheme 같은 메시지는 보통 콘텐츠 파싱 단계의 문제입니다. 업데이트가 완료됐는데 목록이 바뀌지 않았다면 그룹 선택, 중복 제거, 필터, 구독 내용 자체가 변하지 않은 경우를 확인하세요.

현재 보고 있는 구독 그룹을 업데이트하고 있는지 확인하세요. v2rayN은 여러 구독 그룹을 지원하므로 노드 목록이 다른 그룹에 머물러 있을 수 있고, 업데이트 명령도 선택한 그룹에만 적용될 수 있습니다. 같은 이름의 그룹에 같은 주소를 반복해서 가져오지 말고, 먼저 그룹 속성에서 구독 주소, 활성화 상태, 업데이트 결과를 확인하세요. Android 클라이언트에서도 단일 노드 가져오기, 클립보드 일괄 가져오기, 구독 관리가 서로 다르며 자동으로 하나의 업데이트 소스로 합쳐지지 않습니다.

구독 주소의 완전성 확인하기

메신저나 웹 페이지에서 구독 주소를 복사할 때 앞뒤 공백, 줄바꿈, 이스케이프 문자, 잘린 쿼리 매개변수 때문에 요청이 실패할 수 있습니다. 구독 편집란에서 프로토콜 헤더부터 마지막 매개변수까지 주소가 끊김 없이 완전한지 확인하세요. 일부 주소에는 임시 토큰이나 기기 매개변수가 포함되어 있어 문자 하나만 빠져도 권한 없음 또는 빈 내용이 반환됩니다. 구독 주소는 설정을 가져올 수 있는 권한을 가진 경우가 많으므로 공개 로그, 스크린샷, 온라인 분석 도구에 붙여 넣지 마세요.

클라이언트가 프록시를 통한 구독 업데이트를 지원한다면 ‘직접 연결로 업데이트’와 ‘현재 프록시를 통해 업데이트’를 나누어 테스트하세요. 현재 네트워크에서 구독 서비스에 직접 접속할 수 있다면 직접 연결이 가장 단순합니다. 기존 노드를 거쳐야만 접속할 수 있다면 먼저 작동하는 노드가 있어야 합니다. 유일한 구독의 기존 노드가 모두 작동하지 않으면 프록시를 통한 업데이트가 순환 의존에 빠집니다. 이때는 같은 실패 요청을 계속 새로 고치지 말고 설정 제공자에게 직접 접근 가능한 새 주소나 별도 설정을 요청하세요.

업데이트는 성공했지만 새 노드가 없는 경우

노드 수만 보지 말고 업데이트 시각과 로그가 실제로 바뀌었는지 먼저 확인하세요. 구독 서비스가 이전과 같은 내용을 반환하거나 클라이언트가 노드 식별자로 중복을 제거하면 개수가 그대로일 수 있습니다. 이름 필터, 정규식 필터, 특정 프로토콜만 유지, 기존 노드 삭제 옵션이 켜져 있는지 확인하세요. 필터 표현식이 너무 넓으면 파싱 후 새 노드가 모두 제외될 수 있고, 표현식 문법이 잘못되면 일부 클라이언트가 이전 목록을 유지한 채 업데이트 실패를 표시합니다.

구독 그룹을 수정하기 전에 현재 작동하는 설정을 내보내고, 같은 구독을 임시 그룹에 새로 가져오세요. 임시 그룹을 사용하면 이전 캐시, 기존 필터, 중복 항목의 영향을 배제할 수 있습니다. 임시 그룹도 비어 있다면 구독 응답 내용을 중점적으로 확인하고, 임시 그룹에는 노드가 있지만 원래 그룹에는 없다면 원래 그룹의 필터, 정렬, 업데이트 설정을 확인하세요. 비교가 끝난 뒤 원래 그룹을 교체할지 결정하고, 처음부터 유일하게 작동하는 노드를 삭제하지 마세요.

형식과 클라이언트 기능 차이 파악하기

구독 내용은 프로토콜 링크 모음일 수도 있고 구조화된 설정일 수도 있습니다. 클라이언트는 자체적으로 지원하는 형식과 필드만 파싱할 수 있습니다. 전체 코어 설정을 일반 구독으로 가져오거나 단일 공유 링크를 구독 주소란에 넣으면 형식 오류가 발생할 수 있습니다. 제공자가 안내한 가져오기 방식이 현재 클라이언트와 일치하는지 확인하세요. v2rayNG는 Xray 커널을, v2flyNG는 v2fly 커널을 사용하므로 일부 새 필드와 전송 조합의 지원 범위가 다를 수 있습니다. 한 클라이언트에서 가져올 수 있다고 해서 다른 클라이언트도 반드시 허용하는 것은 아닙니다.

{
  "remarks": "example-subscription",
  "url": "https://example.com/subscription?token=xxxx",
  "enabled": true
}

위 구조는 확인해야 할 논리적 필드를 설명하기 위한 것일 뿐이며, 실제 구독은 클라이언트 화면에서 추가해야 합니다. 예시를 클라이언트 설정 파일로 직접 사용하지 마세요. 파싱 오류가 발생하면 오류가 난 줄 주변의 필드 이름을 기록하고, 클라이언트와 커널이 현재 다운로드 페이지의 설치 경로에서 제공되는 것인지 확인하세요. 호환성을 판단하기 위해 버전 번호를 임의로 추정하지 말고 클라이언트에 실제로 표시되는 기능과 로그를 기준으로 판단하세요.

구독 요청이 간헐적으로 실패한다면 같은 네트워크에서 잠시 간격을 두고 재시도하며 직접 연결과 프록시를 통한 업데이트 결과를 비교하세요. 짧은 시간에 계속 새로 고치면 서버 측 요청 제한에 걸릴 수 있고 로그도 읽기 어려울 만큼 쌓입니다. 최종적으로 요청 성공 여부, 반환 콘텐츠의 파싱 가능 여부, 노드가 대상 그룹에 들어갔는지, 필터 규칙이 결과를 삭제했는지를 명확히 확인해야 합니다. 더 짧은 질문은 도움말 센터에서 ‘설치 및 설정’ 분류를 확인하세요.

5. 연결은 정상인데 속도가 느림

지연 시간·대역폭·안정성을 나누어 측정하기

속도가 느리다고 노드 목록의 밀리초 수치만 보면 안 됩니다. 지연 시간은 짧은 연결 설정과 상호작용 응답을, 대역폭은 지속 전송 속도를, 패킷 손실과 지터는 동영상·통화·장시간 연결의 안정성을 좌우합니다. 지연 시간이 짧은 노드라도 외부 연결 대역폭이 제한될 수 있고, 지연 시간이 조금 긴 노드가 지속 다운로드는 더 빠를 수 있습니다. 테스트할 때는 먼저 고정된 웹 페이지를 열어 첫 화면 응답을 관찰하고, 이어서 지속 전송을 실행한 뒤 몇 분 동안 연결이 반복해서 끊기는지 확인하세요. 세 현상을 따로 기록해야 한 번의 속도 측정으로 전체를 판단하는 일을 피할 수 있습니다.

비교군을 만들 때는 기기, 네트워크, 대상 리소스, 테스트 시간을 비슷하게 유지하고 노드만 바꾸세요. 먼저 직접 연결 네트워크의 사용 가능한 대역폭을 측정한 뒤 서로 다른 경로의 노드 두 개를 테스트합니다. 직접 연결 자체가 느리다면 Wi-Fi 신호, 모바일 네트워크 품질, 로컬 사용량을 우선 확인하세요. 모든 노드 속도가 비슷하게 낮다면 기기 성능, 가상 네트워크 모드, 원격 외부 연결을 확인하고, 한 노드만 뚜렷하게 느리다면 해당 경로의 혼잡이나 외부 연결 품질 문제일 가능성이 높습니다.

로컬 리소스와 동시 실행 영향 배제하기

동기화 프로그램, 시스템 업데이트, 클라우드 드라이브, 동영상 재생, 다른 기기가 업로드나 다운로드 대역폭을 사용할 수 있습니다. 특히 업로드가 가득 차면 확인 패킷이 제때 전송되지 않아 다운로드도 끊기는 것처럼 보입니다. 테스트 전에 대용량 작업을 중지하고 라우터나 시스템 작업 관리자에서 네트워크 사용량을 확인하세요. 브라우저에서 많은 페이지를 동시에 열거나, 다운로드 도구의 동시 작업 수를 높이거나, 클라이언트가 모든 노드를 병렬로 측정하면 연결 수와 CPU를 소모해 결과가 불안정해질 수 있습니다.

클라이언트 코어는 암호화, 전송 캡슐화, 라우팅 매칭, DNS를 처리해야 합니다. 저전력 기기는 높은 처리량에서 CPU가 포화되어 속도가 일정 상한에 도달한 뒤 더 이상 증가하지 않을 수 있습니다. 시스템 리소스를 관찰하세요. 전송 중 특정 코어가 계속 100%에 가깝다면 복잡한 규칙을 줄이고 불필요한 로그 수준을 낮춘 뒤 시스템 프록시 모드와 가상 네트워크 모드의 차이를 비교하세요. 속도를 높이려고 이해하지 못한 전송 매개변수를 임의로 바꾸지 마세요. 클라이언트 설정은 원격 서비스와 일치해야 하며 한쪽만 바꾸면 연결 실패로 이어질 수 있습니다.

라우팅 우회 여부 확인하기

속도 문제는 라우팅 문제일 때도 있습니다. 원래 직접 연결해야 하는 로컬 또는 지역 리소스가 프록시로 전송되면 경로와 외부 연결 부담이 늘어납니다. 반대로 프록시를 사용해야 하는 대상이 직접 연결로 잘못 판단되면 반복 재시도가 발생할 수 있습니다. 로그에서 대상 도메인, 조회 결과, 최종 아웃바운드를 확인해 규칙이 예상대로 매칭됐는지 점검하세요. geosite와 geoip로 분할 라우팅할 때는 도메인 규칙과 IP 규칙이 서로 다른 결론을 낼 수 있으며, 규칙 순서가 최종 결과를 결정합니다.

먼저 전체 프록시 모드로 노드의 상한 속도를 확인한 뒤 분할 라우팅 모드로 돌아가세요. 전체 모드는 빠르고 분할 라우팅만 느리다면 DNS와 규칙 매칭을 확인하고, 두 모드 모두 느리다면 경로와 기기를 계속 점검하세요. 첫 페이지 로딩만 느리고 이후 접속은 정상이라면 DNS 조회, 최초 TLS 핸드셰이크, 연결 설정이 원인일 수 있습니다. 처음에는 빠르지만 지속 전송 중 속도가 떨어진다면 경로 혼잡, 패킷 손실, 기기 온도, 대역폭 제한에 가깝습니다. 라우팅 규칙의 실제 설정 방법은 geosite와 geoip 분할 라우팅 실전을 참고하세요.

반복 가능한 테스트 방법 사용하기

여러 속도 측정 사이트를 동시에 사용한 뒤 결과를 섞지 마세요. 고정된 리소스를 선택하고 비슷한 시간대에 직접 연결, 노드 A, 노드 B를 각각 두세 번 테스트해 최고값이 아닌 대표값을 기록하세요. 테스트 중에는 라우팅 모드를 동일하게 유지하고 브라우저 캐시가 다운로드 결과에 영향을 주지 않도록 하세요. 대상 리소스가 외부 연결별로 다르게 분배될 수 있다면 안정적인 다른 리소스로 교차 검증해 대상 사이트의 일시적 혼잡을 노드 속도 문제로 오해하지 마세요.

실제 연결 지연 시간 테스트는 동시 실행 수를 제한해야 하며 노드가 많다면 나누어 실행하세요. 로그에 retry, broken pipe, reset, idle timeout이 반복해서 나타나면 평균 속도가 괜찮아도 경로 안정성이 부족하다는 뜻입니다. 이때는 지연 시간이 가장 짧은 노드보다 패킷 손실과 재연결이 적은 노드를 우선 선택하세요. 동영상과 상호작용 앱은 일반적으로 안정성을 더 중요하게 보고, 장시간 파일 전송은 지속 대역폭을 더 중요하게 보므로 선택 기준이 완전히 같을 수 없습니다.

점검을 마친 뒤에는 병목이 직접 연결 네트워크, 기기 처리 성능, 라우팅 우회, 최초 DNS 조회, 특정 노드 경로, 대상 리소스 중 어디에 있는지 판단할 수 있어야 합니다. 시간대에 따라 병목이 바뀐다면 시간대별 비교 기록을 남기고, 네트워크에 따라 달라진다면 Wi-Fi와 모바일 네트워크를 비교하세요. 클라이언트 모드에 따라 달라진다면 가상 네트워크 인터페이스와 규칙 복잡도를 확인하세요. 이런 결론이 단순히 ‘속도 측정값이 낮다’는 기록보다 후속 처리에 훨씬 유용합니다.

6. DNS 조회 오류·오염·누출로 인한 불일치

DNS 장애의 대표적인 증상 파악하기

DNS 문제는 도메인은 열리지 않지만 알고 있는 IP에는 응답이 있거나, 같은 사이트가 앱마다 다르게 표시되거나, 프록시 모드를 바꾸면 조회 주소가 달라지는 형태로 나타납니다. 로그에 lookup, resolve, no such host, SERVFAIL, NXDOMAIN 등이 표시되기도 합니다. 노드 자체는 연결되지만 대상 도메인이 부적절한 주소로 조회되어 시간 초과나 인증서 이름 불일치가 발생할 수도 있습니다. 점검할 때는 ‘노드 도메인 조회’와 ‘대상 도메인 조회’를 반드시 나누어 보세요. 두 조회가 서로 다른 경로를 사용할 수 있습니다.

먼저 시스템과 브라우저 캐시를 지운 뒤 같은 조회를 반복하세요. 브라우저가 독립 보안 DNS를 사용하면 시스템이나 클라이언트 설정을 따르지 않을 수 있고, 시스템에도 이전 응답이 캐시되어 있을 수 있습니다. 테스트할 때 브라우저의 독립 DNS를 끄거나 현재 상태를 명확히 기록한 다음 시스템 조회 도구와 클라이언트 로그를 비교하세요. Windows에서는 nslookup으로 조회할 수 있고, macOS와 Linux에서는 dig 또는 nslookup을 사용할 수 있습니다. 조회 결과가 다르다고 해서 어느 한쪽이 자동으로 잘못된 것은 아닙니다. 요청을 직접 연결 DNS가 처리해야 하는지 프록시 측 DNS가 처리해야 하는지도 함께 확인해야 합니다.

nslookup example.com
nslookup example.com 1.1.1.1

dig example.com
dig @1.1.1.1 example.com

로컬 조회와 원격 조회 이해하기

로컬 조회는 기기에서 먼저 IP를 얻은 뒤 라우팅 규칙에 따라 연결을 처리합니다. 원격 조회는 일반적으로 도메인을 프록시 측에서 처리합니다. 전자는 IP 규칙에 따른 분할 라우팅이 쉽지만 로컬 DNS 결과에 의존하고, 후자는 로컬 조회 경로가 대상 도메인에 미치는 영향을 줄일 수 있지만 노드 주소와 일부 직접 연결 도메인은 여전히 해결해야 합니다. 구체적인 모드 이름은 클라이언트와 커널 설정에 따라 다르므로 스위치 하나의 이름만 보고 판단하지 말고 로그에서 도메인이 로컬과 원격 중 어디에서 조회됐는지 확인하세요.

라우팅 규칙에 도메인 조건과 IP 조건이 함께 있다면 조회 정책에 따라 IP 규칙에 매칭할 주소가 생성되는지 확인하세요. 도메인으로만 매칭한다면 사전 조회가 필요하지 않을 수 있지만, geoip로 판단해야 한다면 코어가 먼저 조회한 뒤 매칭할 수 있습니다. 잘못된 정책에서는 ‘도메인 규칙이 매칭되지 않고 IP 규칙도 예상대로 작동하지 않음’이 나타날 수 있습니다. 먼저 요구 사항을 정하세요. 로컬 도메인과 사설 주소는 직접 연결하고, 특정 도메인은 지정한 아웃바운드로 보내며, 나머지는 기본 아웃바운드로 보낸다는 식으로 정한 뒤 그 요구에 맞는 조회 경로를 선택하세요.

시작 의존성과 조회 루프 방지하기

노드 주소 자체가 도메인인데 모든 DNS 조회를 해당 노드를 통해 처리하도록 설정하면 조회 루프가 발생합니다. 프록시가 설정되기 전에 사용할 수 있는 부트스트랩 조회를 노드 도메인에 제공하거나, 노드 도메인이 명확한 직접 연결 DNS를 사용하도록 설정하세요. 부트스트랩 DNS는 프록시 연결에 필요한 소수의 조회만 담당해야 하며 대상 도메인 정책과 섞어서는 안 됩니다. 로그에 노드 도메인 조회가 반복되고 연결이 설정되기 전에 DNS 요청이 다시 발생한다면 이 의존 관계를 먼저 확인하세요.

가상 네트워크 모드가 시스템 DNS를 인수할 수도 있습니다. 클라이언트가 비정상 종료되거나 네트워크가 바뀌거나 절전 모드에서 복귀한 뒤 시스템에 더 이상 도달할 수 없는 DNS 주소가 남으면 프록시를 꺼도 조회되지 않을 수 있습니다. 먼저 가상 네트워크 모드를 정상적으로 중지한 뒤 시스템 네트워크 카드의 DNS가 자동 또는 기존 설정으로 복구됐는지 확인하세요. 클라이언트 실행 중 여러 네트워크 도구가 동시에 DNS를 바꾸지 않도록 하세요. 어떤 설정이 최종 적용됐는지 확인하기 어려워집니다.

로그로 최종 결과 검증

DNS를 바꾼 뒤 웹 페이지가 우연히 열리는지만 보지 마세요. 캐시를 지우고 고정된 도메인을 조회해 반환 주소를 기록한 다음, 클라이언트 로그에서 해당 도메인이 어떤 아웃바운드에 매칭됐는지 확인하세요. 같은 도메인에 여러 주소가 있으면 짧은 시간 동안 주소가 바뀌는 것은 정상적인 부하 분산일 수 있습니다. 실제로 중요한 것은 주소 유형과 아웃바운드가 라우팅 설계에 맞는지입니다. 조회 결과, 라우팅 매칭, 최종 연결이 모두 일치해야 설정이 유효하다고 볼 수 있습니다.

특정 도메인 하나가 계속 실패한다면 루트 도메인과 하위 도메인을 비교하고 별도의 도메인 규칙, hosts 재정의, 캐시가 있는지 확인하세요. hosts 항목은 일반적으로 우선순위가 높아 오래된 항목이 모든 DNS 설정을 무효화한 것처럼 보이게 합니다. 특정 브라우저에서만 오류가 발생하면 해당 브라우저의 DNS와 연결 캐시를 지우고, 모든 앱에서 동일하면 시스템과 클라이언트 계층으로 돌아가세요. DNS 서비스를 바꾸는 것은 비교용 수단일 뿐 조회 경로 확인을 대신할 수 없습니다.

DNS 복구 후에는 클라이언트를 완전히 종료했다가 다시 시작해도 노드에 연결되어야 합니다. 시스템 조회가 예상한 경로와 일치하고, 같은 프록시 진입점을 사용한 브라우저와 명령줄의 결과가 같아야 합니다. 네트워크 전환, 절전 모드 복귀, 정상 종료 후에도 시스템 DNS가 복구되어야 합니다. 가상 네트워크 모드에서만 실패하고 일반 시스템 프록시는 정상이라면 가상 인터페이스의 DNS 인수, 라우팅 우선순위, 시스템 권한을 계속 확인하세요.

7. 시스템 프록시 설정이 적용되지 않음

애플리케이션이 시스템 프록시를 따르는지 확인하기

시스템 프록시는 모든 프로그램이 자동으로 사용하는 통합 터널이 아닙니다. 브라우저와 일부 데스크톱 앱은 대개 시스템 프록시를 읽지만, 명령줄 도구, 게임, 백그라운드 서비스, 자체 네트워크 스택을 사용하는 프로그램은 무시할 수 있습니다. ‘브라우저는 정상인데 특정 앱은 직접 연결됨’이 나타나면 해당 앱이 시스템 프록시를 지원하는지, 수동 프록시를 저장했는지, HTTP 또는 SOCKS를 별도로 설정해야 하는지 먼저 확인하세요. 앱이 시스템 프록시를 명확히 따르지 않는다면 클라이언트의 가상 네트워크 모드를 고려할 수 있지만, 활성화 전에 권한, 라우팅, DNS 인수 범위를 이해해야 합니다.

반대로 브라우저 프록시 확장 프로그램이 시스템 설정을 덮어쓸 수도 있습니다. 확장 프로그램이 이전 포트, 이전 프로토콜, 다른 프록시 프로그램을 가리키면 v2rayN의 시스템 프록시 상태와 관계없이 브라우저는 다른 경로를 사용합니다. 점검할 때는 확장 프로그램을 잠시 끄고 브라우저 기본 네트워크 설정을 사용하세요. 정상으로 돌아오면 확장 프로그램을 다시 설정합니다. 기업 관리 정책이 프록시 항목을 잠글 수도 있습니다. 이 경우 시스템 설정 화면에는 값이 보여도 앱이 읽는 값은 정책으로 정해질 수 있으므로 시스템 프록시 페이지에 조직 관리 표시가 있는지 확인하세요.

프로토콜과 리스닝 주소 확인하기

HTTP 프록시와 SOCKS 프록시는 포트 번호만으로 서로 바꿔 쓸 수 없습니다. 시스템 프록시는 대개 HTTP 진입점을 필요로 하지만 일부 도구는 SOCKS를 직접 사용할 수 있습니다. 클라이언트 설정에서 각 인바운드의 프로토콜, 리스닝 주소, 포트를 확인한 뒤 앱에도 그에 맞게 입력하세요. 127.0.0.1에 리스닝한다는 것은 로컬 컴퓨터에서만 접근할 수 있다는 뜻입니다. LAN 연결을 허용하면 모든 인터페이스에서 리스닝할 수 있지만, 이는 로컬 시스템 프록시가 작동하기 위한 필수 조건은 아닙니다. 일상적인 사용에서는 로컬 프록시를 고치려고 LAN 리스닝을 함부로 개방하지 마세요.

다음 방식으로 명시적 HTTP 프록시를 확인할 수 있습니다. 명령은 성공하지만 시스템 프록시 모드의 브라우저가 실패한다면 시스템 프록시 기록이나 브라우저 재정의가 문제입니다. 명령이 로컬 포트 연결 단계에서 거부되면 코어 프로세스와 포트를 확인하세요. 로컬 연결은 성공하지만 원격 연결이 실패하면 노드, 라우팅, DNS를 확인해야 합니다.

curl -I --proxy http://127.0.0.1:10809 https://example.com/
curl -I --socks5-hostname 127.0.0.1:10808 https://example.com/

예시 포트는 설명을 위한 값일 뿐이므로 반드시 클라이언트의 현재 설정을 사용하세요. --socks5-hostname은 도메인을 SOCKS 경로를 통해 조회하므로 로컬 조회 방식과 비교할 때 유용합니다. 시스템 프록시를 자동으로 설정하는 프로그램을 여러 개 동시에 실행하지 마세요. 서로 시스템 값을 번갈아 덮어써 화면 상태와 실제 레지스트리 또는 네트워크 서비스 설정이 달라질 수 있습니다.

비정상 종료 후 남은 프록시 처리하기

클라이언트를 강제 종료했거나 시스템이 갑자기 꺼졌거나 코어가 충돌한 뒤 시스템 프록시가 로컬 포트를 계속 가리킬 수 있습니다. 시스템 프록시를 따르는 모든 앱이 실패하므로 네트워크가 끊긴 것처럼 보입니다. 먼저 원래 클라이언트를 다시 시작해 시스템 프록시를 지우거나 끈 다음 정상적으로 종료하세요. 시스템 네트워크 설정에서 프록시를 수동으로 꺼도 됩니다. 직접 연결을 복구한 뒤 클라이언트를 다시 시작해 설정하세요. 네트워크가 끊긴 상태에서 모든 설정을 즉시 삭제하면 남은 포트와 기존 설정을 판단할 근거를 잃게 됩니다.

Windows에서는 계정과 권한 컨텍스트가 다른지도 구분해야 합니다. 서로 다른 권한으로 시작한 프로그램은 다른 환경 변수나 설정 범위를 읽을 수 있고, 백그라운드 서비스도 현재 데스크톱 계정의 프록시를 사용하지 않을 수 있습니다. macOS의 프록시 설정은 네트워크 서비스별로 저장되므로 Wi-Fi와 다른 네트워크 인터페이스에 서로 다른 설정이 있을 수 있습니다. 인터페이스를 바꾼 뒤 현재 활성 네트워크 서비스의 프록시 상태를 확인하세요. Linux 데스크톱 환경에는 데스크톱 프록시, 환경 변수, 앱 자체 설정이 동시에 존재할 수 있으므로 세 계층을 차례로 확인해야 합니다.

환경 변수와 명령줄 프로그램

명령줄 프로그램은 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY를 읽는 경우가 많습니다. 변수는 현재 터미널, 사용자 설정 파일, 시스템 서비스, 컨테이너 환경에서 설정될 수 있습니다. 터미널에 이전 포트가 남아 있으면 데스크톱 시스템 프록시를 업데이트해도 명령줄 요청은 실패합니다. 변수를 확인한 뒤 터미널을 새로 열어 새 프로세스가 최신 값을 읽도록 하세요. 사내 도메인과 로컬 주소는 일반적으로 프록시를 거치지 않는 범위에 넣어야 하지만, 제외 규칙은 정확하게 유지해야 합니다. 너무 넓은 제외 범위는 프록시가 필요한 요청까지 직접 연결하게 만듭니다.

set HTTP_PROXY
set HTTPS_PROXY

env | grep -i proxy

변수를 지우기 전에 출처를 기록하세요. 현재 터미널에서만 임시로 수정하면 다음 실행 때 이전 값이 다시 나타날 수 있습니다. 컨테이너와 서브시스템이 독립적인 네트워크 네임스페이스를 사용한다면 127.0.0.1은 호스트가 아니라 컨테이너 자신을 가리킬 수 있습니다. 해당 환경에서 접근할 수 있는 호스트 주소를 사용하고 클라이언트가 해당 인터페이스 연결을 허용하는지도 확인하세요. 이는 애플리케이션 네트워크 경계의 문제이지 노드 프로토콜의 문제가 아닙니다.

최종적으로 코어 포트가 실제로 리스닝 중인지, 시스템 프록시가 같은 포트와 올바른 프로토콜을 가리키는지, 브라우저 확장 프로그램이 덮어쓰지 않는지, 명령줄 변수에 이전 값이 남아 있지 않은지, 비정상 종료 후 프록시가 복구되는지, 시스템 프록시를 따르지 않는 앱에 명확한 우회 방식을 적용했는지 확인하세요. 클라이언트를 재설치해야 한다면 먼저 클라이언트 받기 페이지에서 해당 플랫폼을 선택하고, 제거 전에 현재 포트, 그룹, 라우팅 설정을 기록해 설치 후 설정 차이를 프로그램 문제로 오해하지 않도록 하세요.

8. 클라이언트 시작 실패·갑작스러운 종료·코어 충돌

UI 프로세스와 코어 프로세스 구분하기

v2rayN 같은 그래픽 클라이언트는 일반적으로 설정 관리, 구독, 시스템 프록시, 화면 표시를 담당하고 실제 연결은 Xray 또는 v2fly 커널 프로세스가 처리합니다. UI는 열리지만 연결되지 않는다면 코어가 시작되지 않았을 수 있습니다. UI가 바로 종료된다면 실행 환경, 설정 파일, 권한, 프로그램 파일을 우선 확인하세요. 작업 관리자나 시스템 프로세스 목록에 UI 프로세스만 보인다고 코어가 정상 실행 중이라는 뜻은 아닙니다. 로그가 ‘코어 시작’ 전에서 멈췄는지 후에 멈췄는지에 따라서도 점검 방향이 달라집니다.

먼저 클라이언트를 완전히 종료하고 남은 UI와 코어 프로세스가 없는지 확인한 뒤 한 번만 다시 시작하세요. 여러 번 연속으로 실행 버튼을 누르면 여러 인스턴스가 설정 파일과 리스닝 포트를 동시에 사용하려 할 수 있습니다. 클라이언트가 이미 실행 중이라고 표시되면 작업 관리자에서 남은 프로세스를 종료하고 포트가 해제될 때까지 기다린 후 시작하세요. 특정 설정을 로드할 때마다 종료된다면 현재 설정을 임시로 내보내 백업하고 가장 단순한 정상 설정으로 전환해 테스트하세요.

설정 파싱과 쓰기 권한 확인하기

JSON을 수동으로 편집할 때 쉼표 하나, 잘못된 따옴표, 필드 유형 하나만 잘못되어도 코어 로드가 막힐 수 있습니다. failed to parse, invalid character, unknown field, failed to load config 같은 로그는 대개 오류가 난 필드 위치를 알려 줍니다. 오류가 있는 파일에 계속 내용을 추가하지 말고 클라이언트 화면에서 기본 생성 설정을 복구한 뒤 사용자 지정 DNS와 라우팅을 하나씩 추가하세요. 아래는 괄호와 배열 관계를 이해하기 위한 문법적으로 완전한 최소 JSON 구조 예시이며, 직접 연결할 수 있는 노드는 포함하지 않습니다.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

설정 디렉터리에 쓰기 권한이 없으면 구독 업데이트, 로그 생성, 설정 저장이 모두 실패할 수 있습니다. 클라이언트가 있는 디렉터리와 사용자 데이터 디렉터리에 현재 계정의 쓰기 권한이 있는지 확인하고 읽기 전용 위치에서 직접 실행하지 마세요. 보안 프로그램이 코어 파일을 격리하면 UI에서 코어를 찾을 수 없다고 표시되거나 시작 직후 종료될 수 있습니다. 시스템 보안 기록을 확인해 파일 출처가 이 사이트의 다운로드 경로와 일치하는지 확인한 뒤 기기의 관리 정책에 따라 처리하세요. 출처가 불명확한 곳에서 코어 파일 하나만 가져오면 UI와 커널 조합이 맞지 않을 수 있습니다.

포트 충돌과 중복 인스턴스 처리하기

코어가 시작된 직후 종료되는 흔한 원인은 로컬 포트가 이미 사용 중인 경우입니다. 로그에 bind, listen, address already in use가 나타납니다. 먼저 포트를 점유한 프로세스가 이전 클라이언트 인스턴스인지, 다른 프록시 프로그램인지, 시스템 서비스인지 확인하세요. 남은 인스턴스라면 정상적으로 종료한 뒤 다시 시작합니다. 필요한 서비스가 포트를 사용 중이라면 클라이언트에서 HTTP와 SOCKS 포트를 바꾸고 시스템 프록시, 브라우저 확장 프로그램, 명령줄 환경 변수도 함께 업데이트하세요. 클라이언트 포트만 바꾸고 사용 프로그램을 바꾸지 않으면 ‘충돌’이 ‘프록시 미작동’으로 바뀔 뿐입니다.

여러 사용자 계정, 원격 데스크톱 세션, 부팅 시 자동 실행 작업이 서로 다른 인스턴스를 시작할 수도 있습니다. 시작 프로그램과 예약 작업을 확인해 시스템 프록시를 설정하는 클라이언트가 하나뿐인지 확인하세요. 서로 다른 설정을 병렬로 실행해야 한다면 각 인스턴스에 별도의 데이터 디렉터리, 로그, 리스닝 포트를 지정해야 합니다. 일반적인 문제 해결에서는 결과를 원인과 연결하기 어려우므로 권장하지 않습니다.

무작정 삭제하지 말고 깨끗한 상태에서 복구하기

복구하기 전에 구독 그룹, 수동 노드, 사용자 지정 라우팅을 백업하되 구독 주소와 노드 인증 정보는 공개된 곳에 저장하지 마세요. 그다음 시스템 프록시와 가상 네트워크 모드를 끄고 클라이언트를 정상 종료한 뒤 기존 설정 디렉터리의 이름을 백업용으로 변경합니다. 클라이언트를 시작해 새 기본 설정을 생성하고 UI와 코어가 실행되는지 확인한 다음 단일 노드, 구독 그룹, 라우팅과 DNS 순서로 하나씩 가져오세요. 어느 단계에서 다시 충돌하는지에 따라 해당 데이터 유형을 중점적으로 확인할 수 있습니다.

새 설정에서도 시작되지 않는다면 실행 환경, 시스템 권한, 프로그램 아키텍처, 보안 프로그램 기록을 확인하세요. macOS에서는 시스템이 앱 실행을 허용하는지 확인하고, Linux에서는 터미널에서 시작해 누락된 의존성과 권한 오류를 확인하며, Windows에서는 애플리케이션 이벤트와 클라이언트 로그를 확인하세요. 오류 보고서에는 예외 모듈, 종료 단계, 오류 코드를 남기되 개인 경로, 구독 내용, 인증 정보는 삭제하세요.

구독 업데이트나 대량 속도 측정 때만 충돌한다면 동시 실행 수를 줄이고 메모리와 디스크 공간을 관찰하세요. 절전 모드 복귀 후에만 발생한다면 네트워크 인터페이스 변화와 이전 코어 프로세스를 확인하고, 가상 네트워크 모드에서만 발생한다면 드라이버, 권한, 다른 가상 인터페이스와의 충돌을 확인하세요. 점검을 마치면 UI, 코어, 설정 파싱, 포트, 권한, 실행 환경 중 무엇이 문제인지 특정한 뒤 설정을 수정하거나 재설치해야 합니다. 모든 문제를 클라이언트 버전 탓으로 돌리지는 마세요.

9. Android 연결 및 백그라운드 실행 집중 점검

가상 네트워크 권한과 현재 클라이언트 확인하기

v2rayNG와 v2flyNG는 Android에서 일반적으로 시스템 가상 네트워크 인터페이스를 통해 트래픽을 처리합니다. 처음 연결을 시작할 때 시스템 권한 승인이 필요합니다. 권한이 거부됐거나 다른 가상 네트워크 앱이 인터페이스를 사용 중이거나 시스템이 재부팅 후 권한을 철회하면 클라이언트가 시작 중으로 표시되어도 실제 트래픽을 처리하지 못할 수 있습니다. 먼저 같은 시스템 인터페이스를 사용하는 다른 네트워크 도구를 중지하고 현재 클라이언트를 다시 시작한 뒤 권한 안내를 확인하세요. 상태 표시줄의 연결 표시는 인터페이스가 만들어졌다는 단서일 뿐이며, 로그와 실제 접속으로 노드 경로를 검증해야 합니다.

두 클라이언트를 동시에 연결 상태로 두지 마세요. v2rayNG는 Xray 커널을, v2flyNG는 v2fly 커널을 사용하므로 지원하는 설정 필드 범위가 다를 수 있습니다. 같은 구독을 두 클라이언트에 가져와 비교할 때는 앞의 연결을 먼저 중지하고 다음 클라이언트를 시작하세요. 그렇지 않으면 시스템에서 하나의 인터페이스만 작동해 노드 문제로 잘못 판단할 수 있습니다. 데스크톱에서는 v2rayN으로 교차 검증할 수 있지만 기기 간 비교에서는 Wi-Fi, 모바일 네트워크, DNS 경로 차이도 고려해야 합니다.

백그라운드 중지와 화면 잠금 후 연결 끊김 처리하기

일부 Android 시스템은 백그라운드 프로세스, 화면 잠금 상태의 네트워크, 배터리 사용을 제한합니다. 대표적인 현상은 화면이 켜져 있을 때는 정상 연결되지만 몇 분간 잠그면 연결이 끊기고 클라이언트를 다시 열면 복구되는 경우입니다. 시스템 앱 설정에서 클라이언트의 지속적인 백그라운드 실행을 허용하고 엄격한 배터리 제한을 해제하며, 시스템이 알림이나 서비스를 자동으로 정리하지 않는지 확인하세요. 기기마다 메뉴 이름은 다르므로 ‘배터리’, ‘백그라운드 사용’, ‘자동 시작’, ‘앱 시작 관리’와 같은 항목을 기준으로 찾으면 됩니다.

설정을 마친 뒤 클라이언트 버튼 상태만 보지 마세요. 연결을 설정하고 고정된 웹 페이지에 접속한 다음 화면을 잠근 채 기다렸다가 잠금 해제 후 다시 접속하며 로그 타임라인을 확인하세요. 로그가 중간에 완전히 멈췄다면 프로세스가 시스템에 의해 일시 중지됐을 가능성이 높습니다. 로그는 계속되지만 연결이 다시 설정된다면 절전 중 네트워크 인터페이스가 바뀌었을 수 있고, 요청이 로그에 들어온 뒤 노드 시간 초과가 발생한다면 네트워크 경로를 계속 확인하세요. 상시 알림을 유지하면 시스템이 실행 중인 네트워크 서비스를 인식하는 데 도움이 되므로 관련 알림 범주를 함부로 끄지 마세요.

Wi-Fi와 모바일 네트워크 전환

Wi-Fi에서 모바일 네트워크로 전환하면 기기 IP, DNS, 최대 전송 단위, 네트워크 기능이 모두 바뀝니다. 기존 연결은 보통 다시 설정해야 하므로 잠시 실패하는 것은 전환 과정의 일부입니다. 전환 후에도 장시간 네트워크가 작동하지 않으면 클라이언트를 중지하고 다시 시작해 가상 인터페이스를 새 네트워크에 연결하세요. 모바일 네트워크에서 Wi-Fi로 돌아올 때도 다시 테스트해야 합니다. 특히 로그인이 필요한 공용 네트워크에서는 먼저 프록시를 일시 중지하고 네트워크 인증을 완료한 뒤 다시 연결하세요.

Wi-Fi에서는 정상인데 모바일 네트워크에서 시간 초과가 발생한다면 모바일 네트워크에서 노드 주소를 조회할 수 있는지 비교하고, 이동통신망 접속 지점이 특정 연결 방식을 제한하는지 확인한 뒤 구독의 다른 노드로 테스트하세요. 모바일 네트워크는 정상인데 가정용 Wi-Fi가 실패한다면 라우터 DNS, 방화벽, 같은 네트워크의 다른 기기를 확인하세요. 네트워크를 바꾸는 동시에 노드 매개변수도 수정하지 마세요. 무엇이 복구를 일으켰는지 판단할 수 없게 됩니다.

앱별 프록시와 우회 설정

Android 클라이언트는 앱별 프록시를 제공하는 경우가 많습니다. 활성화할 때 현재 모드가 ‘선택한 앱만 프록시 사용’인지 ‘선택한 앱은 우회’인지 명확히 확인하세요. 두 모드는 방향이 반대이므로 잘못 선택하면 브라우저만 정상이고 다른 앱은 직접 연결되거나, 일부 앱만 실패할 수 있습니다. 점검할 때는 앱별 설정을 잠시 끄고 모든 앱이 같은 경로를 사용하도록 하세요. 기본 연결이 정상임을 확인한 뒤 앱을 하나씩 추가해 테스트합니다. 앱 업데이트나 재설치 후 식별자가 바뀔 수 있으므로 목록도 다시 확인하세요.

LAN 앱, 화면 공유, 프린터, 기기 검색은 프록시 우회가 필요할 수 있지만 실제 트래픽은 가상 인터페이스 라우팅의 영향도 받습니다. LAN 접속이 실패하면 클라이언트가 LAN 우회를 허용하는지 확인하고 사설 주소가 직접 연결로 처리되는지 점검하세요. 너무 넓은 우회 범위로 모든 트래픽을 덮지 마세요. 항목을 하나 추가할 때마다 대상 앱으로 확인해야 합니다. 앱 내부에 별도 프록시나 보안 DNS가 있다면 일시적으로 기본값으로 돌려 클라이언트 가상 네트워크 설정과 겹치지 않게 하세요.

모바일 로그와 최종 검증

모바일 로그 수집에는 연결 시작, 네트워크 전환, 화면 잠금 복귀, 실패한 앱이 요청을 시작한 시점이 포함되어야 합니다. 시스템에 가상 네트워크 연결이 표시되는지, 클라이언트 서비스가 계속 실행 중인지, 요청이 로그에 들어오는지, 노드가 재연결하는지 기록하세요. 로그를 공유하기 전에는 구독 주소, 사용자 식별자, 전체 서버 정보를 삭제합니다. 특정 앱에서만 문제가 발생한다면 해당 앱의 독립 DNS 사용 여부, 앱별 규칙 선택 여부, 브라우저 비교 결과도 함께 기록하세요.

최종 검증에는 최소 네 가지가 포함되어야 합니다. 화면이 켜진 상태에서 연속 접속이 정상이어야 하고, 화면 잠금 후 복귀해도 계속 접속할 수 있어야 하며, Wi-Fi와 모바일 네트워크 전환 후 자동 복구되거나 한 번 재연결하면 복구되어야 하고, 앱별 규칙이 예상대로 작동해야 합니다. v2rayNG와 v2flyNG가 같은 설정에서 다르게 작동하면 먼저 해당 설정의 커널 필드 호환성을 확인한 뒤 사용할 클라이언트를 결정하세요. 클라이언트 이름 차이만을 유일한 원인으로 보지 마세요. 설치 경로를 다시 확인해야 한다면 Android 클라이언트 다운로드 영역으로 돌아가세요.

9개 장의 점검을 마친 뒤에도 원인을 찾지 못했다면 문제를 ‘어느 계층에서 발생하는지, 어떤 비교에서 결과가 달라지는지, 로그에 어떤 오류가 있는지’로 압축하세요. 예를 들면 ‘명시적 로컬 프록시는 작동하지만 시스템 프록시는 작동하지 않음’, ‘Wi-Fi에서는 노드 시간 초과가 발생하지만 모바일 네트워크에서는 정상’, ‘구독 다운로드는 성공했지만 파싱 결과가 비어 있음’, ‘화면 잠금 후 코어 로그가 멈춤’처럼 작성할 수 있습니다. 그런 다음 도움말 센터에서 해당 분류를 찾거나 사용 가이드로 돌아가 최소 작동 설정을 다시 구성하세요. 체계적인 점검의 목표는 더 많은 설정을 시도하는 것이 아니라 더 적은 변수로 검증 가능한 결론을 얻는 것입니다.