V2Ray 문제 해결 가이드

캐시 영향을 배제한 테스트 환경부터 만들기

캐시 영향을 받지 않도록 일반 웹페이지 하나와 순수 IP 연결 테스트 하나를 비교 대상으로 남겨 두세요. 오래 열어 둔 페이지만으로 판단하지 마세요. 브라우저가 기존 연결을 재사용하거나 실패한 DNS 결과를 보관할 수 있습니다. 브라우저 창을 모두 닫았다가 다시 열거나 새 시크릿 창에서 테스트하세요. 다른 프록시 도구, 네트워크 가속기, 트래픽 필터링 프로그램은 잠시 중지해 같은 시간에 한 프로그램만 시스템 프록시를 변경하도록 하세요. 컴퓨터가 유선 네트워크, 무선 네트워크, 가상 네트워크 어댑터에 동시에 연결돼 있다면 실제 사용하는 인터페이스만 남겨 기본 경로가 여러 출구 사이에서 바뀌지 않게 하세요.

이어서 클라이언트 메인 화면을 확인하세요. 현재 노드가 선택되어 있고 코어 상태가 실행 중이어야 하며, 로그에 설정 파싱 실패나 포트 바인딩 실패가 연속으로 나타나지 않아야 합니다. v2rayN에서 “시스템 프록시 설정”과 “코어 시작”은 서로 다른 동작입니다. 코어는 실행 중이지만 시스템 프록시가 활성화되지 않았다면 일반 브라우저의 요청은 자동으로 프록시를 통과하지 않습니다. TUN 모드에서는 가상 네트워크 어댑터가 생성됐는지, 시스템에 승인을 기다리는 권한 요청이 남아 있지 않은지도 확인하세요. TUN의 원리와 전체 활성화 절차는 TUN 모드 트래픽 전환 안내를 참고하세요.

로컬 수신 포트와 앱 프록시 확인

v2rayN의 일반적인 로컬 진입점은 SOCKS 및 HTTP 수신 포트이며, 실제 번호는 클라이언트 설정 화면을 기준으로 확인해야 합니다. 가이드의 예시 포트를 현재 설정으로 그대로 사용하지 마세요. Windows에서는 터미널로 클라이언트 프로세스가 포트를 수신 중인지 확인할 수 있습니다. 결과가 없으면 코어가 진입점을 제대로 만들지 못한 것입니다. 다른 프로세스가 같은 포트를 사용 중이라면 먼저 해당 프로세스를 확인한 뒤 충돌 프로그램을 종료하거나 로컬 포트를 변경하세요. 자세한 절차는 로컬 포트 사용 중 문제 해결을 참고하세요.

netstat -ano | findstr LISTENING
tasklist /FI "PID eq 프로세스 번호"

브라우저나 다른 앱에 프록시를 수동으로 설정할 때는 프록시 유형이 수신 진입점과 일치해야 합니다. SOCKS5 진입점을 HTTP 프록시로 입력할 수 없고, HTTP 진입점도 SOCKS만 허용하는 설정란에 입력할 수 없습니다. 주소는 보통 127.0.0.1을 사용하며 노드 서버 주소를 입력하지 마세요. 앱에 “프록시 DNS” 또는 “SOCKS를 통해 도메인 확인” 옵션이 있다면 먼저 활성화해 비교 테스트를 진행하세요. 도메인 확인과 앱 요청이 같은 진입점을 사용하므로 로컬 DNS의 영향을 배제하기 쉽습니다.

직접 연결과 프록시 결과로 문제 범위 나누기

시스템 프록시를 끈 상태에서 일반 네트워크를 테스트하세요. 직접 연결도 어떤 웹페이지에 접속하지 못한다면 먼저 기기 네트워크, 게이트웨이 또는 현재 네트워크 인증을 해결해야 합니다. V2Ray 설정이 첫 번째 점검 대상은 아닙니다. 직접 연결은 정상이고 프록시를 켠 뒤 모두 실패하지만 로컬 포트는 수신 중이라면, 클라이언트 로그에서 요청이 어느 아웃바운드로 향하는지 확인하세요. 연결 거부는 원격 주소에는 도달했지만 해당 포트에서 서비스가 제공되지 않는 경우가 많습니다. 연결 시간 초과는 네트워크 경로, 주소 오류 또는 원격 노드 접근 불가에 가깝고, 핸드셰이크 실패라면 프로토콜, 전송 계층, 보안 계층, 호스트 이름과 경로를 확인해야 합니다.

일부 웹사이트만 열리지 않는다면 먼저 라우팅 모드를 잠시 전환해 비교하세요. 전역 모드에서는 정상인데 규칙 모드에서 실패한다면 대개 노드가 아니라 규칙 매칭 결과가 원인입니다. 도메인 규칙이 너무 일찍 직접 연결이나 차단 아웃바운드로 배정되지 않았는지 확인하고, 위에서 아래로 매칭되는 규칙의 우선순위도 살펴보세요. 페이지는 열리지만 이미지, 로그인 또는 인증 코드가 실패한다면 페이지가 참조하는 다른 도메인이 다른 규칙에 매칭됐는지 확인하세요. 점검이 끝나면 원래의 분할 라우팅으로 되돌리세요. 규칙 오류를 가리기 위해 전역 모드를 장기간 사용하는 것은 권장하지 않습니다.

마지막으로 시스템 시간을 확인하세요. VLESS, VMess, TLS 등의 연결은 시간 오차가 크면 영향을 받을 수 있습니다. 운영체제의 자동 시간 동기화를 켜고 시간대가 올바른지 확인하세요. 동기화가 끝나면 코어를 다시 시작해 새 연결을 핸드셰이크하도록 하세요. 같은 노드가 다른 기기에서는 작동하지만 현재 기기에서 계속 실패한다면 양쪽 설정 필드, 시스템 프록시 상태와 보안 소프트웨어 정책을 우선 비교하세요. 모든 기기에서 같은 시간에 실패한다면 노드 측 또는 현재 네트워크 경로 문제일 가능성이 높습니다.

