V2Ray 문제 진단 매뉴얼

먼저 증상을 확정하고, 다음으로 계층을 찾고, 마지막에 설정을 변경합니다. 이 장은 이후 모든 장의 공통 출발점입니다.

문제 해결의 첫 단계는 설정을 바꾸는 것이 아니라 증상을 확정하는 것입니다. 같은 "연결 안 됨" 뒤에는 시스템 프록시 미적용, 노드 만료, DNS 해석 실패, 라우팅 규칙 차단 등 서로 다른 원인이 있을 수 있으며 처리 방식도 완전히 다릅니다. 이 매뉴얼의 모든 장은 "증상 확정 → 계층 파악 → 설정 변경" 순서로 구성되어 원인을 모른 채 클라이언트를 반복해서 켜고 끄는 일을 피합니다. 빠른 시작 가이드는 "사용법"을 다루고, 이 매뉴얼은 "문제가 생겼을 때 어떻게 할지"를 다룹니다. 두 문서를 함께 읽어 보세요.

점검 전에 세 가지를 확인하세요: 클라이언트 버전, 코어 버전, 시스템 시간. 이 세 항목은 로그와 설정 화면에서 바로 확인할 수 있으므로 기록해 두고 시작하면 불필요한 시행착오를 크게 줄일 수 있습니다.

로그: 연결 문제의 1차 자료

로그는 문제를 파악하는 가장 중요한 1차 자료입니다. v2rayN의 로그는 메뉴 "로그 보기"에서 열 수 있으며 기본적으로 연결 및 라우팅 이벤트를 기록합니다. 핸드셰이크 실패나 TLS 오류를 점검할 때는 로그 레벨을 "디버그"로 올린 뒤 재현하면 전체 연결 시퀀스를 확인할 수 있습니다. v2rayNG의 로그는 "설정 → 로그 기록"에 있으며 역시 레벨별 출력을 지원합니다. 로그 키워드와 점검 방향의 대응 관계는 다음과 같습니다:

버전과 코어: 두 개의 독립 변수

클라이언트 버전과 코어 버전은 서로 독립적인 변수입니다. v2rayN은 "설정 → 옵션 설정 → 코어"에서 코어(Xray-core 또는 V2Fly-core)를 확인하고 전환할 수 있으며, v2rayNG는 기본적으로 Xray 코어를 내장하고, v2flyNG는 v2fly 코어를 사용합니다. 버전 확인 방법: v2rayN 메인 화면에 클라이언트 버전이 표시되고, "설정 → 옵션 설정 → 코어" 상단에 코어 버전이 표시됩니다. v2rayNG는 "정보" 페이지에서 버전 번호와 코어 정보를 확인할 수 있습니다. 클라이언트 업그레이드 후 문제가 생겼다면 코어 버전도 함께 변경되었는지 먼저 확인하세요. 둘은 엄격히 일치할 필요는 없지만 차이가 너무 크면 설정 필드가 호환되지 않을 수 있으며, 주로 시작 직후 오류가 나거나 일부 노드에 연결할 수 없는 증상으로 나타납니다.

시스템 시간: TLS 오류의 가장 흔한 원인

기기 시간이 실제 시간과 몇 분 이상 차이가 나면 인증서 검증이 바로 실패합니다. 노드 목록과 지연 테스트는 정상인데 연결 순간 오류가 나고 로그에 인증서 관련 오류가 나타나는 것이 특징입니다. "시스템 시간 맞추기"를 점검 순서의 맨 앞에 두는 것이 가장 비용이 적게 들고 성공률도 가장 높습니다. Windows, macOS, Android 모두 자동 네트워크 시간 동기화를 지원하므로 켠 뒤 클라이언트를 재시작해 보세요.

최소 검증: 두 가지 테스트로 교차 확인

연결 상태를 확인할 때는 두 가지 방법을 함께 사용하는 것이 좋습니다. 첫째는 브라우저 시크릿 창으로 대상 사이트에 접속해 확장 프로그램과 캐시의 간섭을 배제하는 것이고, 둘째는 터미널에서 curl 명령을 실행해 실제 네트워크 경로 상태를 확인하는 것입니다.

# 로컬 SOCKS 프록시를 통해 대상 사이트에 접속
curl -x socks5h://127.0.0.1:10808 -I https://www.google.com

# 로컬 HTTP 프록시를 통해 대상 사이트에 접속
curl -x http://127.0.0.1:10809 -I https://www.google.com

# 현재 적용된 프록시 환경 변수 확인 (Linux / macOS)
env | grep -i proxy

두 명령의 포트 번호는 클라이언트가 실제로 리슨하는 포트를 기준으로 합니다. v2rayN의 기본 SOCKS 포트는 10808, HTTP 포트는 10809이며 "설정 → 옵션 설정 → 로컬 리슨"에서 확인하고 변경할 수 있습니다.

"연결됐는데 인터넷이 안 됨"의 점검 흐름: 프록시가 트래픽을 제대로 받는지, 경로가 사용 가능한지, 트래픽이 규칙에 막히지 않았는지.

