V2Ray 문제 해결: 증상별 연결 문제 진단

먼저 ‘로컬 네트워크 단절’과 ‘프록시 경로 단절’을 구분하세요

클라이언트 트레이 아이콘이 실행 중으로 표시된다는 것은 그래픽 인터페이스와 코어 프로세스가 시작되었다는 뜻일 뿐, 트래픽이 원격 서버에 도달했다는 의미는 아닙니다. 점검할 때는 먼저 시스템 프록시 또는 Android의 VPN 연결을 잠시 끈 다음, 로컬 네트워크에서 평소 접속되던 사이트를 열어 보세요. 클라이언트를 종료한 뒤에도 접속되지 않는다면 문제는 현재 Wi-Fi, 유선 네트워크, 모바일 네트워크, 게이트웨이 또는 시스템 네트워크 스택에 있습니다. 이때 노드 매개변수를 계속 수정해서는 안 됩니다. 네트워크를 다시 연결하거나 네트워크 어댑터를 껐다 켜고, 다른 네트워크에서 재시험하는 편이 구독을 반복해서 가져오는 것보다 대개 빠릅니다.

직접 연결은 정상이고 프록시를 켠 뒤 모든 웹사이트가 실패한다면 다음 단계로 클라이언트 로그를 확인하세요. v2rayN에서는 로그 영역에서 Xray 시작 및 연결 기록을 확인할 수 있고, v2rayNG·v2flyNG에서는 로그 페이지를 연 뒤 대상 주소에 한 번 다시 접속하면 됩니다. 중요한 것은 로그의 양이 아니라 처음 나타난 오류입니다. connection refused는 대상 포트가 연결을 명확히 거부했다는 뜻인 경우가 많고, timeout은 제한 시간 안에 핸드셰이크가 완료되지 않았다는 뜻입니다. no such host는 도메인 조회 문제를 가리키며, certificate 또는 handshake가 보이면 시스템 시간, SNI와 전송 보안 매개변수를 확인해야 합니다.

최소 설정으로 라우팅 규칙의 영향을 배제하세요

복잡한 라우팅은 브라우저 트래픽을 사용할 수 없는 아웃바운드로 보내거나, 프록시가 처리해야 할 도메인을 잘못 직접 연결로 보낼 수 있습니다. 정상 작동이 확인된 노드 하나만 남기고 라우팅 모드를 잠시 전역 프록시로 전환하세요. 추가 사용자 규칙, 체인 프록시, Mux와 실험적인 DNS 기능을 끈 뒤 일반 HTTPS 페이지를 테스트합니다. 전역 모드에서는 작동하지만 규칙 모드에서는 작동하지 않는다면 문제는 노드가 아니라 라우팅 매칭에 있습니다. 규칙을 복원할 때는 한 번에 한 그룹만 활성화하고, 변경할 때마다 새 연결을 만들어 브라우저가 기존 TCP 또는 HTTP/3 세션을 계속 재사용하지 않도록 하세요.

그래픽 인터페이스의 라우팅 규칙은 최종적으로 Xray 설정으로 변환됩니다. 규칙은 클라이언트가 생성한 순서대로 매칭에 참여하며, 도메인·IP·포트·네트워크 유형이 동시에 아웃바운드를 결정할 수 있습니다. 아래의 최소 구조는 프록시와 직접 연결이라는 두 아웃바운드만 남겨 문제의 범위를 이해하기 위한 것입니다. 실제 클라이언트에는 인바운드 리스너와 노드 인증 정보가 추가됩니다.

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {}
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

포트 점유, 시간과 잔여 프로세스 확인

데스크톱 클라이언트는 로컬에서 SOCKS, HTTP 또는 혼합 프록시 포트를 수신 대기합니다. 같은 포트를 다른 프록시 프로그램, 이전 코어 프로세스 또는 디버깅 도구가 사용 중이면 새 코어가 시작되지 않을 수 있지만 인터페이스에는 이전 상태가 남아 있을 수 있습니다. Windows에서는 터미널에서 netstat -ano를 실행해 수신 대기 포트와 프로세스 번호를 확인할 수 있고, macOS와 Linux에서는 lsof -iTCP -sTCP:LISTEN을 사용할 수 있습니다. 충돌을 발견하면 관련 프로그램을 먼저 종료한 뒤 클라이언트에서 코어를 완전히 다시 시작하세요. 노드만 바꾸어서는 안 됩니다.

netstat -ano | findstr LISTENING
lsof -iTCP -sTCP:LISTEN
date

시스템 시간도 정확해야 합니다. TLS, REALITY와 구독 서버의 HTTPS 연결은 모두 시간 정보를 바탕으로 판단합니다. 시간 오차가 크면 모든 노드가 동시에 실패하거나 구독 업데이트도 되지 않고, 로그에 인증서가 아직 유효하지 않거나 이미 만료되었다는 메시지가 계속 나타날 수 있습니다. 시스템 자동 시간 동기화를 켠 뒤 클라이언트를 완전히 종료하고 다시 시작해 새 연결이 보정된 시간을 사용하게 하세요. 위 점검이 모두 정상이라면 다운로드 페이지에서 플랫폼에 맞는 클라이언트를 사용하는지 확인하고, 오래된 설정을 대량으로 덮어쓰지 말고 최소 설정부터 다시 구성하세요.

지연 시간 테스트 결과가 실제 웹페이지 속도를 의미하지는 않습니다

v2rayN의 지연 시간 테스트는 TCP 연결, 실제 지연 시간 또는 다른 가용성 확인 방식을 사용할 수 있으며, 방식마다 확인하는 대상이 다릅니다. TCP 연결에 성공했다는 것은 원격 주소와 포트가 기본 핸드셰이크를 완료할 수 있다는 뜻일 뿐, 프로토콜 인증, TLS, REALITY 또는 대상 웹사이트 접속까지 성공한다는 의미는 아닙니다. 실제 지연 시간 테스트는 더 많은 과정을 거치지만 테스트 주소, DNS와 현재 라우팅의 영향을 받을 수 있습니다. 따라서 단 한 번의 시간 초과 표시만으로 노드를 삭제해서는 안 됩니다. 먼저 테스트 유형을 확인하고 실제 웹페이지에 접속한 뒤, 로그를 통해 시간 초과가 DNS 조회, 원격 연결, TLS 핸드셰이크 또는 아웃바운드 접속 중 어디에서 발생했는지 판단하세요.

같은 구독의 다른 노드는 정상인데 특정 노드 하나만 시간 초과가 발생한다면 대개 해당 노드의 주소, 포트, 전송 매개변수 또는 서비스 상태 문제입니다. 모든 노드가 동시에 시간 초과되면 로컬 네트워크, 시스템 시간, DNS, 코어 시작 실패 또는 네트워크 환경 변화일 가능성이 큽니다. 특정 네트워크에서만 전부 실패하고 다른 네트워크에서는 복구된다면 현재 라우터, 방화벽, 기업 네트워크 정책 또는 UDP 사용 가능성을 먼저 확인하세요. 모든 노드를 동시에 수정하지 마세요.