테스트 유형과 실제 접속 구분

TCP 테스트는 대상 주소와 포트에서 기본 연결을 만들 수 있는지만 확인하며 VLESS, VMess 또는 다른 프로토콜 매개변수가 올바른지는 검증하지 않습니다. 실제 지연 시간 테스트는 노드를 통해 지정된 웹사이트에 접속하므로 로컬 진입점, 원격 핸드셰이크, 아웃바운드 요청과 대상 응답을 모두 포함해 실제 사용에 더 가깝습니다. 다만 테스트 사이트 접근 불가, DNS 실패 또는 라우팅 규칙의 영향도 더 쉽게 받습니다. “TCP는 사용 가능하지만 실제 테스트는 시간 초과”라면 프로토콜 인증, TLS, 전송 경로와 테스트 사이트를 확인하세요. “TCP부터 시간 초과”라면 서버 주소, 포트와 현재 네트워크에서 원격지까지의 접근 가능성을 먼저 확인하세요.

모든 노드를 연속해서 고빈도로 테스트하지 마세요. 일괄 테스트는 많은 연결을 동시에 생성해 로컬 네트워크 장비의 연결 수 제한을 초과할 수 있고, 로그가 반복 오류로 덮일 수 있습니다. 설정이 명확한 노드 하나를 골라 몇 초 간격으로 테스트하고 각 테스트 시간대의 로그를 읽으세요. 노드 이름은 식별용일 뿐이며 실제 연결을 결정하는 것은 주소, 포트, 사용자 식별자, 전송 방식, 보안 계층과 추가 필드입니다.

노드 이름에 의존하지 말고 필드별로 비교

설정을 수동으로 추가할 때는 프로토콜 유형, 원격 주소, 포트, 사용자 식별자, 암호화 또는 흐름 제어 설정, 전송 유형, 경로, Host, 서버 이름, 지문 옵션을 항목별로 확인하세요. 대소문자, 앞쪽 슬래시와 공백도 결과를 바꿀 수 있습니다. 예를 들어 WebSocket 경로는 일반적으로 서버 측과 완전히 일치해야 합니다. 서버 이름은 TLS 핸드셰이크에 사용되므로 노드 주소가 IP라는 이유만으로 임의로 비워 두면 안 됩니다. REALITY 설정의 서버 이름, 짧은 식별자와 공개 키는 하나의 매개변수 그룹이므로 서로 다른 노드의 필드를 섞으면 핸드셰이크 단계에서 실패합니다.

구독을 가져온 뒤 특정 노드 하나만 실패한다면 해당 노드를 복제해 구독 원문과 필드별로 비교하세요. 원래 노드를 계속 덮어쓰면 비교 기준을 잃을 수 있습니다. 같은 구독의 모든 노드가 시간 초과된다면 회사 네트워크에서 가정용 네트워크나 모바일 네트워크로 바꾸는 등 다른 네트워크를 먼저 시도하세요. 다른 네트워크에서 작동한다면 클라이언트 설정은 대체로 올바르고 현재 네트워크 정책, DNS 결과 또는 출구 라우팅에 문제가 있는 것입니다. 모든 네트워크에서 실패하면 구독을 갱신하고 노드 정보가 변경되지 않았는지 확인하세요.

주소 확인과 IPv4·IPv6 경로 확인

노드 주소가 도메인이라면 클라이언트가 먼저 DNS 확인을 완료해야 합니다. 시스템 터미널에서 도메인을 조회해 주소와 주소 체계가 반환되는지 확인하세요. IPv6만 반환되는데 현재 네트워크에 안정적인 IPv6 출구가 없다면 오랫동안 기다린 뒤 시간 초과가 발생할 수 있습니다. 여러 주소가 반환될 때는 특정 주소에 접근하지 못해 첫 연결이 느려질 수도 있습니다. 비교를 위해 신뢰할 수 있는 DNS로 잠시 전환하거나 클라이언트에서 도메인 확인 전략을 조정할 수 있지만, 서버 주소가 바뀔 수 있으므로 구독 도메인에 대응하는 IP를 장기간 고정하지 마세요.

테스트에는 지연 시간이 표시되지만 실제 접속이 실패한다면 테스트 경로와 앱 경로가 일치하지 않는다는 뜻입니다. 테스트가 사용자 지정 라우팅을 우회했는지, 앱이 시스템 프록시를 사용하는지, 브라우저에 별도 프록시 확장 기능이 켜져 있는지 확인하세요. 마지막으로 노드 하나로 실제 웹페이지에 접속한 뒤 유지 여부를 결정하세요. 지연 시간 정렬은 후보를 추리는 용도일 뿐이며, 안정성·핸드셰이크 성공률·대상 접속 결과가 현재 네트워크에 적합한지 더 잘 보여 줍니다.

먼저 구독 주소 자체 확인

구독 주소를 복사할 때 전체 프로토콜 헤더, 경로와 쿼리 매개변수가 포함됐는지 확인하세요. 메신저나 문서가 링크 앞부분만 인식해 매개변수가 잘릴 수 있으며, 주소 양끝에 공백·줄바꿈·한글 문장 부호가 섞일 수도 있습니다. 클라이언트의 구독 관리 화면에 다시 붙여넣고, 구독 이름은 알아보기 쉬운 짧은 텍스트로 설정하는 것이 좋습니다. 단일 vmess:// 또는 vless:// 공유 링크를 구독 주소 입력란에 넣지 마세요. 이는 단일 노드 가져오기용이며 구독란에는 노드 목록을 반환하는 주소가 필요합니다.