"연결됐는데 인터넷이 안 됨"은 가장 흔한 오류 형태입니다. 클라이언트가 프록시 경로를 확보했지만 트래픽이 그 경로로 제대로 들어가지 않았거나, 들어간 뒤 어떤 규칙에 막혔다는 뜻입니다. 아래 순서대로 항목을 확인하되 각 단계마다 명확한 통과 기준이 있습니다.

1단계: 시스템 프록시 상태 확인

v2rayN의 트레이 메뉴에는 "시스템 프록시" 하위 메뉴가 있으며 상태는 "시스템 프록시 자동 설정", "시스템 프록시 변경 안 함", "시스템 프록시 해제"로 나뉩니다. "시스템 프록시 자동 설정"을 선택하면 Windows와 macOS는 시스템 프록시가 로컬 포트를 가리키도록 설정합니다. 이 항목이 "시스템 프록시 해제"라면 브라우저 트래픽은 클라이언트를 거치지 않습니다. 확인 방법: 시스템 네트워크 설정을 열어 프록시 서버 주소가 127.0.0.1과 해당 포트인지 확인합니다. v2rayNG는 Android에서 시스템 프록시를 사용하지 않고 VPN 터널로 트래픽을 가져가므로, 해당 확인 항목은 시스템 "VPN 설정"에 있습니다.

2단계: 직결 대조 테스트

클라이언트 프록시를 끈 뒤 중국 내 사이트에 직접 접속해 보세요. 직결도 안 되면 문제는 프록시와 무관한 로컬 네트워크 자체에 있으므로 Wi-Fi나 인터넷 회선을 먼저 고쳐야 합니다. 직결은 정상인데 프록시를 켜면 모든 사이트가 안 열린다면 다음 단계로 진행합니다. 이 단계는 "로컬 네트워크 고장"과 "프록시 경로 고장"을 빠르게 구분해 주므로 건너뛰지 마세요.

3단계: 노드 연결성 검증

v2rayN 메인 화면에서 현재 노드를 선택하고 "서버 실제 연결 지연 테스트"를 클릭하세요. 여기서 두 가지 결과를 구분해야 합니다. TCP 지연만 표시되면 포트가 열려 있다는 뜻일 뿐 프록시 핸드셰이크 성공을 의미하지 않습니다. "실제 연결 지연"은 실제로 프로토콜 핸드셰이크를 수행하므로 더 신뢰할 수 있습니다. 실제 연결 테스트가 실패하면 다른 노드로 바꿔 다시 테스트하세요. 모든 노드가 실패하면 문제는 로컬 경로나 클라이언트 설정에 있고, 일부 노드만 실패하면 해당 노드 서버 문제이므로 3장을 참고하세요.

4단계: 라우팅 모드 확인

라우팅 모드는 어떤 트래픽이 프록시를 거칠지 결정합니다. v2rayN에서 흔히 쓰는 세 가지 모드는 "중국 본토 우회"(중국 내 주소는 직결, 나머지는 프록시), "전역"(모든 트래픽이 프록시), "직결"(전부 직결)입니다. 현재 "중국 본토 우회"인데 대상 사이트가 중국 내로 판정되면 트래픽이 직결되어 "프록시는 켜져 있는데 사이트가 안 열림" 현상이 나타납니다. 라우팅 모드를 임시로 "전역"으로 바꿔 테스트해 보고, 연결이 되면 분기 규칙 판정 문제이므로 "중국 본토 우회"로 돌아간 뒤 6장에 따라 DNS와 규칙을 조정하세요.

5단계: DNS와 브라우저 캐시

라우팅 모드가 정상인데 일부 도메인 해석이 실패하면 DNS를 확인하세요. v2rayN의 "DNS 설정"에서 원격 해석을 활성화했다면 로컬 시스템 DNS의 오염을 우회할 수 있습니다. 해석 요청이 로컬 DNS로 나가면 오염으로 잘못된 IP가 반환될 수 있으며, 도메인은 안 열리는데 IP 직결은 되는 현상이 나타납니다. 브라우저는 먼저 시크릿 창으로 다시 테스트해 캐시와 확장 프로그램의 영향을 배제하세요.

• 시스템 프록시가 "시스템 프록시 자동 설정"으로 되어 있음
• 직결 대조 프록시를 끈 뒤 로컬 네트워크로 정상 접속됨
• 노드 테스트 "실제 연결 지연" 테스트 통과
• 라우팅 모드와 대상 사이트 귀속이 일치함
• 브라우저 시크릿 창에서는 접속되고 일반 창에서는 안 되므로 캐시와 확장 프로그램 정리
• 최후 확인 노드를 바꿔도 실패하면 로컬 방화벽과 백신 프로그램 점검

더 세부적인 플랫폼별 점검 절차는 기술 노트 《v2rayNG 연결됐는데 인터넷 안 됨: 시스템 프록시부터 라우팅 규칙까지 단계별 점검 체크리스트》를 참고하세요.

먼저 로그에서 타임아웃 형태를 확인한 뒤 포트, 프로토콜, 회선, 인증서 중 어느 방향으로 점검할지 결정하세요.