주소, 포트와 전송 매개변수를 항목별로 확인

노드를 수동으로 설정할 때 서버 주소에는 프로토콜 접두사, 경로 또는 불필요한 공백을 넣지 마세요. 포트는 정수여야 하며 UUID, 사용자 식별자와 비밀번호 같은 인증 필드는 빠짐없이 복사해야 합니다. VLESS와 VMess는 서로 바꿔 쓸 수 있는 프로토콜이 아니며, TCP·WebSocket·gRPC 전송 방식도 포트만 보고 추측할 수 없습니다. TLS를 사용한다면 서버 이름과 호스트 필드를 확인하고, REALITY를 사용한다면 공개 키, 짧은 식별자, 지문과 서버 이름도 일치시켜야 합니다. 하나라도 다르면 핸드셰이크 시간 초과 또는 연결 직후 종료로 나타날 수 있습니다.

WebSocket 노드는 경로와 Host도 확인해야 합니다. 경로는 보통 슬래시로 시작하며 대소문자와 추가 쿼리 부분도 서버 매칭에 영향을 줄 수 있습니다. gRPC에서는 서비스 이름을 확인해야 하며 이를 WebSocket 경로에 입력하면 안 됩니다. 노드가 구독에서 가져온 것이라면 필드를 수동으로 ‘수정’하기보다 먼저 구독을 다시 업데이트하세요. 제공자가 이미 매개변수를 변경했을 수 있기 때문입니다. 다시 가져오기 전 현재 구독 그룹을 복사해 기록으로 남길 수 있지만, 같은 이름의 노드 두 개가 자동 선택에 동시에 참여하지 않도록 하세요.

시간 초과 시간을 늘리는 것으로 원인 진단을 대신하지 마세요

연결 시간 초과를 몇 초에서 매우 긴 시간으로 늘리면 사용할 수 없는 노드가 실패를 더 늦게 반환할 뿐, 프로토콜이나 포트 오류가 해결되지는 않습니다. 올바른 재시험 방법은 노드 하나를 선택하고 자동 전환을 끈 뒤 새 연결을 만든 다음, 연결 버튼을 누른 시점부터 첫 오류 로그가 나타날 때까지 어떤 일이 발생하는지 관찰하는 것입니다. TCP 연결은 되지만 TLS 핸드셰이크가 실패하면 SNI와 시간을 확인하고, TLS 완료 후 인증이 실패하면 사용자 식별자와 프로토콜을 확인하세요. 프록시는 연결되었지만 특정 웹사이트만 시간 초과되면 라우팅, DNS, MTU 또는 대상 측 연결 문제를 점검해야 합니다.

UDP 상황은 별도로 판단해야 합니다. 일부 네트워크에서는 UDP가 불안정하고, 브라우저가 HTTP/3를 우선 사용하거나 DNS가 UDP로 조회되면서 ‘일부 웹페이지는 계속 로딩되고 일반 TCP 테스트는 정상’인 현상이 나타날 수 있습니다. 브라우저의 HTTP/3를 잠시 끄거나 DNS를 TCP 또는 HTTPS 방식으로 바꿔 문제가 사라지는지 확인하세요. UDP만 실패한다면 노드 전체를 사용할 수 없다고 판단하지 말고 실제 사용 목적에 맞게 전송 방식과 라우팅을 조정하세요.

자동 선택이나 부하 분산 정책은 점검 변수를 늘립니다. 테스트 중에는 아웃바운드 하나를 고정해 클라이언트가 여러 노드 사이를 전환하지 않게 하세요. 단일 노드가 안정적인 것을 확인한 뒤 자동 선택을 다시 활성화합니다. 특정 노드가 데스크톱과 Android에서 동시에 실패하고 두 기기가 서로 다른 네트워크를 사용한다면 노드 매개변수나 원격 상태일 가능성이 높습니다. 같은 노드가 한 기기에서만 실패한다면 양쪽의 코어 유형, 라우팅 규칙, DNS 설정과 시스템 시간을 비교하세요.

먼저 구독 주소와 단일 노드 공유 링크를 구분하세요

구독 주소는 보통 여러 노드 데이터를 반환하며, 클라이언트에 저장한 뒤 다시 업데이트할 수 있습니다. vmess://, vless:// 등으로 시작하는 공유 링크는 보통 하나의 노드만 설명합니다. 단일 노드 링크를 구독 관리에 넣으면 형식 오류가 발생하거나 업데이트 후 목록이 나타나지 않을 수 있고, 구독 주소를 단일 노드 QR 코드로 가져오면 해석되지 않을 수 있습니다. 두 형식의 차이는 공유 링크와 구독 주소 안내에서 확인할 수 있습니다. 점검할 때는 복사한 주소가 완전한지, 메신저에서 줄바꿈되거나 잘리지 않았는지, 끝의 매개변수가 누락되지 않았는지 먼저 확인하세요.

구독 업데이트에는 두 가지 연결이 포함됩니다. 클라이언트가 먼저 구독 서버에 접속해 내용을 가져온 다음, 내용을 해석해 노드를 생성합니다. 다운로드 단계에서 실패하면 DNS, TLS, HTTP 상태 또는 연결 시간 초과가 로그에 자주 나타나고, 다운로드는 성공했지만 해석에 실패하면 지원하지 않는 형식, 빈 데이터 또는 일부 항목 오류가 표시됩니다. 오류가 어느 단계에 속하는지 먼저 기록하면 네트워크 문제를 노드 형식 문제로 잘못 판단하는 일을 피할 수 있습니다.

시스템 프록시와 구독 업데이트 경로 확인

구독 업데이트는 직접 연결을 사용할 수도 있고 현재 프록시를 사용할 수도 있습니다. 프록시 연결이 가능할 때만 접근할 수 있는 구독 주소인데 현재 노드가 이미 만료되었다면 ‘노드를 업데이트하려면 먼저 노드가 필요하다’는 순환이 생깁니다. 이때는 아직 사용할 수 있는 이전 노드로 전환한 뒤 업데이트하거나, 클라이언트의 구독 업데이트 프록시 옵션에서 시스템 프록시·현재 프록시·직접 연결 중 무엇을 사용하는지 확인하세요. 의미를 모른 채 여러 단계의 프록시를 동시에 켜면 요청이 로컬 프록시 포트로 되돌아가 순환할 수 있습니다.

반대로 구독 서버가 직접 연결에서는 열리지만 프록시를 통해서는 실패한다면 잠시 직접 연결로 업데이트하세요. 업데이트가 완료되어도 새 목록에 예상한 노드가 포함되는지 확인하기 전에는 이전 그룹을 삭제하지 마세요. 여러 구독은 ‘모두 업데이트’보다 하나씩 업데이트하는 편이 실패한 주소를 찾기 쉽습니다. 구독 이름은 로컬 레이블일 뿐 연결에는 사용되지 않으며, 실제로 확인할 것은 주소, 업데이트 방식, User-Agent 요구 사항과 반환 내용입니다.