구독 서비스에는 유효한 접근 매개변수가 필요할 수 있습니다. 링크가 재생성됐다면 이전 주소가 열리더라도 오류 안내나 빈 콘텐츠만 반환할 수 있습니다. 브라우저에 “문자열이 표시된다”는 이유만으로 구독이 유효하다고 판단하지 마세요. 오류 페이지도 정상적인 HTTP 상태를 반환할 수 있습니다. 클라이언트 로그에는 요청 상태, 응답 유형 또는 파싱 실패 위치가 기록되는 경우가 많습니다. 인증되지 않음, 접근 금지, 리소스 없음, 리디렉션 과다, 빈 응답 등의 메시지를 중점적으로 확인하세요.

구독 요청이 직접 연결인지 프록시인지 확인

처음 설치해 노드 목록이 비어 있다면 구독 업데이트는 보통 현재 직접 연결 네트워크만 사용할 수 있습니다. 사용 가능한 노드가 이미 있으면 일부 클라이언트에서 프록시를 통한 구독 업데이트를 지원합니다. 직접 연결 업데이트는 실패하고 프록시 업데이트는 성공한다면 현재 직접 연결 경로에서 구독 서비스에 접근할 수 없는 것입니다. 반대라면 현재 프록시 노드가 구독 주소에 접근하지 못할 가능성이 있습니다. 점검할 때 “구독 업데이트 시 프록시 사용”과 “구독 자동 업데이트”를 동시에 반복 실행하지 마세요. 로그에 여러 요청이 섞입니다. 자동 업데이트를 끄고 한 가지 경로를 수동으로 선택해 테스트하세요.

시스템 프록시와 클라이언트 내부의 구독 요청은 같은 개념이 아닙니다. 일부 클라이언트는 업데이트 요청을 코어가 직접 보내고, 일부는 앱 프로세스가 보내므로 시스템 프록시 스위치가 요청 경로를 항상 결정하지는 않습니다. 클라이언트 설정과 로그를 기준으로 확인하세요. 회사·학교 네트워크 또는 웹 인증이 필요한 네트워크에서는 먼저 일반 브라우저로 네트워크 인증을 완료하세요. 인증되지 않은 상태에서는 요청이 로그인 페이지로 리디렉션될 수 있고, 클라이언트가 HTML을 받으면 형식 오류를 보고합니다.

“업데이트 성공했지만 목록이 바뀌지 않음” 처리

먼저 올바른 구독 그룹을 보고 있는지 확인하세요. 클라이언트는 구독 이름별로 그룹을 만들 수 있어 업데이트된 노드가 다른 그룹에 들어가고 현재 화면에는 이전 그룹이 계속 표시될 수 있습니다. 필터, 검색어, 사용 불가 노드 숨기기 등의 옵션을 확인하세요. 다음으로 노드 수, 이름 또는 업데이트 시간에 변화가 있는지 살펴보세요. 서버가 변경되지 않은 콘텐츠를 반환했다면 클라이언트 목록이 그대로인 것은 정상입니다. 로그에 노드가 0개로 파싱됐다고 표시되면 클라이언트가 해당 구독 형식을 지원하는지, 응답이 실제로 오류 안내인지 확인하세요.

v2rayN은 Windows, macOS, Linux 데스크톱 환경에서 사용하고 v2rayNG와 v2flyNG는 Android에서 사용합니다. 클라이언트마다 구독 확장 필드 지원 범위가 다를 수 있습니다. 같은 주소가 한 클라이언트에서는 가져와지지만 다른 클라이언트에서는 비어 있다면 모든 노드를 즉시 수정하지 마세요. 먼저 인식되지 않은 필드가 클라이언트에서 지원하지 않는 확장 형식인지 확인하고 다운로드 페이지에서 제공하는 최신 클라이언트 버전으로 업데이트하세요. 업데이트 후 새 테스트 구독 그룹을 만들어 기존 데이터베이스의 잔여 필드가 결과에 영향을 주지 않게 하세요.

구독 업데이트 후 노드가 중복된다면 같은 주소가 여러 번 추가됐거나 “노드 추가”와 “덮어쓰기 업데이트” 정책이 다를 가능성이 큽니다. 하나의 구독 소스만 남기고 중복 구독 기록을 삭제한 다음 한 번 더 업데이트하세요. 노드 이름만으로 일괄 삭제하지 마세요. 서로 다른 서버가 같은 표시 이름을 사용할 수 있습니다. 기기를 옮길 때는 새 기기에서 구독을 다시 추가하는 것이 좋습니다. 기존 데이터베이스와 같은 구독 소스를 함께 가져오면 중복 기록과 오래된 설정이 남기 쉽습니다.

마지막으로 시스템 날짜, 네트워크 프록시와 인증서 신뢰를 확인하세요. 브라우저에서도 구독 주소가 열리지 않으면 먼저 네트워크 계층을 해결해야 합니다. 브라우저에서는 열리지만 클라이언트에서 실패한다면 클라이언트 로그의 요청 시간, 상태와 파싱 오류를 수집해 해당 단계에 맞게 처리하세요. 구독 주소는 접근 자격 정보이므로 공개 페이지나 스크린샷에 붙여넣지 마세요. 점검용 스크린샷에는 전체 경로와 쿼리 매개변수를 가려야 합니다.

반복 가능한 비교 테스트 만들기

먼저 프록시를 끄고 같은 네트워크와 같은 기기에서 일반 웹페이지 로딩과 안정적인 파일 하나의 다운로드를 테스트해 대략적인 상태를 기록하세요. 한 번의 최고 속도를 얻는 것이 목적은 아닙니다. 그런 다음 프록시를 켜고 노드 하나만 선택해 브라우저, 테스트 대상과 시간대를 동일하게 유지하세요. 속도 테스트 중에는 시스템 업데이트, 클라우드 동기화, 동영상 재생과 다른 기기의 대용량 작업을 중지하세요. 무선 신호가 약하거나 라우터 부하가 높거나 모바일 네트워크가 기지국을 자주 전환하면 모든 노드에서 변동이 생길 수 있으므로 먼저 로컬 경로를 배제하세요.