노드 타임아웃과 "인터넷 연결 안 됨"의 차이는 전자는 프록시 경로 자체가 실패하는 것이고 후자는 경로는 만들어졌지만 트래픽이 올바르게 흐르지 않는 것입니다. 타임아웃 문제의 핵심은 로컬에서 서버까지, 서버에서 대상 사이트까지, 아니면 프로토콜 핸드셰이크 자체 중 어느 구간에서 실패했는지 구분하는 것입니다.

세 가지 타임아웃 형태 구분

연결 타임아웃(로그에서 흔히 dial tcp 또는 connect: connection refused가 보임)은 로컬에서 서버 포트까지 연결이 되지 않는다는 뜻이며, 포트 차단, 서버 다운, 로컬 방화벽 차단 등이 원인일 수 있습니다. 핸드셰이크 타임아웃은 TCP는 연결됐지만 프로토콜 계층에서 응답이 없다는 뜻이며, 프로토콜 종류 오입력, TLS 설정 불일치, 서버 과부하가 흔한 원인입니다. 읽기 타임아웃은 핸드셰이크는 성공했지만 데이터 흐름이 끊긴 경우로, 회선 품질이나 서버 출구 제한과 관련이 많습니다. 세 가지 형태는 서로 다른 점검 방향에 대응합니다:

서버 측 요인

포트가 열려 있지 않거나 프로토콜 설정이 잘못된 것이 가장 흔한 원인입니다. 노드 정보의 포트가 서버가 실제로 리슨하는 포트와 일치하는지 확인하고, 프로토콜(VMess/VLESS/Trojan), 전송 방식(ws/grpc/tcp), TLS 사용 여부가 서버 설정과 정확히 일치해야 합니다. 예를 들어 서버가 VLESS + Reality인데 클라이언트를 VLESS + TLS로 설정하면 핸드셰이크는 반드시 실패합니다. 이런 오류는 로그에서 보통 핸드셰이크 단계 타임아웃이나 EOF로 나타납니다. 또한 서버에 방화벽이나 클라우드 보안 그룹이 443 포트만 허용하도록 설정되어 있는데 노드가 다른 포트를 사용한다면 역시 연결 타임아웃이 발생합니다.

로컬 요인

로컬 방화벽, 백신 프로그램, 프록시 소프트웨어 간 충돌이 아웃바운드 연결을 차단할 수 있습니다. Windows에서는 방화벽을 임시로 끄거나 클라이언트에 허용 규칙을 추가하고, macOS에서는 "시스템 설정 → 네트워크 → 방화벽"의 인바운드 차단을 확인하며, Linux에서는 ufw나 firewalld 상태를 확인하세요. 시스템에서 IPv6를 사용 중인데 노드가 지원하지 않으면 IPv6 우선 연결로 인해 타임아웃이 발생할 수 있으므로, 클라이언트에서 "IPv6 우선"을 끄거나 시스템 IPv6를 잠시 비활성화해 확인하세요. 회사 내부망이나 학교 네트워크에서 비표준 포트를 제한하는 경우도 흔하므로 이런 환경에서는 443 포트 노드를 우선 사용하는 것이 좋습니다.

진단 명령과 로그

로그 레벨을 "디버그"로 두고 재현한 뒤, 연결 실패 직전의 마지막 두 기록을 중점적으로 확인하세요. 명령줄에서는 nc나 curl로 대상 포트를 직접 테스트할 수 있습니다:

# TCP 포트 연결 가능 여부 테스트 (타임아웃 5초)
nc -vz -w 5 <서버 주소> <포트>

# 로컬 SOCKS 프록시를 통해 대상 사이트에 접속
curl -x socks5h://127.0.0.1:10808 -v https://www.google.com

nc가 succeeded를 반환하면 포트는 열려 있고 문제는 프로토콜 계층에 있습니다. timeout이나 connection refused가 반환되면 문제는 포트 또는 네트워크 계층에 있습니다. 로그에 certificate 관련 문구가 보이면 먼저 시스템 시간을 맞춘 뒤 노드의 SNI와 서버 도메인이 일치하는지 확인하세요. 이 두 가지가 TLS 타임아웃의 가장 흔한 원인입니다. TLS 인증서 오류의 전체 원인 분석은 기술 노트 《V2Ray TLS 핸드셰이크 실패와 인증서 오류: 시스템 시간, SNI, allowInsecure 상세 해설》을 참고하세요.

구독 실패는 세 가지와 관련이 있습니다: 구독 URL 자체, 구독 서버 접근성, 반환 콘텐츠의 형식.

구독 실패는 보통 세 가지와 관련이 있습니다: 구독 URL 자체, 구독 서버 접근성, 반환 콘텐츠의 형식. v2rayN과 v2rayNG 모두 구독에서 노드를 일괄 가져올 수 있으며, 실패 시 아래 순서대로 확인하면 대부분의 문제를 처음 세 단계 안에서 해결할 수 있습니다.

구독 URL 확인

올바른 구독 주소는 https://로 시작해야 하며 끝에 불필요한 공백이나 줄바꿈이 없어야 합니다. 구독 링크를 복사할 때 메신저 앱이 공백을 추가하거나 줄바꿈을 자르는 경우가 많아 붙여넣은 뒤 육안으로는 발견하기 어렵습니다. v2rayN에서 "구독 그룹 → 구독 그룹 설정"을 열고 URL을 입력란에 붙여넣은 뒤 문자 단위로 확인하세요. v2rayNG도 "구독 설정"에서 같은 방식으로 확인합니다. URL에 & 파라미터가 포함된 경우 복사할 때 파라미터 구간이 누락되지 않았는지 확인하세요. 일부 서비스 제공자는 여러 구독 주소(base64 버전, Clash 버전 등)를 제공하므로 클라이언트가 지원하는 형식인지 확인하세요.