HTTP 상태와 반환 내용으로 원인 찾기

상태 코드는 책임 범위를 빠르게 나누는 데 도움이 됩니다. 401 또는 403은 주소의 토큰, 경로 또는 접근 조건이 더 이상 유효하지 않다는 뜻인 경우가 많고, 404는 링크가 교체되었거나 잘못 복사된 경우가 많습니다. 429는 짧은 시간에 요청이 너무 많다는 뜻이므로 연속 새로 고침을 멈추고 잠시 후 다시 시도하세요. 5xx는 구독 서버의 일시적인 오류이므로 로컬에서 클라이언트를 반복 설치해도 도움이 되지 않습니다. 상태가 200인데 목록이 비어 있다면 반환된 것이 노드 텍스트인지, 웹페이지 안내인지, 로그인 페이지인지 확인하세요. 그래픽 클라이언트에는 ‘해석 실패’만 표시될 수 있지만 상세 로그에서는 응답 유형이나 디코딩 오류를 확인할 수 있습니다.

데스크톱에서는 시스템 기본 도구로 응답 헤더만 확인하고, 전체 구독 내용을 공유 화면이나 공개 로그에 출력하지 마세요. 아래 명령의 주소는 로컬 예시일 뿐 실제 구독 정보가 아닙니다:

curl -I "https://example.invalid/subscription"
nslookup example.invalid

도메인을 해석할 수 없다면 이 페이지의 DNS 절로 이동하고, TLS 오류가 발생하면 시간을 보정한 뒤 인증서 이름을 확인하세요. 응답은 정상인데 클라이언트 해석만 실패한다면 빈 구독 그룹을 새로 만들어 해당 주소만 가져와 오래된 캐시와 중복 노드의 영향을 배제할 수 있습니다. v2rayN·v2rayNG·v2flyNG는 공유 형식 처리 방식에 세부 차이가 있을 수 있으므로, 같은 구독이 클라이언트마다 다르게 보이면 기기 네트워크 문제로 단정하기보다 해당 클라이언트가 인식하지 못하는 확장 필드가 포함되어 있는지 확인하세요.

업데이트 후 노드 목록이 바뀌지 않을 때

업데이트는 성공했지만 목록이 그대로라면 구독이 실제로 같은 내용을 반환했거나, 클라이언트가 사용자 지정 노드 보존·메모 기준 병합·캐시 표시를 사용 중일 수 있습니다. 먼저 노드 수, 메모와 서버 주소를 비교한 뒤 목록 페이지를 완전히 종료하고 다시 들어가세요. 클라이언트에 구독 캐시 삭제 또는 이전 노드 보존 안 함 옵션이 있다면 백업을 확인한 뒤 사용할 수 있습니다. 노드 이름만으로 업데이트 여부를 판단하지 마세요. 제공자가 이름은 유지한 채 주소를 바꾸거나, 이름만 바꾸고 같은 연결 매개변수를 유지할 수 있습니다.

시스템 시간이 잘못되면 HTTPS 구독과 노드 연결이 동시에 실패할 수 있습니다. 가장 놓치기 쉬운 공통 원인입니다. 모든 구독에서 갑자기 인증서 오류가 발생하고 모든 TLS 노드를 사용할 수 없다면 먼저 시간을 동기화한 뒤 클라이언트를 다시 시작하세요. 구독 하나만 실패한다면 해당 주소를 집중적으로 확인합니다. 업데이트가 끝나면 새 노드 하나를 수동으로 선택해 실제 접속을 테스트하고, 자동 선택이 삭제된 노드의 캐시 참조를 계속 사용하지 않도록 하세요.

속도 문제를 지연 시간·처리량·안정성으로 나누어 확인

‘속도가 느리다’는 현상은 최소 세 가지로 나뉩니다. 웹페이지를 처음 여는 데 오래 걸리면 DNS, 연결 설정과 지연 시간 문제일 가능성이 큽니다. 대용량 파일의 지속 다운로드 속도가 낮다면 회선 처리량, 혼잡과 기기 성능에 가깝습니다. 속도가 크게 오르내리거나 동영상이 주기적으로 버퍼링되면 패킷 손실, 무선 간섭, 노드 부하, 프로토콜 재전송과 백그라운드 트래픽을 확인해야 합니다. 한 번 측정한 지연 시간만으로 모든 현상을 설명할 수 없으므로 같은 기기와 로컬 네트워크, 비슷한 시간대에 두 노드를 비교하고 라우팅, DNS와 테스트 대상을 동일하게 유지하세요.

테스트 전 클라우드 동기화, 시스템 업데이트, 게임 플랫폼 다운로드와 다른 기기의 대용량 작업을 일시 중지하세요. 무선 네트워크에서는 라우터 가까이에서 한 번 테스트한 뒤 유선이나 다른 네트워크에서도 다시 확인합니다. 직접 연결 자체가 느리다면 프록시로 로컬 접속 병목을 없앨 수 없습니다. 직접 연결은 안정적인데 모든 노드가 흔들리면 로컬 프록시 경로, MTU, 코어 부하와 네트워크의 UDP 처리를 확인하세요. 특정 노드 하나만 느리다면 노드 회선이나 원격 부하일 가능성이 높습니다.

라우팅으로 우회 경로가 생겼는지 확인

규칙 모드는 도메인, IP, 포트와 프로토콜에 따라 아웃바운드를 선택합니다. 도메인이 로컬에서 특정 IP로 먼저 해석된 뒤 domainStrategy와 규칙 세트가 맞지 않으면 같은 웹사이트의 메인 페이지, 이미지와 동영상이 서로 다른 아웃바운드를 사용해 페이지는 열리지만 미디어가 느려질 수 있습니다. 점검할 때는 잠시 전역 프록시를 사용해 같은 리소스를 비교하세요. 전역 모드가 확실히 개선된다면 규칙 매칭 순서, 도메인 규칙과 IP 규칙의 충돌 여부, DNS 반환 결과가 예상과 맞는지 확인해야 합니다.

라우팅 규칙은 많을수록 좋은 것이 아닙니다. 겹치는 규칙이 많으면 관리가 어려워지고, 오래된 규칙 세트가 새 도메인을 부적절한 아웃바운드로 보낼 수 있습니다. 먼저 클라이언트에 내장된 간단한 규칙 세트로 기본 연결이 안정적인지 확인한 뒤 필요한 사용자 항목을 추가하세요. 매번 한 그룹만 추가하고 로그에서 해당 도메인이 최종적으로 사용한 아웃바운드 레이블을 확인합니다. 애플리케이션이 IP로 직접 연결하면 도메인 규칙이 적용되지 않을 수 있으므로 애플리케이션 특성, 대상 IP 또는 포트에 맞춰 규칙을 설계해야 합니다. 단, 너무 넓은 네트워크 대역을 지정해 관련 없는 트래픽까지 프록시로 보내지 않도록 하세요.

Mux, 동시 연결과 전송 방식의 선택