“웹페이지 첫 로딩이 느림”과 “지속 다운로드가 느림”을 구분하세요. 첫 로딩만 느리고 이후 정상이라면 DNS, TLS 핸드셰이크 또는 연결 설정 지연이 흔한 원인입니다. 다운로드가 빠르게 시작한 뒤 느려진다면 네트워크 혼잡, 원격 측 속도 제한 또는 패킷 손실 재전송일 수 있습니다. 작은 웹페이지는 정상인데 대용량 파일만 느리다면 기본 연결에는 문제가 없으므로 경로 품질과 지속 처리량을 비교하세요. 하나의 웹사이트만으로 결론 내리지 마세요. 대상 서비스의 부하와 지역별 라우팅도 결과를 바꿀 수 있습니다.

노드와 전송 경로 비교

지리적 거리와 네트워크 경로가 합리적인 노드를 선택해 비교하세요. 지연 시간이 낮으면 대화형 사용에 유리한 경우가 많지만 높은 대역폭을 보장하지는 않습니다. 지연 시간은 조금 높아도 패킷 손실이 적은 노드가 지속 전송에서는 더 안정적일 수 있습니다. 매번 노드 하나만 바꾸고 다른 설정은 그대로 유지하세요. 같은 구독의 모든 노드가 느리고 직접 연결은 정상이라면 로컬 프록시 모드, DNS와 보안 소프트웨어를 확인하세요. 특정 노드 하나만 느리다면 전체 클라이언트를 수정하지 말고 먼저 노드를 교체하세요.

전송 계층 매개변수는 서버 측과 일치해야 하며 “속도 향상”을 위해 임의로 바꾸면 안 됩니다. WebSocket, gRPC, TCP는 연결 특성이 서로 다르지만 실제 성능은 서버 설정과 네트워크 경로에 따라 달라집니다. 잘못된 Host, 경로 또는 서버 이름은 즉시 오류보다 재시도와 간헐적 실패로 나타날 수 있습니다. 로그에 연결 재생성, EOF, 시간 초과 또는 핸드셰이크 실패가 연속으로 나타나면 먼저 안정성을 해결한 뒤 속도를 논의하세요.

라우팅, 동시 연결과 로컬 처리 부하 확인

규칙 모드에서는 한 페이지의 주 문서, 이미지, 스크립트와 API가 서로 다른 아웃바운드에 매칭될 수 있습니다. 주 페이지는 프록시를 통과하지만 정적 리소스가 직접 연결에 실패하면 페이지가 오래 빈 화면으로 보입니다. 클라이언트 라우팅 로그를 열거나 잠시 전역 모드로 전환해 비교하세요. 전역 모드에서 크게 개선된다면 페이지 관련 도메인의 규칙 매칭을 항목별로 확인하세요. 규칙은 명확하고 구체적인 조건부터 배치한 뒤 더 넓은 기본 규칙으로 내려가야 하며, 위쪽의 광범위한 직접 연결 규칙이 요청을 먼저 가로채지 않게 해야 합니다.

TUN 모드는 더 많은 프로세스의 트래픽을 처리합니다. 활성화 후 속도가 떨어지면 시스템 업데이트, LAN 접속과 대용량 파일 동기화까지 프록시로 보내고 있지 않은지 확인하세요. LAN과 필요한 직접 연결 규칙을 적절히 설정하면 불필요한 트래픽이 원격 경로를 거치는 일을 줄일 수 있습니다. 동시에 시스템 프록시, 브라우저 프록시 확장 기능과 다른 가상 네트워크 어댑터를 함께 사용하지 마세요. 중복 전달은 루프를 만들어 CPU 사용량 증가, 웹페이지 반복 재시도와 급격한 속도 저하를 일으킬 수 있습니다.

클라이언트 로그 수준을 장기간 높게 유지하면 특히 짧은 연결이 많은 환경에서 디스크 쓰기가 늘어날 수 있습니다. 진단할 때는 로그 상세도를 높여도 되지만 문제를 확인한 뒤에는 일반 수준으로 되돌리고 지나치게 커진 과거 로그를 정리하세요. 보안 소프트웨어가 새 연결마다 심층 검사를 수행하면 첫 접속 시간이 늘어날 수 있습니다. 전체 보안 정책을 바꾸지 않는 범위에서 클라이언트 프로그램과 로컬 수신 연결이 중복 검사되고 있는지 확인하세요.

DNS 확인이 느리면 연결을 만들기 전에 페이지가 대기합니다. 이 페이지의 DNS 섹션에서 확인 시간도 함께 점검하고 DNS 요청과 프록시 경로 설정을 참고하세요. TUN 환경에서 FakeDNS를 사용한다면 가상 주소 매핑과 도메인 복원의 범위도 이해해야 합니다. 관련 원리는 FakeDNS 작동 방식에서 확인할 수 있습니다. 성능을 조정한 뒤에는 최소 두 개의 대상과 두 개의 시간대에서 다시 테스트해 일시적인 네트워크 변동을 고정 설정 문제로 오해하지 않도록 하세요.

문제가 도메인에서만 발생하는지 확인

로그에 대상 도메인 확인 실패가 표시되지만 접근 가능한 IP에 직접 접속하면 응답이 있다면 문제는 DNS에 집중됩니다. 도메인이 주소로 확인되는데도 연결이 시간 초과된다면 원격 경로도 확인해야 합니다. Windows에서는 nslookup, macOS와 Linux에서는 dig 또는 nslookup으로 시스템 확인 결과를 볼 수 있습니다. 조회할 때 반환된 IPv4와 IPv6 주소를 각각 기록하고 명령이 실행됐는지만 보지 마세요.

nslookup example.com

dig example.com A
dig example.com AAAA