네트워크 접근성 확인

구독 서버는 프록시 대상 사이트와 달리 로컬 네트워크에서 직접 접근할 수 있어야 합니다. 로컬 네트워크에서 구독 도메인을 해석하지 못하면 구독 업데이트가 실패합니다. 판별 방법: 브라우저에서 구독 URL을 직접 열어 텍스트가 다운로드되면 네트워크 접근이 가능하다는 뜻입니다. 열리지 않으면 먼저 구독 도메인 해석 문제를 해결해야 하며, 구독 도메인을 프록시 규칙에 임시로 추가하거나 접근 가능한 미러 주소로 바꿔 보세요. v2rayN의 "구독 업데이트(프록시 사용 안 함)"는 현재 프록시를 통해 구독을 가져오므로 구독 도메인에 직접 접근할 수 없는 경우에 적합합니다.

콘텐츠 형식 확인

구독이 반환하는 내용은 base64로 인코딩된 v2ray 링크 목록일 수도 있고 Clash, sing-box 등의 형식일 수도 있습니다. v2rayN은 일반적인 형식을 인식하며, v2rayNG는 주로 v2ray 표준 형식과 base64를 인식합니다. 반환 내용이 HTML 오류 페이지나 빈 파일이라면 구독 인터페이스 자체의 문제이므로 클라이언트와 무관합니다. 직접 확인하는 방법: 다운로드한 텍스트를 디코딩을 지원하는 온라인 도구에 붙여넣거나, 앞부분을 확인합니다. vmess://, vless://, trojan://로 시작하면 표준 링크이고, 긴 base64 문자열로 시작하면 인코딩된 목록입니다.

업데이트 시점과 캐시

구독 업데이트 주기는 그룹 설정에 의해 결정됩니다. 방금 추가한 새 노드는 바로 나타나지 않으며 "구독 업데이트"를 직접 클릭해야 합니다. 방금 업데이트한 뒤 바로 다시 클릭하면 일부 구독 서버에 빈도 제한이 있어 429나 빈 내용이 반환될 수 있습니다. v2rayN의 "구독 그룹" 오른쪽 클릭 메뉴에는 "구독 업데이트"와 "구독 업데이트(프록시 사용 안 함)" 두 옵션이 있으므로 네트워크 상황에 맞게 선택하세요.

수동 가져오기 대안

구독 서버를 사용할 수 없을 때는 노드를 하나씩 수동으로 가져올 수 있습니다. v2rayN은 클립보드 가져오기를 지원합니다. vmess:// 또는 vless://로 시작하는 전체 링크를 복사한 뒤 트레이 메뉴에서 "클립보드에서 가져오기"를 선택하면 됩니다. v2rayNG도 "클립보드에서 가져오기"를 지원합니다. 단일 노드 가져오기는 구독 인터페이스에 의존하지 않으므로 긴급 점검에 효과적이며, 가져온 뒤 지연 테스트를 먼저 하고 사용하세요.

먼저 병목이 어느 계층인지 확인한 뒤 해당 계층을 조정하고, 무작정 노드를 바꾸지 마세요.

속도 저하는 한 번에 원인을 찾기 가장 어려운 문제입니다. 영향 요인이 서버, 회선, 로컬 세 계층에 걸쳐 있기 때문입니다. 이 글은 계층별 점검 방식을 사용합니다. 먼저 병목이 어느 계층인지 확인한 뒤 해당 계층을 조정하고, 무작정 노드를 바꾸지 마세요. 속도 문제의 전체 계층별 접근법은 기술 노트 《v2rayN 속도 느릴 때: 노드·회선·로컬 설정 3계층 점검법》을 참고하세요.

먼저 신뢰할 수 있는 속도 테스트

지연 숫자로 속도를 판단하지 마세요. 지연은 핸드셰이크 왕복 시간만 반영할 뿐 다운로드 처리량과 선형 관계가 없습니다. 속도 측정 방법: 먼저 v2rayN에서 노드에 "실제 연결 지연" 테스트를 실행해 경로가 사용 가능한지 확인한 뒤, 명령줄로 실제 파일을 다운로드합니다:

curl -o /dev/null -w "%{speed_download}\n" \
  -x socks5h://127.0.0.1:10808 \
  https://speed.cloudflare.com/__down?bytes=10000000

세 번 반복 측정해 중간값을 사용해 순간적인 변동을 배제하세요. 속도가 출근 시간대와 심야에 크게 다르다면 병목은 기본적으로 서버와 회선 계층에 있으며, 로컬 설정을 아무리 조정해도 상한은 바뀌지 않습니다.

노드와 회선 계층

