V2Ray 클라이언트 문제 해결 증상별 원인 찾기

01 / 점검 기준변수를 고정한 뒤 단계별로 배제

문제 해결에서 가장 흔한 실수는 여러 설정 항목을 한꺼번에 바꾸는 것입니다. 노드, 프로토콜, 라우팅, DNS를 동시에 바꾸면 연결이 복구되더라도 어떤 항목이 효과를 냈는지 알 수 없습니다. 이 페이지의 모든 장은 같은 순서를 따릅니다. 현재 환경을 먼저 고정하고, 연결 경로를 여러 구간으로 나눈 뒤 클라이언트에 가장 가까운 구간부터 검증하고, 한 구간이 통과된 것을 확인한 다음 다음 구간을 봅니다.

완전한 프록시 경로는 여섯 구간으로 나눌 수 있습니다. 앱의 요청 발생, 로컬 인바운드 포트, 로컬 코어 프로세스, 아웃바운드 연결(프로토콜과 전송 방식), 원격 서버, 대상 사이트입니다. 각 구간에는 독립적으로 검증할 수 있는 점검 지점이 있으며, 아래 표에 함께 정리했습니다. 이후 장의 점검 작업은 모두 이 구간들을 기준으로 진행됩니다.

시작하기 전에 네 가지 정보를 고정

1. 클라이언트와 코어 버전 — v2rayN 로그 첫 줄에 코어 이름과 버전이 출력됩니다. 코어(V2Fly와 Xray)에 따라 같은 설정의 지원 범위가 다르므로, 필드 오류가 나면 먼저 코어를 확인하세요.
2. 로컬 인바운드 포트 — 설정에서 SOCKS와 HTTP 포트가 각각 무엇인지 기록해 두세요. 이후 모든 명령줄 검증에 이 두 포트가 필요합니다.
3. 현재 아웃바운드 파라미터 — 프로토콜(VLESS, VMess, Trojan 등), 전송 방식(tcp, ws, grpc), TLS 사용 여부, SNI 또는 Host 값.
4. 시스템 프록시와 TUN 상태 — 클라이언트가 운영체제에 프록시를 기록했는지, 또는 TUN 모드로 전체 트래픽을 가로채는지 확인하세요. 두 모드는 대처 방향이 완전히 다릅니다.

함께 점검 노트를 준비해 재현 시각, 당시 네트워크 환경(Wi-Fi인지 유선인지, 네트워크를 전환했는지), 변경한 설정 항목을 기록하세요. 될 때도 있고 안 될 때도 있는 문제는 대부분 이 노트만으로 규칙을 찾을 수 있습니다. 예를 들어 특정 네트워크에서만 나타나거나, 절전 모드에서 깨어난 뒤에만 나타나는 경우입니다.

로그 레벨을 높이고 한 번 재현

기본 로그 레벨은 보통 경고만 출력해 정보가 충분하지 않습니다. 장애를 재현하기 전에 레벨을 info 또는 debug로 올리고, 한 번 재현한 뒤 바로 되돌려 로그 파일이 계속 커지는 것을 막으세요. 로그는 각 줄에 타임스탬프가 있어 시스템 이벤트와 초 단위로 대조할 수 있습니다. 로그 구조와 자주 나오는 오류를 읽는 방법은 v2rayN 실행 로그 보는 방법에서 자세히 다룹니다.

명령줄로 코어 단독 실행

클라이언트 화면의 로그 패널은 본질적으로 코어 프로세스의 표준 출력입니다. 설정을 config.json으로 내보낸 뒤 명령줄에서 직접 한 번 실행하면 UI 계층의 간섭을 배제할 수 있습니다:

# Xray 코어: 설정만 검증하고 서비스는 시작하지 않음
xray run -test -config config.json

# Xray 코어: 포그라운드로 실행, 로그를 터미널에 바로 출력
xray run -config config.json

V2Fly 코어는 명령을 v2ray test -config config.json과 v2ray run -config config.json으로 바꾸면 되며, 파라미터 의미는 같습니다.

마지막 판단 원칙입니다. 같은 구독의 여러 노드가 동시에 타임아웃되면 로컬 네트워크, 구독 자체, 클라이언트 설정을 먼저 의심하세요. 일부 노드만 타임아웃되면 해당 노드의 서버와 회선을 먼저 의심하세요. 이 원칙에 따라 03장으로 갈지 04장으로 갈지가 정해집니다.