시스템 조회가 정상이라고 해서 클라이언트 내부 DNS도 반드시 정상인 것은 아닙니다. v2rayN, v2rayNG와 v2flyNG는 코어에서 별도로 확인을 수행하고 라우팅에 따라 다른 서버를 선택할 수 있습니다. 브라우저 직접 연결은 정상인데 프록시를 사용하면 도메인 확인에 실패할 때는 클라이언트 로그의 DNS 서버, 조회 유형과 아웃바운드 표시를 확인하세요. 프록시를 통해서만 접근할 수 있는 DNS로 요청을 보내는데 현재 프록시가 아직 연결되지 않았다면 시작 의존성이 생길 수 있습니다. 반대로 프록시가 필요한 확인 요청을 강제로 직접 연결하면 계속 시간 초과될 수 있습니다.

DNS와 라우팅 실행 순서 정리

라우팅 규칙은 도메인, IP, 포트 또는 프로세스 기준으로 매칭할 수 있습니다. 도메인 규칙은 코어가 대상 도메인 정보를 유지해야 하며 IP 규칙은 먼저 확인이 필요할 수 있습니다. 필요할 때만 확인하도록 설정하면 규칙에 IP 조건이 있을 때만 주소를 조회해 불필요한 요청을 줄일 수 있습니다. 모든 도메인을 라우팅 전에 강제로 확인한 뒤 반환된 IP로 분할하면 동적 주소를 사용하는 서비스가 잘못된 규칙에 들어갈 수 있습니다. 점검 단계에서는 먼저 단순한 DNS 설정으로 기본 접속을 복구한 뒤 분할 서버, 도메인 목록과 주소 정책을 단계적으로 추가하세요.

다음은 코어 DNS 구조를 이해하기 위한 예시입니다. 실제 주소와 태그는 현재 네트워크와 설정에 맞게 조정해야 하며, 클라이언트가 자동 생성한 전체 설정을 그대로 덮어쓰면 안 됩니다. 핵심은 DNS 서버에 아웃바운드를 지정할 수 있고 조회 정책도 네트워크가 지원하는 주소 체계와 일치해야 한다는 점입니다.

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "1.1.1.1",
        "port": 53,
        "skipFallback": false
      },
      "localhost"
    ]
  }
}

캐시·IPv6·FakeDNS 범위 확인

DNS를 변경한 뒤 시스템 캐시를 지우고 브라우저 연결을 새로 만드세요. Windows에서는 관리자 터미널에서 ipconfig /flushdns를 실행할 수 있습니다. 코어에서 독립 DNS를 사용한다면 클라이언트 코어도 다시 시작해야 합니다. 시스템 캐시를 지워도 코어 내부 상태는 삭제되지 않습니다. 브라우저 자체 호스트 캐시가 남아 있을 수 있으므로 완전히 종료했다가 다시 여는 편이 일반 새로고침보다 확실합니다. 네트워크가 IPv4만 안정적으로 지원하는데 IPv6가 우선 반환된다면 조회 정책을 잠시 조정해 확인하세요. 이후 로컬 IPv6 라우팅을 고칠지, 클라이언트가 현재 접근 가능한 주소 체계를 우선 사용하게 할지 결정하면 됩니다.

FakeDNS는 TUN 모드와 함께 사용하는 경우가 많습니다. 앱에는 예약 주소가 할당되고 코어가 매핑을 바탕으로 원래 도메인을 복원해 라우팅합니다. 도메인 정보를 유지할 수 있지만 모든 LAN 앱과 특수 프로토콜이 가상 주소에 적합한 것은 아닙니다. LAN 기기 검색 실패나 일부 앱의 고정 IP 연결 이상이 발생하면 LAN 도메인, 사설 주소 대역과 필수 시스템 서비스를 FakeDNS에서 제외하세요. FakeDNS 주소를 원격 실제 주소로 간주해 규칙에 입력하거나 수동 연결에 사용하지 마세요.

“접속은 되지만 확인 경로가 예상과 다름”이라면 앱이 보낸 DNS, 클라이언트가 사용하는 DNS와 노드 연결에 필요한 DNS를 나눠 관찰하세요. 노드 서버 도메인은 프록시 경로가 만들어지기 전에 확인해야 하므로 일반적으로 직접 접근 가능한 경로가 필요합니다. 대상 웹사이트의 도메인 확인은 라우팅에 따라 다른 아웃바운드를 사용할 수 있습니다. 이 두 요청을 하나의 복잡한 규칙 그룹에 섞으면 순환 의존성이 생기기 쉽습니다. 수정 후에는 도메인 확인 결과, 클라이언트 로그의 아웃바운드 표시와 실제 웹 요청을 함께 검증하세요. 자세한 방법은 DNS 유출 확인 및 해결 실전에서 계속 확인할 수 있습니다.

시스템 프록시 값과 로컬 수신 설정 일치 여부 확인

시스템 프록시 주소는 로컬 진입점을 가리켜야 하며 보통 127.0.0.1과 클라이언트의 현재 HTTP 포트를 사용합니다. 클라이언트가 로컬 포트를 바꿨는데 운영체제에 이전 포트가 남아 있으면 프록시를 켜는 즉시 인터넷이 끊길 수 있습니다. v2rayN이 비정상 종료된 경우에도 이전 설정이 남을 수 있으므로 클라이언트를 다시 연 뒤 시스템 프록시를 먼저 지우고 현재 설정으로 다시 지정하세요. 여러 클라이언트가 같은 포트를 사용하거나 시스템 프록시를 반복해서 덮어쓰지 않도록 하세요.