노드 부하, 대역폭 상한, 회선 품질이 속도 상한을 결정합니다. 같은 서비스 제공자의 여러 노드 중에서는 부하가 낮은 노드를 선택하세요. 서비스 제공자가 다르면 회선 차이로 몇 배의 속도 차이가 날 수 있습니다. 전송 방식도 영향을 줍니다. 약한 네트워크 환경에서는 grpc와 reality가 일반 tcp보다 패킷 손실에 강한 편입니다. 통신사가 UDP를 제한하는 환경에서는 UDP 기반 전송이 TCP보다 느릴 수 있습니다. 노드 프로토콜과 전송 방식을 기록해 두고, 노드를 바꿀 때 같은 파라미터 조합을 유지해야 비교가 의미 있습니다.

로컬 설정 계층

클라이언트 로컬 설정이 속도에 미치는 영향은 세 곳에 집중됩니다. 첫째는 로그 레벨로, "디버그" 레벨은 오버헤드를 크게 증가시키므로 점검이 끝나면 "정보"나 "경고"로 되돌리세요. 둘째는 라우팅 규칙 수로, 규칙이 많을수록 연결마다 분기 판단에 시간이 더 걸리므로 불필요한 규칙을 줄일 수 있습니다. 셋째는 mux(멀티플렉싱) 사용 여부로, 패킷 손실률이 높은 회선에서는 mux가 재전송 오버헤드를 키울 수 있어 끄면 오히려 빨라질 때도 있습니다. v2rayN의 "설정 → 옵션 설정 → 라우팅"과 "설정 → 옵션 설정 → 코어"에서 이 항목들을 조정할 수 있습니다.

시스템 계층

DNS 해석 시간은 새 도메인을 처음 방문할 때마다 드러납니다. 로컬 DNS가 오염되면 해석이 타임아웃 후 재시도되어 "웹페이지가 몇 초 멈췄다가 로드됨" 현상이 나타나며, 클라이언트의 원격 DNS나 FakeDNS를 활성화하면 이 대기 시간을 줄일 수 있습니다. MTU 불일치는 큰 패킷이 조각화되어 버려지는 원인이 되며, 웹페이지는 열리는데 대용량 파일 다운로드가 매우 느린 현상으로 나타납니다. 시스템 네트워크 설정에서 MTU를 1500에서 1400 정도로 낮춰 확인해 보세요. 백신의 실시간 검사도 다운로드를 느리게 만들 수 있으므로 클라이언트 디렉터리를 제외 항목에 추가하세요.

세 가지 증상: 해석 실패, 프록시를 거쳐야 할 도메인이 직결됨, 해석 결과가 잘못된 IP를 가리킴.

DNS 문제는 보통 세 가지로 나타납니다: 일부 도메인 해석 실패, 프록시를 거쳐야 할 도메인이 직결됨, 해석 결과가 잘못된 IP를 가리킴. DNS 설정은 Xray 코어의 고급 기능이므로 설정 구조를 이해하면 대부분의 문제를 dns 섹션 안에서 해결할 수 있습니다.

DNS 증상 식별

도메인은 안 열리는데 IP 직결은 되는 것은 DNS 오염의 전형적인 특징입니다. 프록시를 거쳐야 할 사이트가 직결되는 것은 보통 해석 결과가 "중국 본토 우회"의 IP 대역 판정에 걸렸기 때문입니다. 또 흔한 경우로, 노드 목록과 연결은 정상인데 특정 사이트 로그인이 비정상적이거나 캡차가 로드되지 않는 문제가 있으며, 이는 DNS가 오염된 중간 결과를 반환했기 때문인 경우가 많습니다. DNS 관련 오류가 노드 문제로 오인되기도 합니다. 로그에 resolution failed나 no such host가 나타나면 노드보다 DNS를 먼저 확인하세요.

Xray DNS 설정 구조

Xray의 DNS 설정은 dns 섹션에 있으며 핵심은 servers 목록과 queryStrategy입니다. servers에는 로컬 DNS(예: 223.5.5.5)와 원격 DNS(예: 1.1.1.1 또는 DoH 주소)를 동시에 설정할 수 있고, 도메인 규칙에 따라 어떤 도메인이 어떤 서버를 사용할지 결정합니다:

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

이 예시의 구조는 중국 외 도메인은 원격 DNS를 사용하고, 중국 도메인은 로컬 DNS를 사용하면서 반환된 IP가 중국 IP 대역인지 검증하는 것입니다. 실제 사용할 때는 예시의 주소를 자신의 DNS 서버로 바꾸세요. servers의 순서에는 우선순위가 있으며 도메인 규칙이 겹칠 때 먼저 일치하는 규칙이 먼저 적용됩니다.

FakeDNS 활성화 시나리오

FakeDNS는 예약된 네트워크 대역의 가상 IP로 실제 해석을 대체하여 투명 프록시와 TUN 모드에서도 도메인 규칙이 적용되도록 하고 DNS 왕복을 한 번 줄여 줍니다. 활성화 위치는 v2rayN에서 "설정 → 옵션 설정 → 코어 → FakeDNS 사용"입니다. 적합한 상황: TUN 모드 사용, 도메인 레벨 분기 필요, 로컬 DNS 오염. 부적합한 상황: 시스템 프록시만 사용, IP 직결 요구가 강함, 일부 앱이 가상 IP에 민감함. 활성화한 뒤 로그인 이상이나 인증서 오류가 생기면 FakeDNS를 꺼서 비교해 보세요. FakeDNS와 원격 DNS는 동시에 활성화할 수 있습니다. 전자는 도메인 규칙 매칭을 해결하고 후자는 해석 결과의 신뢰성을 해결합니다. 원리와 경계는 기술 노트 《FakeDNS란: Xray 코어 가상 IP 해석 원리와 활성화 시나리오》를 참고하세요.