02 / 증상 1연결됨으로 표시되지만 웹페이지가 안 열림

클라이언트의 '연결됨' 표시는 로컬 코어 프로세스가 정상 시작되고 인바운드 포트가 수신 대기를 시작했다는 뜻일 뿐, 데이터가 아웃바운드를 거쳐 대상 사이트까지 도달한다는 의미는 아닙니다. 이 증상은 범위가 가장 넓어서, 아래 네 단계를 따르면 문제를 특정 구간으로 좁힐 수 있습니다.

1단계: 로컬 포트 수신 대기 확인

# macOS / Linux
lsof -nP -iTCP:10808 -sTCP:LISTEN

# Windows
netstat -ano | findstr "10808"

출력이 전혀 없다면 인바운드가 시작되지 않은 것입니다. 클라이언트 프로세스가 실제로 실행 중인지, 설정의 인바운드 포트를 다른 프로그램이 점유하고 있지 않은지 확인하세요. 처리 방법은 07장을 참고하세요.

2단계: curl로 브라우저를 거치지 않고 프록시 직접 테스트

curl -x socks5h://127.0.0.1:10808 -I https://www.example.com
curl -x http://127.0.0.1:10809 -I https://www.example.com

두 명령으로 SOCKS와 HTTP 인바운드를 각각 테스트합니다. 결과 대조:

• 둘 다 응답 헤더를 반환: 프록시 경로는 정상이며 문제는 브라우저나 시스템 프록시 계층에 있으므로 07장으로 이동합니다.
• 둘 다 실패: 아웃바운드나 원격 서버에 문제가 있으므로 03장으로 이동합니다.
• 하나만 통과: 해당 포트의 인바운드 설정이나 프로토콜 유형에 문제가 있으므로, 설정에서 두 인바운드가 모두 활성화되어 있는지 확인하세요.

socks5h의 h는 도메인 해석을 프록시에 맡긴다는 뜻이고, h가 없으면 로컬에서 먼저 IP로 해석한 뒤 프록시에 넘깁니다. 테스트할 때 socks5h를 쓰면 로컬 DNS의 간섭을 배제할 수 있습니다. 두 방식의 차이는 06장에서 다룹니다.

3단계: 라우팅 규칙이 대상을 직접 연결로 보냈는지 확인

클라이언트의 흔한 분기 프리셋에는 보통 '도메인 지역별 분기' 규칙이 들어 있습니다. 대상 도메인이 직접 연결로 판정되었는데 직결 회선 자체가 막혀 있으면, 브라우저에서는 '프록시가 적용되지 않은' 것과 똑같이 보입니다. 확인 방법은 로그 레벨을 info로 올리고 대상 사이트에 접속한 뒤, 로그에서 해당 요청의 아웃바운드 태그가 직접 연결인지 프록시인지 보는 것입니다.

오판으로 확인되면 두 가지 방법이 있습니다. 라우팅 설정에서 해당 도메인을 프록시 규칙에 추가하거나, 기본 아웃바운드를 임시로 프록시로 바꿔 규칙 때문인지 검증하는 것입니다. 참고할 수 있는 규칙 골격:

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      { "type": "field", "domain": ["geosite:cn"], "outboundTag": "direct" },
      { "type": "field", "domain": ["geosite:geolocation-!cn"], "outboundTag": "proxy" }
    ]
  }
}

규칙은 위에서 아래로 매칭되며 먼저 일치한 것이 적용되므로, 더 구체적인 항목을 앞에 써야 합니다. 이 주제는 라우팅 규칙 설정 실전에서 더 자세히 다룹니다.

4단계: 직접 연결과 비교해 대상 사이트 자체 문제 배제

프록시를 거치지 않는 네트워크로 같은 사이트에 접속해 보세요. 직접 연결로도 안 열린다면 문제는 클라이언트에 있지 않으므로 설정을 더 고칠 필요가 없습니다. 단순해 보이지만 '한참 점검했더니 상대 사이트 장애였던' 상황을 상당 부분 걸러 줍니다.

03 / 증상 2노드 타임아웃과 핸드셰이크 실패