Mux는 여러 논리 연결이 하나의 하위 연결을 재사용하게 해 특정 고지연 환경에서 반복적인 핸드셰이크를 줄일 수 있지만 처리량 향상을 보장하지는 않습니다. 장시간 대용량 전송에서는 연결 재사용으로 인해 패킷 손실이 여러 요청에 영향을 줄 수 있고, 일부 서버 설정은 클라이언트의 일방적인 활성화에 적합하지 않습니다. 속도를 점검할 때는 먼저 Mux를 끄고 기준값을 만든 뒤 단독으로 켜서 비교하세요. 끈 뒤 더 안정적이면 계속 끄고, 짧은 연결이 많을 때 뚜렷하게 개선된다면 활성화를 검토합니다. Mux, 동시 연결 수, 분할 전송, DNS와 라우팅을 동시에 바꾸면 어떤 변경이 효과를 냈는지 알 수 없습니다.

WebSocket, gRPC, TCP 같은 전송 방식은 서버 설정으로 결정되며 클라이언트에서 임의로 바꾼다고 ‘가속’되지 않습니다. 매개변수가 맞지 않으면 더 빠른 회선이 아니라 즉시 연결 실패로 이어지는 경우가 많습니다. REALITY와 TLS는 핸드셰이크와 보안 전송 조건을 해결하는 기능이지 속도 향상 버튼이 아닙니다. 실제 처리량에 영향을 주는 요소는 로컬 접속 품질, 기기 CPU, 원격 용량, 회선 혼잡, 패킷 손실률, 왕복 시간과 애플리케이션 자체의 동시성 전략입니다.

기기 리소스와 MTU 증상 확인

성능이 낮은 기기에서 고처리량 암호화, 복잡한 규칙 또는 많은 동시 연결을 사용하면 CPU 사용량이 높아질 수 있습니다. 데스크톱에서는 작업 관리자나 시스템 모니터를 함께 확인하고, Android에서는 기기 발열과 백그라운드 제한을 살펴보세요. 속도가 올라갈 때 CPU가 거의 최대치라면 복잡한 라우팅을 줄이고 불필요한 로그와 동시성 기능을 끈 뒤, 다른 코어 클라이언트의 성능을 비교하세요. v2rayNG는 Xray 코어를 사용하고 v2flyNG는 v2fly 코어를 사용하므로 Android에서 비교하기 좋지만, 노드 프로토콜이 해당 코어에서 지원되는지 확인해야 합니다.

MTU 문제는 작은 웹페이지는 열리지만 큰 이미지, 업로드 또는 특정 HTTPS 페이지가 멈추는 형태로 나타나는 경우가 많습니다. VPN, 터널과 일부 광대역 접속이 겹치면 실제 전송 가능한 패킷 크기가 줄어들 수 있습니다. 먼저 네트워크를 바꿔 확인하세요. 같은 기기가 다른 네트워크에서는 완전히 정상이라면 기존 네트워크의 MTU나 라우팅 장비를 점검할 가치가 있습니다. Linux에서는 단편화를 허용하지 않는 ping으로 패킷 크기를 단계적으로 줄여 볼 수 있지만 운영체제마다 매개변수 표기가 다르고 대상의 응답 여부에도 영향을 받으므로 참고 자료로만 사용해야 합니다. 일반적인 속도 변동 때문에 그래픽 클라이언트의 하위 MTU를 바로 바꿀 필요는 없습니다. 증상이 네트워크와 관련 있는지 확인한 뒤 시스템 또는 라우터에서 신중하게 조정하세요.

최종 비교는 같은 파일, 같은 시간대와 최소 몇 분간의 지속 전송을 사용해 평균 속도와 끊김 여부를 기록해야 합니다. 한 번의 최고 속도는 대표성이 없습니다. 노드가 안정적인 것을 확인한 뒤 규칙 모드, 자동 선택과 평소 DNS 설정을 하나씩 복원하고 매번 다시 테스트하세요. 그래야 성능 저하가 노드 때문인지 로컬 설정 때문인지 알 수 있습니다.

DNS 장애의 대표적인 경계 파악

DNS는 도메인을 IP로 변환합니다. 조회에 실패하면 알려진 IP에 직접 접속했을 때는 응답이 오지만 도메인 접속에서는 서버를 찾을 수 없다는 메시지가 나타날 수 있습니다. 적절하지 않은 주소로 해석되면 연결 시간 초과, 인증서 이름 불일치 또는 네트워크마다 같은 사이트의 접속 결과가 달라질 수 있습니다. 모든 웹사이트가 실패한다고 즉시 DNS 문제로 단정하지 마세요. 로컬 프록시 포트, 노드와 시스템 프록시도 전체 연결 실패를 일으킬 수 있습니다. 도메인을 따로 조회하고 클라이언트 DNS 로그를 확인하며 프록시를 끈 전후를 비교하는 것이 더 정확합니다.

데스크톱에서는 nslookup 또는 dig로 기본 조회를 확인할 수 있습니다. 명령 출력의 DNS 서버, 반환 주소와 오류 유형이 단순히 웹페이지가 열리는지보다 유용합니다. 시스템 조회는 성공하지만 프록시를 통한 접속이 실패한다면 Xray 내장 DNS, 라우팅 규칙 또는 브라우저의 보안 DNS가 다른 조회 경로를 사용하고 있을 수 있습니다. 브라우저, 시스템과 클라이언트에서 각각 보안 DNS를 동시에 사용하면 점검이 어려워지므로 명확한 경로 하나만 잠시 남겨 두세요.

nslookup example.com
dig example.com A
dig example.com AAAA

로컬 조회, 원격 조회와 라우팅의 관계 이해

도메인은 프록시에 들어가기 전에 시스템에서 조회할 수도 있고, 프록시 코어의 DNS 모듈에 맡길 수도 있습니다. 전자는 시스템 캐시를 활용하기 쉽지만 로컬 DNS의 영향을 받고, 후자는 도메인과 라우팅 규칙을 더 일관되게 유지할 수 있지만 DNS 아웃바운드와 조회 경로를 올바르게 설정해야 합니다. Xray의 domainStrategy는 라우팅 매칭 시 도메인을 조회할지 결정합니다. AsIs는 가능한 한 원래 도메인으로 처리하고, IPIfNonMatch는 도메인 규칙이 매칭되지 않을 때 IP를 조회해 다시 매칭을 시도합니다. 정책은 규칙 구조에 맞춰 선택해야 하며 복잡할수록 좋은 것은 아닙니다.

아래는 일반 주소를 사용해 필드 관계를 보여 주는 간단한 DNS 구조입니다. 실제 사용 시에는 네트워크 환경과 클라이언트 인터페이스에 맞춰 설정하고, 클라이언트가 자동 생성한 전체 파일을 그대로 덮어쓰지 마세요.

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": ["geosite:geolocation-!cn"]
      },
      "localhost"
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