브라우저 DoH와 시스템 DNS의 충돌

브라우저 내장 "보안 DNS"(DoH)는 시스템과 클라이언트의 DNS 설정을 우회하고 브라우저에 설정된 DoH 서버에 직접 질의하므로 분기가 실패합니다. 점검 방법: 브라우저의 보안 DNS를 잠시 끄고 도메인 해석이 정상으로 돌아오는지 확인하세요. 도메인 레벨 분기가 필요한 환경에서는 브라우저 DoH를 끄고 해석을 클라이언트에 일괄 맡기는 것이 좋습니다. 시스템 레벨 "비공개 DNS"(Android)도 마찬가지로 "자동"으로 설정하거나 끄세요.

점검 핵심은 프록시 포트와 트래픽 범위입니다: 포트가 점유되었는지, 시스템 프록시가 올바른 포트를 가리키는지, 앱이 시스템 설정을 읽는지.

"클라이언트는 연결됐다고 표시되는데 브라우저가 프록시를 안 거침"과 "인터넷 연결 안 됨"의 차이는 전자는 프록시가 시스템이나 앱에 사용되지 않는 것이고 후자는 프록시 경로 자체가 통하지 않는 것입니다. 이 유형의 점검 핵심은 프록시 포트와 트래픽 범위입니다.

로컬 리슨 포트 확인

v2rayN은 기본적으로 로컬에서 두 개의 포트를 리슨합니다: SOCKS 10808, HTTP 10809. 시스템 프록시는 이 두 포트 중 하나를 가리켜야 합니다. 포트가 점유되면 클라이언트가 자동으로 포트를 변경할 수 있고, 시스템 프록시가 더 이상 유효하지 않은 포트를 가리키게 됩니다. 확인 방법: "설정 → 옵션 설정 → 로컬 리슨"에서 실제 포트를 확인하고 시스템 프록시 설정의 주소와 비교하세요. 명령줄에서는 다음 명령으로 리슨 상태를 확인할 수 있습니다:

# Windows: 10808 포트 리슨 상태 확인
netstat -ano | findstr 10808

# Linux / macOS: 10808 포트 리슨 상태 확인
lsof -i :10808

포트를 다른 프로그램이 점유하고 있다면 해당 프로세스를 종료하거나 클라이언트 설정에서 로컬 포트를 변경하세요. 포트를 변경한 뒤에는 시스템 프록시 주소도 함께 수정해야 합니다.

자동 설정 메커니즘과 플랫폼 차이

"시스템 프록시 자동 설정"은 플랫폼마다 구현 방식이 다릅니다. Windows는 시스템 프록시 레지스트리를 작성하고, macOS는 네트워크 서비스 설정을 수정하며, Linux 데스크톱 환경은 보통 환경 변수나 데스크톱 설정에 의존합니다. Linux의 많은 배포판은 시스템 프록시를 자동으로 설정하지 않으므로 환경 변수를 직접 내보내야 합니다:

export http_proxy=http://127.0.0.1:10809
export https_proxy=http://127.0.0.1:10809
export socks5_proxy=socks5h://127.0.0.1:10808

이 변수들은 현재 터미널에만 적용되며, GUI 앱은 데스크톱 설정이나 시작 스크립트에서 읽어야 합니다. macOS에서 Wi-Fi를 변경한 뒤 이전 프록시 설정이 남을 수 있으며, "시스템 프록시가 설정됐는데 실제로는 적용되지 않음" 현상으로 나타납니다. "시스템 프록시 자동 설정"을 다시 한 번 켜고 끄면 갱신됩니다.

브라우저 확장 프로그램 충돌

SwitchyOmega 같은 프록시 확장 프로그램은 브라우저 레벨에서 트래픽을 가로채 시스템 프록시를 우회합니다. 확장 프로그램이 가리키는 포트가 클라이언트의 실제 포트와 다르면 브라우저가 바로 연결에 실패합니다. 점검: 프록시 확장 프로그램을 잠시 비활성화하거나, 확장 프로그램에서 포트를 클라이언트가 실제로 리슨하는 포트로 변경하세요. 브라우저 자체의 "보안 DNS"도 프록시 설정을 우회하므로 함께 확인하세요.

앱이 프록시를 안 거치는 흔한 이유

일부 앱은 시스템 프록시를 읽지 않으므로 별도로 설정해야 합니다. Windows의 UWP 앱은 네트워크 격리의 영향을 받으므로 "네트워크 격리" 관련 설정을 꺼 보세요. macOS의 기본 앱은 대부분 시스템 프록시를 사용하지만 명령줄 도구는 환경 변수가 필요합니다. v2rayN은 "TUN 모드"를 제공하며 가상 네트워크 어댑터로 모든 트래픽을 가로채므로 시스템 프록시를 읽지 않는 앱에 가장 효과적입니다. TUN을 켜면 시스템 프록시 설정은 필수가 아니게 되지만 관리자 권한이 필요하고 일부 VPN 소프트웨어와 충돌할 수 있습니다.