이 유형의 공통점은 로컬 코어는 작동하지만 데이터가 나가지 못한다는 것입니다. 로그에 명확한 오류 줄이 남으므로, 키워드로 분류한 뒤 확인 방향을 정하는 편이 설정을 하나씩 바꾸는 것보다 훨씬 빠릅니다.

로그 키워드 대조표

연결성 테스트를 먼저, 설정은 그다음 의심

# Linux / macOS: TCP 포트 연결 수립 여부 테스트
nc -vz 203.0.113.10 443

# Windows PowerShell
Test-NetConnection -ComputerName 203.0.113.10 -Port 443

예시의 주소는 문서용 주소 대역에서 가져온 것이며, 실제로 사용할 때는 자신의 노드 서버 주소와 포트로 바꾸세요. 결과 판단:

• 포트 연결 실패: 서버가 수신 대기하지 않거나, 서버 방화벽에서 차단했거나, 회선 차원에서 도달할 수 없는 경우입니다. 서버 상태를 먼저 확인한 뒤 포트나 회선 교체를 고려하세요.
• 포트는 통과하는데 클라이언트가 계속 타임아웃: 클라이언트에 입력한 주소가 도메인인지 IP인지 확인하세요. 도메인이라면 해석 단계에 문제가 있을 수 있으므로 06장으로 이동합니다.
• ICMP ping 실패가 포트 연결 실패를 뜻하지는 않습니다. 대부분의 서버는 기본적으로 ping에 응답하지 않으므로 TCP 테스트 결과를 기준으로 판단하세요.

인증 파라미터와 시간 오차

VMess 프로토콜은 인증에 타임스탬프를 사용하므로, 클라이언트와 서버의 시간 오차가 허용 범위를 넘으면 바로 거부됩니다. 시스템 시간의 자동 동기화가 켜져 있는지 확인하세요. 가상 머신이나 듀얼 부팅 기기는 오래 절전 상태를 유지한 뒤 시간이 어긋나는 경우가 흔합니다. UUID, 비밀번호 같은 자격 증명 필드는 대소문자를 구분하므로 복사할 때 끝부분 문자가 빠지기 쉽습니다.

TLS와 전송 파라미터

• TLS를 사용하는 노드는 SNI가 서버 인증서와 일치해야 하며, 잘못 입력하면 핸드셰이크 실패가 발생합니다.
• REALITY 노드는 올바른 serverName과 공개 키(publicKey)가 모두 필요하며 하나라도 빠지면 안 됩니다. 이 두 파라미터의 원리는 REALITY와 XTLS Vision 해설에서 확인할 수 있습니다.
• 전송 방식이 ws 또는 grpc일 때 path와 host는 서버와 일치해야 하며 대소문자도 구분합니다.
• 전송 계층의 host 필드와 TLS의 SNI는 서로 다른 파라미터이므로 섞어 넣지 마세요.

여러 노드가 동시에 타임아웃되고 연결성 테스트도 모두 실패한다면 의심 대상을 개별 노드에서 로컬 네트워크 출구나 구독 자체로 옮기세요. 특정 노드만 정해진 시간대에 타임아웃된다면 시간 패턴을 기록한 뒤 서비스 제공자에게 문의해 확인하세요.

04 / 증상 3구독 업데이트 실패와 노드 목록 이상

구독은 노드 목록의 원천입니다. 업데이트 실패는 노드가 전부 사라지거나, 목록이 예전 내용에 머물거나, 업데이트 버튼이 돌다가 오류 메시지를 띄우는 형태로 나타납니다. 구독 내용 자체를 가져올 수 있는지 먼저 확인하고 클라이언트 쪽을 나중에 보세요. 순서를 바꾸지 마세요.

1단계: 명령줄에서 구독을 직접 한 번 가져오기

curl -L -A "v2rayN" -o sub.txt "https://example.com/api/v1/client/subscribe?token=xxxx"
head -c 300 sub.txt

첫 번째 명령은 구독 내용을 파일로 저장하고, 두 번째 명령은 반환 형태를 판단하기 위해 앞 300자만 출력합니다:

• base64 문자열이 반환됨: 정상적인 노드 목록 인코딩이며 문제는 클라이언트 쪽에 있습니다.
• HTML 페이지가 반환됨: 구독 주소가 만료되었거나, 요청이 중간 계층에서 차단된 뒤 오류 페이지로 넘어간 경우입니다.
• 404 또는 403 반환: 주소가 만료되었거나 token이 틀렸거나, 서버가 User-Agent를 제한한 경우입니다. 예시의 -A "v2rayN"은 User-Agent를 지정하는 옵션이며, 일부 서버는 이를 기준으로 요청 출처를 구분합니다.

구독을 업데이트하려면 먼저 노드가 필요함

구독 서버가 프록시를 통해서만 도달할 수 있는 네트워크에 있는데 클라이언트에 쓸 수 있는 노드가 하나도 없다면 '노드 없음 → 구독 업데이트 불가 → 노드 더 없음'의 악순환에 빠집니다. 해결 방법은 두 가지입니다. 구독 설정에서 '프록시를 통해 구독 업데이트'를 켜고 사용 가능한 노드를 먼저 수동으로 하나 가져오거나, 구독 서버에 직접 연결할 수 있는 네트워크에서 한 번 업데이트를 마친 뒤 노드를 가져오고 네트워크를 바꾸는 것입니다.

업데이트 후 노드가 줄거나 사라짐

• 그룹 필터: 이름이나 지역으로 걸러내는 그룹을 설정했는지 확인하세요. 필터에 걸린 노드는 표시되지 않습니다.
• 덮어쓰기: 일부 클라이언트는 구독 업데이트 시 해당 그룹 내용을 통째로 교체하므로, 수동으로 추가한 노드는 별도 그룹에 넣어 덮어써지지 않게 하세요.
• 중복 제거 병합: 같은 서버의 여러 회선이 가져오기 후 하나로 합쳐질 수 있으며, 개수가 줄어드는 것은 정상입니다.
• 서버 측 변경: 구독 내용 자체가 바뀐 경우이므로 가장 최근에 가져온 결과를 기준으로 하세요.

자동 업데이트와 수동 업데이트의 차이

설정의 업데이트 간격이 자동 업데이트 주기를 결정합니다. 수동 업데이트에는 보통 두 가지 경로가 있습니다. 전체 업데이트는 노드 목록을 다시 가져와 덮어쓰고, 구독 내용만 새로 고치는 방식은 현재 선택된 노드를 바꾸지 않으므로 연결이 안정적일 때 현상을 유지하기에 적합합니다. 점검 중에는 자동 업데이트를 꺼 두어 백그라운드 작업이 판단을 흐리지 않게 하는 것이 좋습니다.

05 / 증상 4연결은 되지만 느리고 자주 끊김

'느림'에는 적어도 네 가지 양상이 있습니다. 핸드셰이크 지연(페이지가 열리기 전 대기가 김), 대역폭 부족(다운로드 속도가 안 나옴), 지터(빠를 때와 느릴 때가 반복됨), 연결 끊김(세션이 중단됨)입니다. 네 가지는 대처 방향이 다르므로 먼저 자신의 상황을 맞춰 본 뒤 손을 대세요.

또한 자주 보이는 세 가지 지연 수치를 구분해야 합니다. ping은 ICMP 왕복을, 실제 연결 지연은 프록시 경로 수립 시간을, 다운로드 속도 측정은 실제 처리량을 측정합니다. 세 가지는 측정 대상이 달라 서로 대체할 수 없습니다. 지연 테스트 세 가지 수치 비교에서 각 수치의 적용 상황과 흔한 오해를 정리했습니다.

직접 연결 비교를 먼저

같은 기기, 같은 시간대에 프록시를 거치지 않고 같은 지역의 대용량 파일 다운로드 주소에 접속해 속도를 기록하세요. 직접 연결 자체가 불안정하다면 문제는 로컬 네트워크나 통신사 출구에 있으므로 클라이언트를 계속 조정해도 의미가 없습니다.

트래픽이 실제로 프록시를 거치는지 확인

로그에서 대상 도메인의 아웃바운드 태그를 확인하세요. 속도가 느린 이유가 규칙 때문에 대상이 직접 연결로 빠졌고 그 직결 회선이 마침 혼잡해서인 경우, '프록시가 느리다'고 보이기 쉽습니다.

전송 방식과 멀티플렉싱