Windows에서는 시스템 네트워크 설정에서 수동 프록시를 확인할 수 있고 명령으로 WinHTTP 계층 설정을 읽을 수도 있습니다. WinHTTP와 일반 데스크톱 앱의 프록시 설정은 완전히 같지 않으므로 특정 명령에 “직접 연결”이라고 표시됐다고 해서 브라우저가 프록시를 사용하지 않는다고 단정할 수 없습니다. macOS는 현재 네트워크 서비스별로 웹 프록시와 보안 웹 프록시를 설정합니다. 무선 네트워크 서비스를 전환하면 이전 서비스의 설정이 현재 연결에 적용되지 않을 수 있습니다. Linux 데스크톱 환경은 그래픽 설정, 환경 변수 또는 앱 자체 설정을 사용할 수 있으므로 세 가지를 따로 확인해야 합니다.

netsh winhttp show proxy

scutil --proxy

env | grep -i proxy

시스템 프록시를 무시하는 앱 식별

명령줄 도구는 보통 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY 환경 변수를 읽지만 자체 설정에서 지정해야 하는 경우도 있습니다. 환경 변수의 프록시 유형은 로컬 진입점과 일치해야 하며 적용 범위도 명확해야 합니다. 현재 터미널에만 설정하면 새로 연 다른 터미널에는 상속되지 않고, 전역 환경에 기록하면 클라이언트 종료 후에도 잘못된 주소가 남을 수 있습니다. 점검 단계에서는 현재 세션에만 임시로 설정하고 테스트가 끝나면 제거하세요.

일부 앱은 UDP, 직접 소켓 또는 자체 DNS를 사용해 HTTP 시스템 프록시를 따르지 않습니다. 이때는 TUN 모드로 가상 네트워크 어댑터가 네트워크 계층에서 트래픽을 가져오게 할 수 있습니다. 활성화하기 전에 관리자 권한, 가상 네트워크 어댑터 드라이버와 라우팅 설정이 정상인지 확인하고 LAN 주소를 제외해 프린터, 라우터 관리 페이지와 파일 공유가 원격으로 전송되지 않게 하세요. TUN은 잘못된 노드를 고치는 대체 수단이 아닙니다. 노드 핸드셰이크 자체가 실패한다면 관리 범위만 넓어져 더 많은 앱이 동시에 실패합니다.

남은 프록시 설정, 루프와 LAN 우회 처리

프록시 루프는 브라우저 확장 기능이 시스템 프록시를 가리키고 시스템 프록시가 다시 다른 도구로 전달되거나, 클라이언트의 자체 업데이트 요청이 자신의 수신 포트로 잘못 돌아갈 때 흔히 발생합니다. CPU 사용량 증가, 로그에서 같은 대상의 빠른 반복, 결과 없이 계속 로딩되는 웹페이지가 주요 증상입니다. 브라우저 프록시 확장 기능과 다른 네트워크 도구를 끄고 클라이언트가 설정한 시스템 프록시만 남기세요. 복구를 확인한 뒤 앱별 규칙이 필요한지 결정하세요.

시스템 프록시 우회 목록에는 로컬 기기와 필요한 LAN 주소가 포함되어야 합니다. localhost, 127.0.0.1 또는 사설 네트워크 기기에 접속할 때는 대개 원격 경로를 거치지 않아야 합니다. 반대로 모호한 와일드카드로 많은 도메인을 우회하도록 범위를 지나치게 넓히면 원래 프록시가 필요한 요청까지 직접 연결될 수 있습니다. 각 우회 규칙의 대상을 명확히 적고 변경 후 LAN 주소 하나와 외부 대상 하나로 각각 확인하세요.

클라이언트가 정상 종료되면 보통 시스템 프록시를 복원하지만, 시스템 강제 종료, 프로세스 충돌 또는 권한 부족으로 완료하지 못할 수 있습니다. 클라이언트가 실행되지 않는데 전체 인터넷이 작동하지 않는다면 운영체제에서 수동 프록시를 먼저 끄고 브라우저를 다시 시작하세요. 자주 발생하면 클라이언트에 설정 변경 권한이 충분한지, 보안 소프트웨어가 차단하는지, 다른 프로그램이 프록시를 주기적으로 덮어쓰는지 확인하세요. 포트 변경 후 시스템 프록시를 동기화하는 전체 절차는 로컬 수신 포트 충돌 해결을 참고하세요.

최종 검증은 세 종류의 앱을 대상으로 해야 합니다. 시스템 프록시를 읽는 브라우저, 자체 프록시 설정으로 연결하는 도구, TUN으로 트래픽을 가져와야 하는 앱을 각각 하나씩 테스트하세요. 세 결과를 통해 시스템 프록시와 TUN의 범위를 구분할 수 있습니다. 하나의 앱을 작동시키기 위해 모든 트래픽 관리 방식을 동시에 켜지 마세요. 대상 트래픽을 처리할 수 있는 가장 작은 구성을 선택해야 이후 라우팅과 문제 분석이 명확해집니다.

시작 로그에서 종료 단계 확인

클라이언트 창이 열린다면 먼저 로그 디렉터리와 메인 화면의 마지막 몇 줄을 확인하세요. 설정 파싱 오류는 보통 코어 시작 직후 나타나며 필드, JSON 위치 또는 지원하지 않는 설정 항목을 알려 줍니다. 포트 사용 중이면 바인딩 실패가 표시되고, 몇 초 실행 후 종료된다면 TUN 권한, 가상 네트워크 어댑터, 네트워크 환경 또는 실제 요청과 관련이 있을 수 있습니다. 로그가 저장되기 전에 계속 재시작하지 마세요. 발생 시간 전후의 오류 텍스트를 먼저 복사하고 노드 주소, 사용자 식별자와 구독 매개변수는 가리세요.

인터페이스가 완전히 열리지 않는다면 시스템 작업 관리자나 활성 상태 보기에서 남은 프로세스가 있는지 확인하세요. 남은 프로세스가 데이터베이스와 포트를 점유해 두 번째 시작을 방해할 수 있습니다. 남은 프로세스를 정상적으로 종료한 뒤 한 번만 다시 시작하고 여러 시작 버튼을 연속으로 누르지 마세요. 데스크톱에서는 먼저 v2rayN을 사용하고, 클라이언트 다운로드 페이지에서 운영체제와 프로세서 아키텍처에 맞는 설치 패키지를 선택하세요. macOS에서 첫 실행 시 시스템 보안 허용과 네트워크 권한이 필요하다면 macOS 설치 및 권한 처리를 참고하세요.