1. 클라이언트의 실제 리슨 포트 확인 — "로컬 리슨"에서 확인하고 시스템 프록시 주소와 비교합니다.
2. 시스템 프록시가 가리키는 주소 확인 — Windows와 macOS는 시스템 네트워크 설정에서 프록시 서버 주소를 확인합니다.
3. 브라우저 프록시 확장 프로그램을 끄고 재테스트 — 확장 프로그램 레벨의 가로채기를 배제합니다.
4. 터미널에서 환경 변수를 내보내고 재테스트 — 명령줄 도구가 프록시를 사용하는지 확인합니다.
5. 여전히 안 되면 TUN 모드 켜기 — 가상 네트워크 어댑터로 모든 트래픽을 가로챕니다.

복구 순서는 "백업 먼저, 초기화 다음, 복원 마지막"을 따르며, 설정이 손상된 상태에서 반복해서 재시작하지 않도록 합니다.

클라이언트 크래시는 세 가지로 나뉩니다: 시작 즉시 크래시, 연결 과정 중 크래시, 구독 업데이트 중 크래시. 크래시는 대부분 설정 손상, 코어 파일 누락, 포트 충돌로 발생하며 아래 절차를 따르면 빠르게 초기화할 수 있습니다. 복구 순서는 "백업 먼저, 초기화 다음, 복원 마지막"을 따르며, 설정이 손상된 상태에서 반복해서 재시작하지 않도록 합니다.

시작 즉시 크래시

시작 즉시 크래시가 나면 설정 손상을 우선 의심하세요. v2rayN의 설정은 사용자 디렉터리의 guiConfig 관련 파일에 저장되며, 손상되면 클라이언트가 시작 단계에서 읽기에 실패합니다. 처리 방법: 클라이언트를 종료하고 설정 디렉터리 전체 이름을 바꿔 백업한 뒤(예: .bak 접미사 추가) 다시 시작하면 클라이언트가 기본 설정으로 재생성합니다. 백업 디렉터리는 클라이언트 데이터 디렉터리 밖에 두어 중복 읽기를 피하세요. 이름을 바꿔도 여전히 크래시가 나면 다른 보안 소프트웨어가 클라이언트 프로세스를 차단하고 있는지 확인하세요. 재생성 후 구독을 다시 가져오면 노드 목록이 복원됩니다.

연결 과정 중 크래시

연결 중 크래시는 코어와 설정이 맞지 않을 때 흔합니다. v2rayN에서 코어(Xray-core / V2Fly-core)를 전환한 뒤 이전 설정의 일부 필드를 새 코어가 인식하지 못할 수 있습니다. 처리 방법: "설정 → 옵션 설정 → 코어"에서 원래 코어로 되돌리거나, 노드를 삭제한 뒤 구독에서 다시 가져오세요. 또한 로그 레벨을 "디버그"로 두고 오래 실행하면 매우 큰 로그 파일이 생성되어 디스크가 가득 차면 이상이 생길 수 있으므로, 점검이 끝나면 "정보"로 되돌리세요.

코어 파일 누락과 백신 오탐 삭제

코어 파일이 없으면 클라이언트 시작 시 코어를 찾을 수 없다는 안내가 나옵니다. 흔한 원인은 백신 프로그램이 코어 실행 파일을 위협으로 격리하는 것입니다. 처리 방법: 백신의 격리 영역에서 파일을 복원하고 클라이언트 디렉터리를 신뢰 영역에 추가하세요. v2rayN의 "설정 → 옵션 설정 → 코어"에서 코어를 다시 다운로드할 수 있으며, 다운로드가 실패하면 로컬 네트워크에서 코어 다운로드 주소에 접근할 수 있는지 확인하고 필요하면 프록시를 통해 다운로드하세요. v2rayNG의 코어는 설치 패키지에 내장되어 있으므로 누락 안내가 나오면 재설치를 우선 고려하세요. 설치 패키지는 다운로드 센터에서 받을 수 있습니다.

포트 점유

로컬 포트를 다른 프로그램이 점유하면 클라이언트가 리슨에 실패하여 시작 직후 종료되거나 프록시가 적용되지 않습니다. netstat이나 lsof로 점유 프로세스를 찾아 종료하거나, 클라이언트 설정에서 로컬 포트를 변경하세요. 여러 프록시 클라이언트를 동시에 실행할 때도 기본적으로 같은 포트를 사용하므로 충돌이 흔합니다.

v2rayNG 크래시 처리

v2rayNG가 크래시된 뒤에는 앱 데이터를 지우고 구독을 다시 가져오면 됩니다. Android에서 백그라운드 크래시가 발생했다면 배터리 최적화가 앱을 동결했는지 확인하고 앱을 "제한 없음" 배터리 정책에 추가하세요. v2flyNG도 처리 방법이 같지만 두 클라이언트의 설정은 서로 호환되지 않으므로 데이터 디렉터리를 그대로 복사하지 마세요. 데이터를 지우면 구독과 설정이 함께 삭제되므로 작업 전에 구독 주소를 복사해 두세요.