• 멀티플렉싱(mux): 여러 연결을 하나의 TCP로 합치는 방식으로, 패킷 손실이 적은 회선에서는 핸드셰이크 부담을 줄여 줍니다. 손실이 많은 회선에서는 연결 하나에 문제가 생기면 그 위에 묶인 모든 요청이 느려집니다. 켜고 끈 상태를 비교 테스트해 보세요.
• 전송 방식: tcp가 가장 직접적이고, ws와 grpc는 특정 네트워크 환경에서 더 안정적이지만 캡슐화 계층이 하나 늘어 추가 부담이 생깁니다.
• 암호화 알고리즘: 성능이 낮은 기기에서는 알고리즘에 따라 처리량 차이가 뚜렷하므로, 바꿔 보고 비교해 볼 수 있습니다.

MTU와 단편화

큰 패킷이 회선에서 버려지면 '웹페이지는 열리는데 다운로드가 멈춘다'거나 '동영상 버퍼링이 길다'는 형태로 나타납니다. 클라이언트나 시스템 수준에서 MTU를 8~16바이트씩 단계적으로 줄이며 개선되는지 확인해 보세요. 조정 후에는 다시 연결해야 적용됩니다.

연결 끊김의 흔한 원인

• 서버 부하 변화 또는 회선 전환;
• 로컬 네트워크 전환: Wi-Fi와 유선 간 전환, 이동통신 기지국 전환;
• 시스템이 절전에서 깨어난 뒤 프록시 프로세스 상태가 어긋나 재연결이 필요함;
• 오래 유휴 상태인 연결을 중간 장비가 정리해 끊기며, 재연결하면 복구됨.

06 / 증상 5일부 도메인 해석 오류

이 유형의 전형적인 양상은 대부분의 사이트는 정상인데 특정 도메인만 안 열리거나, 해석된 IP가 실제와 다르거나, 특정 지역 사이트 접속 시 지연이 눈에 띄게 높은 것입니다. 공통점은 '도메인이 IP로 바뀌는' 단계에서 문제가 생긴다는 점입니다.

도메인이 어디에서 해석되는가

SOCKS 프록시를 사용할 때 도메인 해석 위치는 클라이언트 설정에 따라 달라집니다:

• socks5h(h 포함) 또는 도메인 스니핑 사용: 도메인을 코어가 DNS 설정에 따라 해석;
• socks5(h 없음): 로컬에서 먼저 IP로 해석한 뒤 프록시에 넘기므로, 로컬 DNS 문제가 그대로 프록시 경로에 들어옵니다.

점검할 때 socks5h로 먼저 테스트하면 '로컬 DNS 문제'와 '프록시 경로 문제'를 빠르게 구분할 수 있습니다.

클라이언트 DNS 설정 조정

{
  "dns": {
    "servers": [
      { "address": "1.1.1.1", "domains": ["geosite:geolocation-!cn"] },
      { "address": "223.5.5.5", "domains": ["geosite:cn"] }
    ]
  }
}

이 설정은 지역별로 다른 DNS 서버를 사용하게 해, 지역을 넘나드는 해석에서 생기는 추가 지연을 줄여 줍니다. 수정 후에는 코어 프로세스를 다시 시작해야 적용됩니다.

라우팅 규칙이 매칭되려면 도메인 정보가 필요

도메인 기반 라우팅 규칙은 도메인을 먼저 확보해야 합니다. 트래픽이 IP 형태로 코어에 들어오면 도메인 규칙이 매칭되지 않아 요청이 기본 아웃바운드로 떨어집니다. 도메인 스니핑(sniffing)을 켜면 코어가 HTTP 요청과 TLS 핸드셰이크 정보에서 도메인을 복원할 수 있습니다:

{
  "inbounds": [
    {
      "tag": "socks-in",
      "port": 10808,
      "listen": "127.0.0.1",
      "protocol": "socks",
      "sniffing": { "enabled": true, "destOverride": ["http", "tls"] },
      "settings": { "udp": true }
    }
  ]
}

스니핑을 켜야 도메인 규칙과 도메인 분기가 의도대로 작동합니다. 규칙을 '분명히 썼는데 적용되지 않는다'면 스니핑이 켜져 있는지 먼저 확인하세요.

개별 도메인만 지정해 수정