설정 예시에 사용된 공용 DNS 주소가 모든 네트워크에 적합한 것은 아닙니다. 중요한 것은 조회가 어디에서 시작되고 어느 아웃바운드를 사용하는지, A 레코드와 AAAA 레코드 중 무엇을 반환하는지, 결과가 라우팅에 어떻게 반영되는지를 확인하는 것입니다. 조회가 직접 연결로 전송되는데 현재 네트워크에서 해당 DNS 서비스에 안정적으로 접근하지 못하면 간헐적인 시간 초과가 발생할 수 있습니다. 반대로 조회를 프록시로 보내는데 프록시가 아직 시작되지 않았다면 시작 의존성이 생깁니다. 여러 안내서의 복잡한 설정을 조합하기보다 클라이언트 기본 설정을 유지하는 편이 대개 관리하기 쉽습니다.

캐시 삭제와 IPv6 차이 처리

DNS를 변경한 뒤에도 시스템, 브라우저와 클라이언트가 이전 결과를 계속 저장할 수 있습니다. Windows에서는 ipconfig /flushdns를 실행해 시스템 캐시를 지울 수 있습니다. Linux의 명령은 실행 중인 조회 서비스에 따라 다르고, macOS에서는 네트워크를 다시 연결하거나 해당 조회 서비스를 재시작해 새로 고칠 수 있습니다. 브라우저도 별도의 연결 풀을 유지할 수 있으므로 관련 페이지를 완전히 닫았다가 다시 여세요. 캐시 삭제는 오래된 레코드 문제만 해결할 뿐 잘못된 DNS 라우팅이나 접근할 수 없는 DNS 서버를 고치지는 않습니다.

ipconfig /flushdns
resolvectl flush-caches

IPv6도 자주 발생하는 분기입니다. 도메인이 A와 AAAA 레코드를 모두 반환하면 시스템이나 애플리케이션이 IPv6를 우선 시도할 수 있습니다. 네트워크에 IPv6 주소가 할당되어 있어도 실제 외부 연결이 불안정하면 첫 연결이 지연되거나 일부 도메인이 실패하고, 폴백 후에야 열릴 수 있습니다. DNS가 IPv4 결과만 반환하도록 잠시 설정해 비교할 수 있습니다. 문제가 사라진다면 로컬 IPv6 연결성과 클라이언트 조회 정책을 확인해야 하며, 무작정 새로 고침을 반복하거나 영구적으로 IPv6에 의존해서는 안 됩니다. 반대로 IPv6 네트워크가 정상이라면 무조건 비활성화하면 더 적합한 경로를 잃을 수 있습니다.

FakeDNS의 적용 범위와 비활성화 시점

FakeDNS는 도메인에 예약 주소를 할당한 뒤 연결 단계에서 코어가 원래 도메인을 복원하도록 하여 투명 프록시와 도메인별 분류에 활용됩니다. 일반 DNS를 단순히 대체하는 기능은 아닙니다. 일부 애플리케이션은 반환된 IP를 검사하거나 주소를 캐시한 뒤 프록시를 우회하고, 자체 조회 로직을 직접 사용하기도 합니다. 이 경우 로그인 실패, LAN 기기 접근 불가, 푸시 오류 또는 UDP 애플리케이션 불안정이 발생할 수 있습니다. 이런 경계 사례에서는 먼저 FakeDNS를 끄고 일반 DNS로 기준 상태를 확인하세요. 자세한 원리는 FakeDNS 작동 원리와 적용 사례에서 확인할 수 있습니다.

LAN 호스트 이름이나 프린터, 라우터 관리 주소만 실패한다면 사설 주소와 로컬 도메인이 직접 연결용 로컬 DNS를 사용하도록 하세요. 원격 DNS나 FakeDNS로 보내지 않는 것이 좋습니다. IP로는 접속되지만 로컬 호스트 이름으로는 실패한다면 노드보다 로컬 DNS 또는 멀티캐스트 조회 문제에 가깝습니다. FakeDNS를 끄고 LAN 도메인에 로컬 조회를 사용하며 사설 네트워크 대역은 직접 연결로 두면 더 명확한 기준을 만들 수 있습니다. 시스템 조회, 클라이언트 조회, 브라우저 조회의 세 계층을 차례로 검증하는 편이 공용 DNS를 계속 바꾸는 것보다 충돌 지점을 찾기 쉽습니다.

시스템 프록시와 로컬 인바운드 포트가 일치하는지 확인

시스템 프록시는 본질적으로 프록시 설정을 지원하는 애플리케이션이 로컬 HTTP 또는 SOCKS 수신 대기 포트로 연결하도록 지정하는 기능입니다. 클라이언트 인터페이스에 ‘시스템 프록시 켜짐’이 표시되어도 시스템 설정의 주소와 포트가 현재 코어가 실제로 수신 대기하는 값과 일치하는지 확인해야 합니다. 주소는 보통 루프백 주소이고 포트는 클라이언트 설정에 따라 달라집니다. 로컬 포트를 변경했는데 시스템에 이전 값이 남아 있으면 애플리케이션은 존재하지 않는 포트로 연결합니다. 이전 클라이언트 프로세스가 그 포트를 점유 중이면 트래픽이 잘못된 인스턴스로 들어갈 수도 있습니다.

먼저 클라이언트 로그에서 인바운드가 시작되었는지 확인한 다음 포트 조회 명령으로 수신 대기 프로세스를 검증하세요. 원격 노드 포트와 로컬 프록시 포트를 혼동하지 마세요. 원격 포트는 코어가 서버에 연결할 때 사용하고, 로컬 포트는 브라우저가 클라이언트에 연결할 때 사용합니다. 시스템 프록시에는 로컬 수신 주소만 입력해야 하며 노드 주소를 입력하면 안 됩니다. 변경 후에는 이미 설정된 연결이 이전 경로를 계속 사용하지 않도록 브라우저를 완전히 종료했다가 다시 여세요.

애플리케이션마다 시스템 프록시 지원이 다른 이유 이해

브라우저와 대부분의 데스크톱 네트워크 프로그램은 시스템 프록시를 읽지만 모든 애플리케이션이 따르는 것은 아닙니다. 일부 프로그램은 자체 프록시 설정을 사용하고, 일부 명령줄 도구는 환경 변수를 읽으며, 어떤 애플리케이션은 직접 네트워크 연결을 만듭니다. 따라서 ‘브라우저는 되지만 특정 애플리케이션은 직접 연결된다’고 해서 시스템 프록시 전체가 고장 난 것은 아닙니다. 먼저 시스템 프록시를 확실히 지원하는 브라우저에서 기준을 만든 뒤 대상 애플리케이션이 HTTP, HTTPS 또는 SOCKS 설정을 제공하는지 확인하세요.

명령줄 도구는 보통 환경 변수를 명시적으로 설정해야 합니다. 아래 예시는 HTTP와 HTTPS 요청을 로컬 HTTP 프록시 포트로 보내며, 포트는 클라이언트에 현재 표시된 실제 값으로 바꿔야 합니다. 환경 변수는 현재 터미널 세션과 그 하위 프로세스에만 적용되며 터미널을 닫으면 대개 유지되지 않습니다.

set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809