1. 설정 디렉터리 백업 — 전체 이름을 바꿔 장애 현장을 보존합니다.
2. 기본 설정으로 복원 후 시작 — 클라이언트가 정상적으로 열리는지 확인합니다.
3. 구독 다시 가져오기 — 노드 목록을 복원합니다.
4. 코어 무결성 확인 — 코어 파일이 격리되거나 삭제되지 않았는지 확인합니다.
5. 포트 점유 확인 — 로컬 포트가 다른 프로그램에 점유되지 않았는지 확인합니다.

모바일의 점검 차이는 세 곳에 집중됩니다: 백그라운드 유지, 시스템 레벨 프록시 트래픽 처리 방식, 배터리 및 네트워크 정책.

모바일과 데스크톱의 점검 차이는 세 곳에 집중됩니다: 백그라운드 유지, 시스템 레벨 프록시 트래픽 처리 방식, 배터리 및 네트워크 정책. 이 절에서는 v2rayNG와 v2flyNG의 흔한 문제를 다루며, Android 시스템 버전 차이가 크므로 아래 단계는 일반적인 설정을 기준으로 합니다.

연결은 성공했는데 앱이 프록시를 안 거침

Android에서 v2rayNG는 기본적으로 VPN 터널로 트래픽을 가로채므로 시스템 "VPN 설정"에서 앱이 VPN 연결을 만들도록 허용해야 합니다. 연결 아이콘은 정상인데 대상 앱이 여전히 직결된다면 라우팅 모드를 확인하세요. 기본값인 "중국 본토 우회"에서는 중국 내 앱이 직결되며, 프록시가 필요한 앱이 중국 내로 판정되면 직결로 실패합니다. 라우팅을 임시로 "전역"으로 바꿔 확인하거나, "앱별 프록시"를 사용할 때 대상 앱이 선택되었는지 확인하세요. 일부 기종은 VPN에 추가 절전 제한이 있으므로 "앱 정보"에서 "절전 정책"의 VPN 제한을 해제해야 합니다.

백그라운드 종료로 인한 연결 끊김

Android 시스템은 절전을 위해 백그라운드 앱을 동결하며, v2rayNG가 동결되면 VPN 터널도 함께 끊깁니다. 처리 방법: 시스템 설정에서 v2rayNG를 "배터리 최적화 화이트리스트"에 추가하고, 일부 기종은 "자동 시작 관리"에서 자동 시작을 허용해야 합니다. v2rayNG의 "연결 시 자동 재연결"을 켜면 짧은 끊김을 완화할 수 있지만 근본 원인은 여전히 백그라운드 제한입니다. 제조사별 ROM은 백그라운드 정책 구현이 크게 다르므로, 끊김이 발생하면 먼저 "배터리" 페이지에 앱 동결 안내가 있는지 확인하세요.

구독 업데이트 실패

모바일에서 구독 업데이트 실패는 시스템 시간이나 인증서와 관련된 경우가 많습니다. Android의 자동 시간 동기화가 꺼져 있으면 시간 오차로 HTTPS 인증서 검증이 실패하여 구독 요청이 거부됩니다. 처리: "자동 시간 확인"을 켜고 시간대를 맞추세요. 또한 일부 구독 도메인은 모바일 네트워크에서 직접 접근할 수 없으므로, v2rayNG의 구독 설정에서 "프록시를 통해 업데이트"를 켤 수 있습니다. 단, 사용 가능한 노드가 이미 있어야 합니다. Wi-Fi와 모바일 네트워크를 전환한 뒤에는 네트워크 상태가 갱신되지 않아 구독 업데이트가 실패할 수도 있으므로 비행기 모드를 껐다 켜서 다시 시도하세요.

비공개 DNS와 프록시 충돌

Android의 "비공개 DNS" 기능은 앱 레벨 DNS 설정을 우회하여 클라이언트의 도메인 분기와 충돌합니다. 증상: 클라이언트는 연결됐다고 표시되는데 일부 도메인 해석이 비정상적입니다. 처리: 비공개 DNS를 "자동"으로 설정하거나 꺼서 해석이 클라이언트 설정을 따르도록 하세요. 비공개 DNS를 반드시 사용해야 한다면 DoH를 지원하고 오염되지 않는 서버를 선택하세요. 다만 도메인 레벨 분기는 여전히 실패할 수 있습니다.

v2flyNG의 차이점

v2flyNG는 v2fly 코어를 사용하며 v2rayNG의 Xray 코어와 설정 필드에서 차이가 있습니다. 같은 구독을 두 클라이언트에 가져올 수 있는 경우가 많지만 일부 고급 파라미터(예: 일부 전송 방식의 확장 필드)는 호환성이 다릅니다. 점검 시 먼저 노드 프로토콜과 전송 방식이 현재 코어에서 지원되는지 확인한 뒤 코어나 클라이언트 전환을 고려하세요. 두 클라이언트의 설정 데이터는 서로 독립적이므로 재설치하거나 다른 클라이언트로 바꿀 때는 구독을 다시 가져와야 합니다.