특정 도메인만 해석이 이상하다면 hosts 설정에 올바른 주소를 고정해 두거나, DNS 설정에서 그 도메인만 별도 서버를 지정할 수 있습니다. 변경 범위가 작을수록 효과를 확인하기 쉽고 새로운 문제를 끌어들이기 어렵습니다.

시스템 DNS 캐시 초기화

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux(systemd-resolved)
sudo resolvectl flush-caches

07 / 증상 6시스템 프록시 미적용과 포트 점유

전형적인 양상은 클라이언트는 연결됨으로 표시되고 브라우저는 페이지가 안 열리는데, 명령줄에서 curl로 로컬 프록시를 거치면 통과하는 경우입니다. 이는 프록시 경로 자체에는 문제가 없고, 시스템 프록시가 기록되지 않았거나 잘못된 위치에 기록되었거나 포트가 맞지 않는다는 뜻입니다.

플랫폼별 시스템 프록시 확인 위치

시스템 프록시가 기록되지 않는 흔한 원인

• 클라이언트 권한이 부족해 시스템 프록시 설정을 바꿀 수 없음;
• 다른 프록시류 프로그램이 실행 중이라 같은 설정을 선점함;
• 브라우저가 자체 프록시 설정이나 프록시 확장을 사용해 시스템 설정을 무시함;
• 시스템 프록시는 시스템 설정을 읽는 앱에만 영향을 주며, 일부 앱은 TUN 모드여야 트래픽을 가로챌 수 있습니다.

TUN 모드와 시스템 프록시의 차이

포트 점유

# Windows: 포트를 점유한 프로세스 번호 확인
netstat -ano | findstr ":10808"
tasklist | findstr "<PID>"

# macOS / Linux
lsof -nP -iTCP:10808 -sTCP:LISTEN

점유 프로세스를 찾았다면 종료하거나, 클라이언트 인바운드 포트를 사용 중이 아닌 다른 포트로 바꾸세요.

포트를 바꾼 뒤 해야 할 전체 순서

1. 클라이언트 설정에서 인바운드 포트를 수정하고 저장;
2. 시스템 프록시 스위치를 껐다가 다시 켜서 새 포트가 시스템에 기록되게 함;
3. 시스템 설정에서 프록시 주소와 포트가 일치하는지 확인;
4. curl로 새 포트를 거쳐 한 번 검증해 경로가 원활한지 확인.

08 / 증상 7클라이언트 실행 실패와 설정 손상

더블클릭해도 반응이 없거나, 실행 직후 종료되거나, 화면은 정상인데 코어가 반복 재시작되는 형태로 나타납니다. 먼저 '클라이언트 화면이 뜨지 않는 것'인지 '코어 프로세스가 뜨지 않는 것'인지 구분하세요. 점검 방향이 다릅니다.

설정 문법부터 검증

# Xray 코어: 설정만 검증하고 서비스는 시작하지 않음
xray run -test -config config.json

# V2Fly 코어
v2ray test -config config.json

자주 나오는 오류와 의미:

• invalid character: JSON에 잘못된 문자가 있음. 흔한 원인은 불필요한 쉼표, 주석, 잘못된 따옴표입니다;
• unexpected end of JSON input: 괄호나 따옴표가 닫히지 않음;
• unknown field: 필드 이름을 잘못 썼거나 현재 코어가 해당 필드를 지원하지 않습니다.

설정에 주석이나 끝에 남은 쉼표가 있으면 파싱이 실패합니다. 다른 곳에서 설정 조각을 복사할 때 이런 문제가 가장 쉽게 따라옵니다.

코어가 반복 재시작

화면에는 실행 중으로 표시되지만 로그에서 코어 프로세스가 반복적으로 시작과 종료를 되풀이한다면, 보통 설정 검증 실패이거나 포트가 점유된 경우입니다. 먼저 로그 레벨을 debug로 올리고 종료 직전 마지막 줄을 확인한 뒤, 03장과 07장의 절차에 따라 처리하세요.

권한과 경로

• 설치 디렉터리가 시스템 보호 영역에 있으면 설정을 쓸 때 관리자 권한이 필요하므로, 데이터 디렉터리를 사용자 폴더로 옮길 수 있습니다;
• 경로에 특수 문자가 들어가거나 깊이가 너무 깊으면 일부 시스템 구성 요소가 읽기에 실패합니다;
• 설정 파일 위치를 옮긴 뒤에는 클라이언트에 기록된 예전 경로가 무효가 됩니다.