사용자 설정과 프로그램 파일 분리

업그레이드 후 갑자기 종료되는 현상은 프로그램 자체가 손상된 것이 아니라 이전 데이터베이스, 테마 설정 또는 사용자 지정 설정이 새 구조와 호환되지 않아서일 수도 있습니다. 먼저 구독 주소와 필요한 설정을 백업한 뒤 클라이언트를 종료하세요. 원본 데이터 디렉터리를 바로 삭제하지 말고 이름을 바꿔 클라이언트가 빈 설정으로 시작하게 하세요. 빈 설정에서는 정상 실행된다면 문제는 사용자 데이터에 있습니다. 이때 이전 디렉터리 전체를 한 번에 덮어쓰지 말고 구독과 설정을 단계적으로 복원하세요.

사용자 지정 JSON 설정은 코어 시작 실패의 가장 흔한 원인입니다. 먼저 클라이언트가 생성한 일반 노드 설정으로 전환해 코어 실행 여부를 확인한 뒤 사용자 지정 파일을 점검하세요. JSON에는 후행 쉼표를 사용할 수 없고 문자열의 백슬래시와 큰따옴표를 올바르게 처리해야 하며 필드 유형도 코어 요구 사항에 맞아야 합니다. 아래 명령으로 JSON 기본 문법을 확인할 수 있으며 파일 이름은 실제 경로로 바꾸세요.

python -m json.tool config.json

문법이 올바르다고 해서 설정 의미까지 올바른 것은 아닙니다. 존재하지 않는 아웃바운드 태그, 잘못된 라우팅 규칙 참조, 중복 수신 포트와 현재 코어에서 지원하지 않는 필드도 로드 단계에서 실패를 일으킬 수 있습니다. 로그에 표시된 첫 번째 오류부터 수정하세요. 이후 오류는 첫 실패가 연쇄적으로 만든 결과일 수 있습니다.

권한, 보안 정책과 시스템 리소스 확인

TUN 모드는 가상 네트워크 어댑터를 만들고 라우팅을 변경하므로 일반 권한만으로는 활성화 순간 종료될 수 있습니다. 먼저 TUN을 끄고 일반 시스템 프록시 모드가 실행되는지 확인하세요. 일반 모드는 정상인데 TUN에서 충돌한다면 관리자 권한, 가상 네트워크 어댑터 상태와 시스템의 다른 VPN 계열 네트워크 드라이버를 확인하세요. 여러 가상 네트워크 어댑터가 동시에 기본 경로를 변경하면 코어가 시작된 뒤 네트워크를 잃고 반복 재시작할 수도 있습니다.

보안 소프트웨어가 코어 하위 프로세스를 격리하거나 로컬 포트 수신을 막거나 설정 디렉터리 읽기를 제한할 수 있습니다. 시스템 보안 기록에서 클라이언트 시작 시간과 일치하는 이벤트를 확인하고 명확한 기록에 따라 처리하세요. 모든 보호 기능을 무작정 끄지는 마세요. 프로그램 디렉터리에 쓰기 권한이 없으면 로그와 데이터베이스 생성도 실패할 수 있습니다. 현재 사용자가 읽고 쓸 수 있는 위치에 클라이언트를 설치하고 압축 파일 미리보기 창에서 직접 실행하지 마세요.

일정 시간 실행한 뒤 충돌한다면 메모리, 디스크 여유 공간과 로그 용량도 관찰하세요. 연결량이 많은 환경에서 지나치게 상세한 로그는 빠르게 커지고 디스크 부족은 설정 저장과 업데이트에 영향을 줍니다. 이전 로그를 정리한 뒤 로그 수준을 일반으로 되돌리고 다시 재현하세요. 특정 노드에서만 충돌한다면 해당 노드를 복제해 필드를 비교하세요. 빈 설정에서도 계속 충돌한다면 운영체제, 클라이언트 이름, 충돌 시간과 시스템 이벤트 정보를 기록하고 현재 아키텍처에 맞는 클라이언트를 다시 설치하세요. 점검 중에는 많은 구독을 한꺼번에 가져오지 말아 설정 문제와 실행 환경 문제를 섞지 않도록 하세요.

연결 버튼이 작동하지 않거나 VPN 권한 부여 실패

처음 연결을 시작하면 시스템에 VPN 연결 확인 화면이 표시됩니다. 확인하지 않았거나 다른 VPN 서비스가 이미 실행 중이거나 업무 프로필 정책이 제한하는 경우 인터페이스를 만들 수 없습니다. 다른 VPN 앱을 먼저 연결 해제한 뒤 클라이언트로 돌아가 연결을 다시 시작하고 시스템 확인을 완료하세요. 상태 표시줄의 VPN 아이콘은 인터페이스가 만들어졌다는 뜻일 뿐입니다. 노드 핸드셰이크가 성공했는지는 클라이언트 로그에서 확인해야 합니다. 연결 직후 중지된다면 노드 설정, 현재 네트워크와 앱 백그라운드 권한을 확인하고 시작 버튼만 반복해서 누르지 마세요.

한 클라이언트에서 다른 클라이언트로 전환할 때는 기존 클라이언트에서 먼저 서비스를 중지한 뒤 새 클라이언트를 여세요. v2rayNG는 Xray 코어를 사용하고 v2flyNG는 v2fly 코어를 사용합니다. 둘은 Android에서 선택할 수 있는 서로 다른 클라이언트지만 시스템 VPN을 동시에 만들면 안 됩니다. 구독은 각각 가져와 테스트하되 노드 매개변수는 동일하게 유지해 클라이언트 차이와 노드 차이를 혼동하지 마세요. 다시 설치해야 한다면 Android 클라이언트 입구에서 v2rayNG 또는 v2flyNG를 선택하고 기기 아키텍처에 맞는 설치 패키지를 우선 사용하세요.