export http_proxy=http://127.0.0.1:10809
export https_proxy=http://127.0.0.1:10809

SOCKS 프록시는 도메인을 어디에서 조회하는지도 관련됩니다. 일부 도구에서 socks5 표기는 로컬에서 도메인을 조회하지만 socks5h는 도메인 조회를 프록시에 맡깁니다. 명령줄에서 도메인만 실패하고 IP 연결은 된다면 이 차이를 확인할 가치가 있습니다. 애플리케이션 내부와 시스템에 동시에 프록시를 설정하고 투명 프록시까지 같은 트래픽을 가로채게 하지 마세요. 연결이 클라이언트로 중복 유입될 수 있습니다.

PAC, 우회 목록과 규칙 모드 점검

시스템 프록시 모드는 전역, PAC 또는 변경하지 않음일 수 있습니다. PAC는 스크립트로 어떤 주소에 프록시를 사용할지 결정합니다. 스크립트가 업데이트되지 않았거나 오래된 내용이 캐시되었거나 대상 도메인이 규칙에 포함되지 않으면 브라우저는 직접 연결합니다. 전역 시스템 프록시는 시스템 프록시를 지원하는 요청을 클라이언트로 보내지만, 클라이언트에 들어온 뒤에는 Xray 라우팅 규칙의 영향을 받습니다. 따라서 ‘시스템 전역’이 모든 트래픽이 프록시 아웃바운드로 간다는 뜻은 아닙니다. 운영체제 계층과 코어 라우팅 계층을 나누어 관찰하세요.

시스템 우회 목록에는 보통 LAN 주소와 로컬 호스트 이름이 포함됩니다. 목록이 너무 넓으면 일반 도메인도 프록시를 우회할 수 있고, 너무 좁으면 라우터 관리 페이지와 LAN 서비스가 프록시로 전송될 수 있습니다. 루프백 주소와 명확한 사설 네트워크 대역은 남기되, 모호한 와일드카드로 많은 도메인을 한꺼번에 덮지 않는 것이 좋습니다. 회사 환경에서 정책으로 프록시를 일괄 배포하면 클라이언트가 시스템 설정을 계속 덮어쓰지 못할 수 있으므로, 변경 전후 시스템 프록시 값이 자동으로 복원되는지 비교하세요.

종료 후 남은 프록시와 절전 모드 복귀 처리

클라이언트가 비정상 종료되거나 시스템이 프로세스를 강제 종료했거나 기기가 절전 모드에서 복귀한 뒤에는 시스템 프록시가 로컬 포트를 계속 가리킬 수 있지만 해당 코어는 이미 중지되었을 수 있습니다. 이때 시스템 프록시를 따르는 모든 애플리케이션이 실패하고, 시스템 프록시를 끄면 즉시 복구됩니다. 먼저 시스템 네트워크 설정에서 프록시를 끈 다음 클라이언트를 다시 시작하고 클라이언트가 프록시를 다시 활성화하게 하세요. 정상 종료 시에는 보통 복구 작업이 실행되지만 비정상 프로세스가 정리까지 수행한다고 기대해서는 안 됩니다.

Windows에서는 현재 사용자 프록시 설정과 일부 구형 프로그램이 읽는 다른 인터페이스를 구분해야 합니다. macOS에서는 현재 사용 중인 네트워크 서비스의 설정을 수정했는지 확인하세요. Linux 데스크톱 환경에는 시스템 프록시, 데스크톱 프록시와 애플리케이션 환경 변수라는 세 가지 출처가 있을 수 있습니다. 모든 위치에 동시에 입력하지 말고 명확한 한 가지 방식부터 검증하세요. v2rayN의 Linux 데스크톱 설치와 자동 시작을 설정할 때는 Linux 데스크톱 설치 가이드를 참고해 사용자 서비스와 데스크톱 세션이 같은 환경인지 확인할 수 있습니다.

최종 확인에서는 클라이언트 접근 로그에 대상 도메인이 나타나는지 확인해야 합니다. 로그에 아무 기록도 없으면 트래픽이 클라이언트에 들어오지 않은 것이므로 애플리케이션과 시스템 프록시를 계속 점검하세요. 대상 도메인이 로그에 있지만 direct로 처리되면 라우팅 규칙 문제입니다. 프록시로 처리된 뒤 시간 초과가 발생하면 노드와 DNS 절로 돌아가세요. 로그로 문제를 계층화하면 시스템 프록시가 작동하지 않을 때 노드를 반복해서 바꾸는 일을 피할 수 있습니다.

그래픽 인터페이스 충돌과 코어 시작 실패 구분

v2rayN은 그래픽 인터페이스, 설정 데이터와 프록시 코어로 구성됩니다. 창이 열리지 않거나, 열린 직후 사라지거나, 인터페이스는 정상인데 연결 버튼이 작동하지 않는 현상은 서로 다른 계층의 문제일 수 있습니다. 인터페이스를 조작할 수 있지만 로그에 코어 종료가 표시된다면 생성된 설정과 포트를 중점적으로 확인하세요. 프로그램 자체에 창이 나타나지 않는다면 시스템 이벤트, 시작 터미널 출력, 파일 권한과 실행 의존성을 확인해야 합니다. 모든 시작 문제를 노드 탓으로 돌리지 마세요. 손상된 노드는 보통 연결만 실패하게 하며 전체 인터페이스가 표시되지 않게 하지는 않습니다.

점검 전에 관련 프로세스를 완전히 종료한 뒤 한 번 다시 시작하세요. 여러 번 더블클릭하면 여러 인스턴스가 실행되어 설정 파일 잠금이나 로컬 포트 충돌이 발생할 수 있습니다. 데스크톱에서는 작업 관리자나 시스템 모니터로 그래픽 프로세스와 Xray 프로세스가 남아 있는지 확인하세요. 시스템을 재시작한 뒤 복구되더라도 이전 로그에서 포트 점유와 비정상 종료 원인을 확인해 다음 절전 모드 복귀 때 문제가 반복되지 않게 해야 합니다.

첫 번째 설정 오류부터 거슬러 올라가며 확인

코어가 설정을 불러올 때 JSON 구조, 필드 유형, 프로토콜 매개변수와 참조 레이블을 검증합니다. 로그 뒤쪽에 이어지는 많은 종료 메시지는 대개 첫 번째 설정 오류 때문에 발생하므로, 가장 중요한 것은 가장 먼저 나타난 failed to load config, 알 수 없는 필드, 누락된 아웃바운드 레이블 또는 JSON 파싱 위치입니다. JSON을 수동 편집할 때는 쉼표, 따옴표와 괄호에서 가장 자주 오류가 발생합니다. 그래픽 클라이언트가 설정 생성에 실패한다면 사용자 지정 라우팅, DNS 항목 또는 노드 추가 매개변수가 잘못되었을 수 있습니다.