보안 프로그램 차단

일부 보안 프로그램은 프록시 코어를 위험 프로그램으로 판단해 조용히 차단합니다. 프로세스가 몇 초 뒤 사라지는데 명령줄에서 같은 설정을 직접 실행하면 정상인 경우가 대표적입니다. 보안 프로그램에서 해당 디렉터리를 예외로 추가하거나, 다른 설치 디렉터리에서 다시 시도하세요. Windows에서 처음 설치하는 절차와 흔한 문제는 Windows에서 v2rayN 설치 전체 과정에서 단계별로 설명합니다.

설정 백업과 복구

설정을 바꾸기 전에 먼저 한 번 내보내 두세요. 실행 문제가 생기면 초기화 기능으로 기본 설정으로 돌아간 뒤 항목을 하나씩 복원하면 어떤 설정 항목이 원인인지 찾을 수 있습니다. 설정 디렉터리 전체를 되돌리는 것보다 노드를 직접 가져오는 편이 더 안전하고 되돌리기도 쉽습니다.

09 / 증상 8Android 전용 점검

Android에서는 v2rayNG(Xray 코어)와 v2flyNG(v2fly 코어)가 실행됩니다. 두 앱은 데스크톱과 작동 방식이 다릅니다. 모바일에서는 VPN 모드로 트래픽을 가로채고 '시스템 프록시' 계층이 없으므로, 데스크톱의 일부 점검 항목은 휴대폰에 적용되지 않으며 그 반대도 마찬가지입니다.

두 클라이언트의 차이

같은 공유 링크를 두 앱 모두에서 가져올 수 있지만, 일부 최신 프로토콜 파라미터는 Xray 코어에서만 작동합니다. '가져오기는 되는데 연결이 안 되는' 상황이라면 다른 클라이언트로 한 번 비교해 보면 파라미터 문제인지 클라이언트 문제인지 빠르게 판단할 수 있습니다. 두 클라이언트의 설치 파일은 다운로드 페이지의 Android 섹션에서 받을 수 있습니다.

연결이 안 되는 흔한 원인

• VPN 권한 팝업을 확인하지 않음: 처음 연결할 때 시스템이 권한 대화 상자를 띄우며, VPN 연결 수립을 반드시 허용해야 합니다;
• 시스템에 다른 VPN류 앱이 이미 실행 중: 동시에 하나의 VPN 터널만 허용됩니다;
• 절전 정책: 앱이 백그라운드에서 시스템에 의해 정리되어 알림 표시줄 아이콘이 사라지고 연결이 끊깁니다;
• 앱별 프록시: 일부 앱만 선택되어 있어, 선택하지 않은 앱은 프록시를 거치지 않습니다.

구독과 노드 관리

휴대폰에서 구독 업데이트가 실패하면 네트워크를 먼저 바꿔 보세요. 이동통신 데이터와 Wi-Fi를 한 번 서로 바꿔 보는 것입니다. 업데이트 후 노드 순서가 바뀌는 것은 정상이며 구독 내용을 기준으로 하세요. 구독 주소에는 token이 들어 있으므로 스크린샷을 공개된 곳에 올리지 마세요. 노드 목록 정리 방식은 데스크톱과 같고, 구독 업데이트 실패 판단 절차는 04장을 그대로 따르면 됩니다.

로그와 자체 점검

v2rayNG의 로그 페이지에서 코어 출력을 볼 수 있으며 점검 방법은 데스크톱과 같습니다. 타임스탬프에 해당하는 오류 줄을 먼저 보고, 타임아웃인지 인증인지 DNS 문제인지 구분하세요. 모바일에는 명령줄 환경이 없으므로 노드 교체 비교와 네트워크 전환 비교를 주된 검증 수단으로 사용합니다.

위 아홉 개 장에 해당하지 않는 상황이라면 증상을 한 문장으로 정리해 보세요. 어떤 작업을 했는지, 언제였는지, 로그 마지막 줄이 무엇이었는지입니다. 자주 묻는 질문 페이지에는 주제별로 더 세분화된 문답이 정리되어 있고, 용어 설명 페이지에서 로그에 나오는 용어의 의미를 확인할 수 있습니다.