백그라운드 연결 해제와 네트워크 전환 처리

시스템 배터리 최적화가 화면이 꺼진 뒤 클라이언트의 백그라운드 실행을 제한할 수 있습니다. 현재 사용하는 클라이언트를 백그라운드 실행 허용 목록에 추가하고 자동 시작 또는 백그라운드 활동을 허용하세요. 기기마다 배터리 최적화, 백그라운드 사용, 전원 관리 또는 절전 앱 등 이름이 다를 수 있습니다. 실제 사용하는 클라이언트만 조정하면 되며 모든 네트워크 앱의 제한을 풀 필요는 없습니다. 설정 후 몇 분간 화면을 잠갔다가 다시 열어 웹페이지와 로그를 확인하고 서비스가 계속 실행 중인지 확인하세요.

무선 네트워크에서 모바일 네트워크로 전환하면 로컬 IP, DNS와 기본 경로가 모두 바뀝니다. 대부분의 경우 클라이언트가 연결을 자동으로 다시 만들지만 이전 연결이 잠시 남을 수 있습니다. 네트워크 전환 후 접속할 수 없다면 서비스를 한 번 중지했다가 다시 시작해 VPN 인터페이스를 현재 네트워크에 다시 연결하세요. 두 네트워크를 자주 오가면 테스트 결과가 뒤섞이므로 점검할 때는 한 네트워크에서 검증을 끝낸 뒤 다른 네트워크를 테스트하세요. 특정 네트워크에서만 실패한다면 노드 시간 초과와 DNS 섹션으로 돌아가 해당 네트워크의 접근 가능성을 확인하세요.

앱 분할 라우팅과 비공개 DNS 확인

Android의 앱 분할 라우팅에서는 어떤 앱을 VPN에 포함할지 선택할 수 있습니다. 허용 목록 방식을 사용하면 새로 설치한 앱이 기본적으로 클라이언트를 거치지 않을 수 있고, 제외 목록 방식을 사용하면 제외된 브라우저도 프록시를 사용하지 않습니다. “특정 앱 하나만 작동하지 않음”을 점검할 때는 먼저 해당 앱이 선택됐는지 확인한 뒤 앱 분할 라우팅을 잠시 꺼서 비교하세요. 모든 앱이 정상이라면 분할 라우팅을 다시 켜고 규칙에 앱을 하나씩 추가하세요. 시스템 구성 요소, 다운로드 관리 앱과 브라우저가 호출하는 외부 서비스는 서로 다른 프로세스일 수 있으므로 대표 앱 하나만 선택해도 전체 요청 경로가 포함되지 않을 수 있습니다.

시스템 비공개 DNS는 VPN 외부 또는 내부에 또 다른 확인 경로를 만들 수 있으며 실제 동작은 시스템과 클라이언트 설정에 따라 다릅니다. 도메인은 실패하지만 IP에는 접속할 수 있다면 먼저 비공개 DNS를 자동으로 되돌려 비교한 뒤 클라이언트 DNS를 확인하세요. 브라우저 자체의 보안 DNS도 코어 규칙을 우회할 수 있으므로 점검 중에는 기본 설정을 유지하세요. 클라이언트 DNS가 정상임을 확인한 뒤 시스템 수준의 사용자 지정 확인을 다시 사용할지 결정하세요.

LAN 접속이 실패하면 LAN 우회가 켜져 있는지, 앱이 사설 주소에 접속하려는지 확인하세요. 일부 기기는 VPN을 켜면 VPN을 통하지 않는 연결을 기본적으로 차단해 프린터, 라우터 관리 페이지 또는 LAN 서비스에 접근하지 못하게 할 수 있습니다. 클라이언트에서 사설 주소에 대한 명확한 직접 연결을 설정하고 VPN 외부의 모든 트래픽을 차단하는 엄격한 옵션이 시스템에 켜져 있지 않은지 확인하세요. 변경 후 LAN 주소와 외부 웹페이지를 각각 테스트해 직접 연결 범위가 과도하게 넓어지지 않았는지 확인하세요.

QR 코드 가져오기 후 연결에 실패한다면 프로토콜, 주소, 포트, 사용자 식별자, 보안 계층, 서버 이름과 전송 경로를 항목별로 비교하세요. 카메라 인식 과정에서 긴 내용이 잘리거나 클립보드에 줄바꿈이 남을 수 있습니다. 여러 노드를 수동으로 스캔하는 것보다 구독 가져오기가 업데이트에 편리하지만, 구독 업데이트가 실패하면 이 페이지의 구독 섹션에 따라 확인해야 합니다. 마지막으로 안정적으로 재현 가능한 노드 하나를 남겨 무선 네트워크와 모바일 네트워크에서 각각 테스트하세요. 한 네트워크에서만 실패하면 경로 문제이고, 두 네트워크 모두 실패하지만 데스크톱에서 같은 설정이 작동한다면 Android 클라이언트의 DNS, 앱 분할 라우팅과 전송 필드를 중점적으로 비교하세요.

앱이 백그라운드에서 안정적으로 실행되지만 메시지나 동기화가 지연된다고 해서 모든 앱을 바로 프록시에 추가하지 마세요. 먼저 대상 앱이 시스템 절전 정책의 제한을 받는지, 제외된 시스템 구성 요소에 의존하는지, 해당 도메인이 예상한 라우팅에 매칭되는지 확인하세요. Android 문제 해결의 핵심은 시스템 VPN, 클라이언트 코어와 앱 권한을 따로 검증하는 것입니다. VPN 인터페이스가 존재하고, 코어 연결이 성공하며, 대상 앱이 인터페이스에 들어가야 전체 연결 경로가 완성됩니다.