JSON에서는 주석을 사용할 수 없고 마지막 멤버 뒤에 쉼표를 남겨서도 안 됩니다. 문자열의 백슬래시와 큰따옴표는 이스케이프해야 합니다. 아래 구조는 문법이 완전하며 기본 계층을 비교하는 데 사용할 수 있지만 연결 가능한 노드는 포함하지 않습니다:

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "port": 10808,
      "listen": "127.0.0.1",
      "protocol": "socks"
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ]
}

사용자 지정 설정을 활성화한 뒤에만 오류가 발생한다면 먼저 사용자 지정 항목을 끄고 클라이언트가 기본 설정을 다시 생성하게 하세요. 기본 설정으로 시작되는 것을 확인한 뒤 DNS, 라우팅과 아웃바운드를 구간별로 추가합니다. 설정 파일 구조와 각 영역의 역할은 V2Ray JSON 설정 구조 해설에서 확인할 수 있습니다. 다른 클라이언트의 전체 설정을 현재 클라이언트에 그대로 덮어쓰지 마세요. 인터페이스가 자체적으로 생성한 인바운드 레이블, 포트와 관리 인터페이스에 의존할 수 있습니다.

디렉터리 권한, 경로와 보안 프로그램 차단 확인

클라이언트는 설정을 읽고 로그를 기록하며 코어 하위 프로세스를 시작해야 합니다. 설치 디렉터리에 쓰기 권한이 없거나 사용자 디렉터리 권한에 문제가 있거나 경로가 있는 디스크가 읽기 전용이면 시작에 실패합니다. Linux에서는 특히 한 번 관리자 권한으로 시작한 뒤 같은 설정 디렉터리를 일반 사용자로 실행하지 않도록 하세요. 이전에 생성된 파일의 소유자가 관리자로 남을 수 있습니다. 파일 소유자와 권한을 수정한 뒤 일반 데스크톱 사용자로 다시 시작하세요. macOS와 Windows에서는 프로그램 디렉터리가 시스템 보호 정책으로 쓰기 차단되지 않았는지, 보안 프로그램이 코어 파일을 격리하거나 하위 프로세스 실행을 막고 있지 않은지 확인하세요.

경로에 특수 문자가 포함되어도 최신 클라이언트는 대개 처리할 수 있지만 외부 스크립트, 오래된 설정 또는 사용자 지정 명령이 경로를 잘못 나눌 수 있습니다. 비교를 위해 설정 디렉터리를 짧은 사용자 디렉터리로 잠시 옮겨 보세요. 실시간 동기화 디렉터리에 설정을 두고 테스트하지 마세요. 클라이언트가 파일을 쓰는 동안 동기화가 충돌 사본을 만들거나 파일을 잠시 잠글 수 있습니다. 문제가 경로와 관련 있음을 확인한 뒤 원래 위치를 하나씩 복원하세요.

진단 자료를 보존하고 안전하게 설정 재구성

초기화가 필요하다면 먼저 클라이언트를 종료하고 설정 디렉터리를 로컬 백업으로 복사한 다음, 현재 설정 디렉터리의 이름만 바꿔 클라이언트가 새 설정을 생성하게 하세요. 새 설정으로 시작된다면 프로그램 파일과 시스템 실행 환경은 대체로 정상이며 문제는 이전 설정에 있습니다. 이때 구독과 꼭 필요한 규칙만 다시 추가하고 이전 디렉터리 전체를 즉시 덮어쓰지 마세요. 구독, 라우팅, DNS, 인터페이스 설정 순서로 종류별 복원하며 매번 시작 여부를 확인할 수 있습니다.

새 설정으로도 시작되지 않는다면 재설치를 고려하세요. 클라이언트 다운로드 페이지에서 플랫폼과 프로세서에 맞는 v2rayN을 선택하고, Android에서는 v2rayNG를 사용하거나 v2fly 코어가 필요할 때 v2flyNG를 선택하세요. 재설치 전에 로그 오류, 운영체제, 프로세서 아키텍처와 재현 절차를 기록하세요. 이는 ‘시작되지 않음’이라고 표시된 스크린샷 한 장보다 문제를 찾는 데 훨씬 유용합니다. 버전 호환 관계를 추측하거나 만들어 내지 말고 다운로드 페이지에 현재 제공되는 패키지 유형과 시스템 요구 사항을 기준으로 판단하세요.

특정 노드를 가져온 뒤 충돌이 발생한다면 새 설정에서 다른 노드를 먼저 가져온 다음 의심스러운 링크만 따로 가져오세요. 특정 DNS나 라우팅 기능을 켠 뒤 발생했다면 기본 설정을 유지한 채 항목별로 재현합니다. ‘어떤 항목을 추가한 뒤 실패하기 시작했는지’를 확인하면 시스템, 클라이언트와 구독을 동시에 바꾸지 않고도 문제를 구체적인 설정으로 좁힐 수 있습니다.

VPN 권한과 시스템의 단일 연결 인스턴스 확인

v2rayNG와 v2flyNG는 Android에서 보통 시스템 VPN 인터페이스를 통해 트래픽을 가로챕니다. 처음 연결할 때는 시스템 권한 승인을 확인해야 합니다. 승인 창을 취소하면 클라이언트가 노드를 저장할 수는 있어도 VPN을 만들 수 없습니다. 상태 표시줄의 VPN 아이콘은 인터페이스가 생성되었다는 뜻일 뿐이므로 로그에서 코어와 노드 연결 성공 여부를 확인해야 합니다. 시스템에는 일반적으로 한 번에 하나의 VPN 서비스만 유지되며, 다른 VPN 애플리케이션, 업무 프로필 관리 도구 또는 시스템 네트워크 기능이 인터페이스를 차지하면 연결 직후 끊길 수 있습니다.

점검할 때는 다른 VPN 기능을 먼저 끄고 v2rayNG 또는 v2flyNG를 완전히 중지한 뒤 다시 열어 권한을 승인하세요. 두 클라이언트를 동시에 자동 연결 상태로 두지 마세요. 클라이언트를 바꾼 뒤에도 이전 VPN 아이콘이 사라지지 않으면 시스템 네트워크 설정에서 현재 VPN을 끊은 다음 대상 클라이언트를 시작하세요. 노드가 데스크톱에서는 작동하지만 Android에서 즉시 실패한다면 Android로 가져온 뒤의 프로토콜, 전송 방식, 보안 방식, 서버 이름과 경로를 먼저 비교하고 QR 코드나 클립보드 내용이 잘리지 않았는지 확인하세요.

배터리 절전 정책과 백그라운드 제한 처리

화면이 꺼진 뒤 몇 분 후 연결이 끊기고 다시 켜면 복구된다면 대개 백그라운드 제한과 관련이 있습니다. Android 제조사의 절전 정책은 클라이언트 프로세스를 일시 중지하거나 백그라운드 네트워크를 제한하고, 오래 실행되는 VPN 서비스를 정리할 수 있습니다. 시스템 앱 설정에서 클라이언트의 백그라운드 실행을 허용하고 해당 클라이언트의 배터리 최적화를 해제하며 필요한 자동 시작이나 백그라운드 활동을 허용하세요. 기기마다 메뉴 이름은 다르지만 기준은 같습니다. 화면이 잠긴 뒤에도 클라이언트가 실행되어야 하고 시스템에서 제한 앱으로 분류되지 않아야 합니다.

클라이언트를 최근 앱 목록에 남겨 두는 것만으로는 충분하지 않을 수 있습니다. 일부 시스템의 ‘작업 잠금’도 백그라운드 네트워크 권한과는 다릅니다. 조정한 뒤 화면을 잠근 채 잠시 기다리고, 메시지 동기화, 웹 요청 또는 클라이언트 로그로 연결이 유지되는지 확인하세요. 모바일 네트워크에서 Wi-Fi로 전환할 때만 끊긴다면 네트워크 변경 후 기존 연결이 제때 재구성되지 않은 것일 수 있습니다. 클라이언트로 돌아가 수동으로 중지했다가 다시 시작해 재연결 문제인지 판단하세요. 네트워크를 자주 전환한다면 시스템 상시 연결 VPN, 다른 자동화 네트워크 도구와 클라이언트 자체 자동 연결을 동시에 사용하지 마세요.

애플리케이션 분할 라우팅과 우회 설정 점검 순서

Android 클라이언트에서는 애플리케이션별로 어떤 트래픽을 VPN에 넣을지 정할 수 있습니다. 설정 방향은 혼동하기 쉽습니다. 어떤 화면은 ‘선택한 앱만 프록시’를 뜻하고, 어떤 화면은 ‘선택한 앱 우회’를 뜻합니다. 의미를 반대로 이해하면 브라우저는 정상인데 대상 앱은 직접 연결되거나, 일부 앱만 인터넷에 연결됩니다. 먼저 애플리케이션 분할을 끄고 모든 앱을 같은 VPN 경로로 보내 노드와 DNS가 정상인지 확인하세요. 그다음 분할을 다시 켜고 테스트 앱 하나만 선택합니다.

시스템 앱, 업무 프로필의 앱과 일반 사용자 앱은 서로 다른 설정 범위에 속할 수 있습니다. 대상 앱이 시스템 구성 요소를 호출해 웹페이지를 열면 주 앱과 시스템 구성 요소가 서로 다른 경로를 사용해 로그인 페이지와 본문 연결 결과가 달라질 수 있습니다. 이때 클라이언트 로그에 대상 도메인이 나타나는지 함께 확인하고 관련 시스템 구성 요소가 분할 규칙에서 제외되지 않았는지 점검하세요. 처음부터 많은 앱 목록을 추가하지 마세요. 목록이 길수록 실제 적용 방향을 판단하기 어려워집니다.

LAN 접근, 핫스팟 공유와 DNS 차이 해결

VPN을 켠 뒤 라우터, LAN 저장 장치 또는 프린터에 접속할 수 없다면 ‘LAN 우회’ 또는 사설 주소 직접 연결 규칙을 확인하세요. LAN 주소는 보통 원격 노드로 보내지 않아야 합니다. IP로는 접속되지만 로컬 호스트 이름으로는 실패한다면 노드보다 로컬 DNS 또는 멀티캐스트 조회 문제에 가깝습니다. FakeDNS를 끄고 LAN 도메인에 로컬 조회를 사용하며 사설 네트워크 대역은 직접 연결로 두면 더 명확한 기준을 만들 수 있습니다.

기기 핫스팟 공유는 별도의 네트워크 전달 계층이므로 휴대폰 핫스팟에 연결한 기기가 휴대폰의 VPN을 자동으로 사용하는 것은 아닙니다. 휴대폰 브라우저가 클라이언트를 통해 연결되어도 핫스팟에 연결된 기기는 별도의 외부 경로를 사용할 수 있습니다. 휴대폰 상태 표시줄만 보고 공유 기기의 경로를 판단하지 말고 하위 기기에서 따로 확인하세요. 휴대폰 앱만 처리하면 된다면 핫스팟을 끄는 것이 변수를 줄입니다. 공유 트래픽을 처리해야 한다면 클라이언트와 시스템이 해당 기능을 지원하는지 확인해야 하며, 일반 VPN 모드의 동작을 핫스팟에도 그대로 적용해서는 안 됩니다.

Android의 비공개 DNS와 클라이언트 DNS가 동시에 사용될 수 있습니다. 비공개 DNS에 접근할 수 없으면 일부 앱이 계속 대기할 수 있고, 클라이언트에서 FakeDNS나 원격 DNS를 활성화하면 시스템 정책과 서로 다른 조회 결과가 발생할 수 있습니다. 점검할 때는 비공개 DNS를 시스템 자동으로 되돌리고 클라이언트의 고급 DNS를 끈 뒤 기본 설정만 남기세요. 기본 연결이 복구된 뒤 실제 필요에 따라 항목을 하나씩 켭니다. 특정 앱 하나만 실패한다면 앱 내장 DNS, QUIC 또는 인증서 고정도 고려해야 하며 모든 차이를 클라이언트 오류로 돌려서는 안 됩니다.

로그를 수집하고 두 Android 클라이언트를 비교

문제를 재현하기 전에 현재 로그 위치를 비우거나 기억한 다음, 연결을 끊었다가 다시 연결하거나 실패하는 도메인을 열거나 화면을 잠근 채 기다리는 등 명확한 작업을 한 번 수행하세요. 첫 번째 오류, 사용한 네트워크 유형, 애플리케이션 분할 사용 여부, DNS 모드와 노드 프로토콜을 기록합니다. 로그에 대상 요청이 전혀 없으면 애플리케이션 분할을 확인하고, 요청은 있지만 조회에 실패하면 DNS를 확인하세요. 노드 연결이 시간 초과되면 주소, 포트와 네트워크로 돌아가고, 화면을 잠근 뒤 코어 로그가 멈추면 백그라운드 제한을 중점적으로 확인합니다.

v2rayNG는 Xray 코어를 사용하는 Android 우선 클라이언트이고, v2flyNG는 v2fly 코어를 사용해 프로토콜 호환성과 실행 동작을 비교할 수 있습니다. 비교 테스트에서는 지원되는 동일한 노드를 가져오고 DNS, 라우팅과 분할 설정을 최대한 단순하게 유지하세요. 두 클라이언트가 같은 네트워크에서 모두 실패하지만 다른 네트워크의 데스크톱에서는 정상이라면 Android의 네트워크를 바꿔 다시 테스트하세요. 한 클라이언트에서만 실패한다면 코어 지원 범위와 생성된 설정을 비교합니다. 클라이언트, 노드와 네트워크를 동시에 바꾸면 결과로 원인을 설명할 수 없습니다.

점검이 끝나면 필요한 백그라운드 권한, 애플리케이션 분할과 DNS 설정을 복원하고 항목별로 확인하세요. 장기간 안정적인 설정은 실험 옵션을 많이 쌓은 설정보다 관리하기 쉽습니다. 처음 설정하는 단계는 사용 안내로 돌아가 다시 확인하고, 인증서 핸드셰이크 오류는 TLS 및 인증서 오류 점검 목록을 계속 참고하세요.