V2Ray 연결 문제 해결 가이드

인터넷에 연결되지 않을 때: 요청이 어디까지 전달되는지 확인

‘연결 성공’은 보통 클라이언트가 코어를 시작했거나 로컬 서비스를 실행했다는 뜻일 뿐, 브라우저 요청이 목적지 웹사이트까지 도달했다는 의미는 아닙니다. 문제를 진단할 때는 앱, 로컬 인바운드, 라우팅 선택, 원격 아웃바운드, 대상 서비스의 5단계로 나눠 살펴보세요. 다른 프록시 프로그램을 종료하고 특정 웹사이트 하나를 정해 반복 테스트하면서 v2rayN 로그 창을 확인합니다. 처음부터 프로토콜 변경, DNS 수정, TUN 활성화, 라우팅 초기화를 한꺼번에 하지 마세요. 여러 설정을 동시에 바꾸면 연결이 복구되어도 실제 원인을 파악하기 어렵습니다.

기본 네트워크와 로컬 수신 대기

먼저 시스템 프록시를 해제한 뒤 평소 직접 접속되는 웹사이트를 열어 보세요. 그래도 실패한다면 Wi-Fi 연결, 게이트웨이, 포털 인증, 시스템 시간을 확인하고 필요하면 같은 기기에서 다른 네트워크로 바꿔 테스트하세요. 웹 인증을 완료한 뒤 클라이언트 연결을 다시 시작합니다. 기본 네트워크가 복구되기 전에는 프록시 로그의 시간 초과만으로 별도의 원인을 진단하기 어렵습니다. 클라이언트를 종료한 뒤 모든 브라우저에서 인터넷이 끊긴다면 원격 서버 문제로 단정하지 말고, 시스템 프록시가 로컬 포트를 가리킨 채 남아 있는지 확인하세요.

이어서 v2rayN에서 대상 서버를 활성 서버로 선택하고 코어 시작 오류가 표시되는지 확인합니다. 관련 설정에서 로컬 수신 주소와 포트를 확인한 다음 브라우저나 시스템 프록시가 같은 포트를 사용하는지 살펴보세요. 온라인 화면에 나온 포트 번호가 항상 고정이라고 가정하지 마세요. 설정과 인바운드 유형에 따라 값이 다를 수 있습니다. 로그에 포트 사용 중이라고 표시되면 다른 클라이언트를 종료한 뒤 코어를 다시 시작하세요. 포트를 바꿔야 한다면 해당 포트를 사용하는 앱 설정도 함께 변경해야 합니다. 그렇지 않으면 로컬 서비스가 정상이어도 요청을 받지 못합니다.

로그로 인바운드와 아웃바운드 확인

웹페이지를 다시 열고 그 시점에 새 연결 로그가 추가되는지 살펴보세요. 기록이 없다면 먼저 앱의 요청 경로를 확인합니다. 브라우저 확장 프로그램이 시스템 프록시를 덮어쓰는지, 앱에 별도 프록시 설정이 있는지, 대상 주소가 시스템 우회 목록에 포함되는지 확인하세요. 로그 기록 여부는 로그 수준의 영향을 받으므로 창이 비어 있다는 이유만으로 결론 내리지 마세요. 현재 실행 중인 코어의 로그를 보고 있는지 확인하고 연결을 확인할 수 있는 수준으로 잠시 조정합니다. 진단이 끝나면 로그 수준을 원래대로 돌려 불필요한 기록이 쌓이지 않게 하세요.

요청이 코어에 들어왔지만 direct로 분류된다면 상태 표시줄의 라우팅 모드와 사용자 지정 규칙 순서를 확인하세요. 라우팅은 보통 규칙을 순서대로 검사하므로, 범위가 넓은 직접 연결 규칙이 앞에 있으면 뒤의 프록시 규칙이 적용되지 않을 수 있습니다. 분할 라우팅 문제인지 확인하려면 잠시 전역 프록시 모드로 바꿔 비교한 뒤 테스트가 끝나면 원래 모드로 되돌리세요. ‘전역’은 클라이언트 내부의 라우팅 선택을 뜻합니다. 시스템의 모든 프로그램이 자동으로 연결되는 것은 아니며, 로컬 프록시를 사용하지 않는 앱은 클라이언트를 우회할 수 있습니다.

전체 경로 문제와 특정 사이트 문제 구분

여러 웹사이트에서 문제가 발생한다면 서버 연결 및 DNS 절을 이어서 확인하세요. 한 사이트만 문제라면 먼저 다른 브라우저 세션으로 열어 보고, 사이트 점검 중인지, 로그인이 필요한지, 정적 리소스 도메인이 다른 라우팅 규칙을 적용받는지 살펴보세요. 페이지의 글자는 보이지만 이미지가 계속 로딩된다면 페이지가 여러 도메인에 의존할 수 있습니다. 주소 표시줄의 기본 도메인만 확인해서는 충분하지 않습니다. 페이지 전체를 반복해서 새로고침하기보다 같은 시점의 요청을 규칙과 대조하면 차이를 찾기 쉽습니다.

서버 연결 시간 초과: 주소 연결과 프로토콜 핸드셰이크 분리

시간 초과는 특정 단계가 제한 시간 안에 완료되지 않았다는 뜻이지, 그 자체로 서버가 작동하지 않는다는 증거는 아닙니다. 클라이언트의 테스트 기능은 TCP 연결, 프록시를 통한 테스트 주소 접속 등 서로 다른 방식을 사용할 수 있으므로 측정 대상도 다릅니다. 먼저 기능 이름과 로그를 확인한 뒤 브라우저에서 실제 요청을 보내 재현해 보세요. 테스트 주소 자체에 문제가 있으면 서버 목록의 테스트 결과가 모두 비정상일 수 있습니다. 이를 근거로 서버를 한꺼번에 삭제하거나 기존 구독을 덮어쓰지 마세요.

주소, 포트, 연결 단계부터 확인

서버 편집 창에서 주소가 빠짐없이 입력됐는지, 포트가 서비스 제공자가 안내한 값인지, 복사 과정에서 공백이나 줄바꿈이 들어갔는지 확인하세요. 주소가 도메인이라면 시스템에서 해당 도메인을 확인할 수 있는지도 살펴봅니다. 원격 주소에 연결하는 단계에서 로그에 시간 초과가 표시되면 네트워크 경로, 서버 접속 가능 여부, 포트를 우선 확인하세요. 연결이 완료된 뒤 TLS 또는 인증 오류가 발생한다면 전송 보안과 프로토콜 매개변수를 살펴봐야 합니다. 두 오류를 같은 문제로 보고 설정을 바꾸면 진단 시간만 길어질 수 있습니다.

같은 기기에서 다른 네트워크로 전환해 테스트하면 로컬 네트워크 제한과 서버 문제를 구분하는 데 도움이 됩니다. 같은 네트워크에서 정상 작동이 확인된 다른 설정을 사용하면 특정 서버에 문제가 집중되는지 확인할 수 있습니다. 비교할 때는 클라이언트, 대상 웹사이트, 라우팅 모드를 그대로 유지하세요. 회사 네트워크에서 테스트한다면 포털 인증이 필요한지, 지정된 출구를 이용해야 하는지 확인하고 네트워크 사용 규정을 준수하세요. 테스트를 통과하려고 시스템의 인바운드 방화벽을 함부로 열지 마세요. 아웃바운드 연결 실패와 로컬 서비스를 외부에 공개하는 일은 별개입니다.

TLS, 전송 방식, REALITY 설정

연결이 성립된 뒤 인증서 관련 오류가 발생하면 먼저 기기의 날짜, 시간, 시간대를 맞추고 서버 이름 설정이 설정 출처와 일치하는지 확인하세요. TLS 서버 이름과 연결 주소는 서로 다를 수 있지만, 경험에만 의존해 서로 바꿔 입력해서는 안 됩니다. 인증서 체인을 신뢰할 수 없는 경우, 이름이 일치하지 않는 경우, 핸드셰이크 시간 초과는 각각 다른 문제이므로 전체 오류 문구에 따라 처리하세요. 인증서 검증을 끄는 것은 일반적인 해결 방법이 아닙니다. 설정 오류를 숨길 수 있고 연결 상대의 신원 확인도 약화됩니다. 서버 이름, 시간 또는 서버 인증서 조건을 올바르게 수정하세요.

WebSocket 또는 gRPC를 사용하는 경우 전송 유형, 경로, Host 또는 서비스 이름을 항목별로 비교하세요. 경로의 대소문자, 앞의 슬래시, 서비스 이름의 문자 하나도 일치 여부에 영향을 줄 수 있습니다. 포트에 연결된다고 해서 이 설정이 올바르다는 뜻은 아닙니다. 공유 링크로 가져온 설정도 각 항목이 제대로 인식됐는지 확인하세요. 원본 형식이 클라이언트에서 지원되지 않으면 일부 항목이 빠질 수 있습니다. 전송 유형을 자유롭게 바꿀 수 있는 속도 향상 옵션처럼 취급하지 마세요. 클라이언트와 서버에서 호환되는 설정을 사용해야 합니다.

VLESS와 REALITY를 함께 사용할 때는 서버에서 지정한 서버 이름, 공개 키, 짧은 ID, 흐름 제어 요구사항을 확인하세요. 각 항목의 역할은 서로 다르므로 대체할 수 없습니다. 선택한 코어가 해당 조합을 지원하는지도 확인해야 합니다. v2rayNG와 v2flyNG는 서로 다른 코어 계열을 사용하므로 같은 공유 링크가 두 앱에서 동일하게 작동한다고 가정하지 마세요. 가장 확실한 복구 방법은 유효한 설정을 다시 받아 전체를 가져온 뒤 테스트하는 것입니다. 서로 다른 안내에서 비슷해 보이는 항목을 골라 조합하지 마세요.

재시도 간격과 결과 기록

짧은 간격으로 계속 다시 불러오면 일시적인 네트워크 복구, 서버 연결 제한, 이전 프로세스 종료가 서로 겹칠 수 있습니다. 설정을 바꿀 때마다 코어가 완전히 시작될 때까지 기다리고, 명확한 요청을 한 번만 보낸 뒤 해당 시점의 첫 오류를 확인하세요. 오류가 연달아 나타난다면 가장 먼저 발생한 문제부터 처리하는 것이 좋습니다. 뒤따르는 연결 종료는 앞선 실패의 결과일 수 있습니다. 어떤 네트워크에서 어느 서버를 통해 어떤 대상에 접속했고 어느 단계에서 멈췄는지 기록하고, 정상 설정을 복구용으로 보관하세요. 시간 초과 메시지만 캡처하는 것보다 훨씬 유용합니다.

설정 제공자에게 문의할 때는 원격 연결 단계에서 실패했는지, TLS 이후에 실패했는지 설명하고 민감한 내용을 가린 로그 일부를 첨부하세요. 전체 구독 링크나 인증 정보는 보내지 마세요. 다른 서버는 안정적으로 작동하는데 해당 설정만 네트워크를 바꿔도 같은 핸드셰이크 단계에서 계속 멈춘다면 로컬 라우팅을 더 수정해도 효과가 적습니다. 원격 서비스 상태와 설정 유효 기간을 확인하세요. 자주 사용하는 항목의 의미는 FAQ에서 확인할 수 있습니다. 네트워크 시간 초과와 프로토콜 비호환 문제를 혼동하지 마세요.

구독 오류: 가져오기 실패와 내용 해석 실패 구분

구독 업데이트는 두 단계로 진행됩니다. 먼저 구독 주소에서 응답을 가져오고, 그 응답을 클라이언트가 인식할 수 있는 서버 항목으로 해석합니다. ‘업데이트 실패’ 메시지가 표시되면 연결, 인증서, 상태 코드, 형식 해석 중 어느 단계에서 오류가 났는지 로그를 확인하세요. 브라우저에서 주소가 열리더라도 응답이 구독 데이터라는 보장은 없습니다. 로그인 페이지, 인증 페이지, 계정 만료 안내가 표시될 수 있습니다. 웹페이지 내용을 저장해 반복해서 가져오지 말고, 한 번 가져오기에 실패했다고 계속 사용할 수 있는 서버 항목을 삭제하지도 마세요.

구독 주소와 가져오기 경로 확인

구독 그룹 설정에서 주소가 온전히 입력됐는지 확인하세요. 특히 끝부분의 매개변수, 복사 과정에서 섞인 공백, 메신저가 긴 링크를 잘라낸 경우를 살펴봅니다. 구독 주소에는 계정 접근 권한이 포함되는 경우가 많으므로 민감 정보로 취급하세요. 링크를 캡처 화면이나 게시판에 공개했다면 서비스 제공자가 허용하는 경우 링크를 재설정한 뒤 로컬 그룹을 업데이트하세요. 일반 웹페이지 주소, 사용자 대시보드 주소, 구독 API 주소는 서로 다릅니다. 출처가 분명한 구독 주소를 사용해야 합니다.

v2rayN에서는 현재 네트워크 환경에 따라 ‘프록시를 통하지 않고 구독 업데이트’ 또는 프록시를 통한 가져오기를 시도할 수 있습니다. 정확한 메뉴 이름은 버전에 따라 다를 수 있습니다. 직접 연결은 실패하지만 프록시는 작동한다면 기존에 사용할 수 있는 서버를 거쳐 업데이트할 수 있습니다. 프록시가 이미 작동하지 않는다면 그 프록시를 통해 구독을 가져오려는 시도는 순환 문제를 일으킬 수 있습니다. 원래 그룹은 보존하고, 실제로 사용할 수 있는 경로로 다시 시도하세요. 회사 네트워크의 웹 인증이나 로컬 네트워크 미연결도 예상과 다른 응답을 초래할 수 있습니다.

응답 유형에 따라 다음 단계 선택

로그에 HTTP 상태 코드가 있다면 접근 거부, 주소 없음, 요청 제한, 서버 오류를 구분하세요. 접근 권한 문제라면 구독이 만료됐는지, 주소의 매개변수가 온전한지 확인합니다. 요청이 너무 잦다면 계속 누르지 말고 기다렸다가 다시 시도하세요. 인증서 오류는 기기 시간과 로컬 신뢰 환경부터 확인합니다. 모든 오류 코드를 ‘클라이언트가 오래됨’으로 단정하지 마세요. 구독을 가져오려고 인증서 검증을 함부로 무시하면 실제 요청 경로의 문제를 놓칠 수 있습니다.

공유 링크 모음, Base64 인코딩 구독, 기본 JSON 설정은 파일 확장자만으로 형식을 구분할 수 없습니다. Base64는 인코딩 방식일 뿐, 올바른 서버 정보가 포함됐다는 뜻은 아닙니다. 기본 코어 JSON 설정도 일반 구독 입력란에 그대로 붙여넣기에 적합하지 않을 수 있습니다. 클라이언트에 맞는 가져오기 메뉴를 사용하고 지원되는 데이터 구조인지 확인하세요. 공유 링크 한 개만 있다면 먼저 클립보드에서 가져와 인식되는지 테스트하면 형식 문제와 원격 가져오기 문제를 구분할 수 있습니다.

업데이트된 그룹과 활성 서버

업데이트가 완료되면 대상 그룹에 예상한 서버 항목이 들어왔는지 확인하고 활성 서버를 다시 선택하세요. 구독 업데이트로 항목 이름이 바뀌거나 폐기된 설정이 제거될 수 있으므로 이전에 선택한 항목이 계속 유효하다고 볼 수 없습니다. ‘업데이트 성공’ 메시지만 보고 연결이 복구됐다고 판단하지 마세요. 서버 항목을 선택해 연결을 시작하고 정해 둔 웹사이트에 접속한 뒤 핸드셰이크 설정을 추가로 확인할지 결정하세요. 이름이 비슷한 그룹이 여럿이라면 업데이트한 그룹, 확인 중인 그룹, 연결에 사용한 그룹이 모두 같은지 점검하세요.

자동 업데이트 간격을 지나치게 짧게 설정하지 마세요. 자주 가져와도 잘못된 주소가 고쳐지지 않으며 오히려 API 요청 제한에 걸릴 수 있습니다. 기기가 절전 상태에서 깨어나거나 네트워크를 전환하는 시점에 예약 업데이트가 실행될 수도 있습니다. 수동 업데이트는 성공하고 자동 업데이트만 가끔 실패한다면 실패 시각과 기기 네트워크 상태의 관계부터 살펴보세요. 모든 설정을 바로 다시 만들 필요는 없습니다. 그룹 구조를 바꿔야 한다면 먼저 클라이언트 내보내기 기능으로 복구 가능한 사본을 만들고 안전한 위치에 보관하세요.

구독 형식과 변환 범위는 V2Ray 구독 형식 안내에서 자세히 확인할 수 있습니다. 진단 후에는 주소 권한, 가져오기 경로, 응답 형식, 설정 호환성 중 무엇이 문제였는지 정리해 두세요. 결론이 명확하면 누구에게 문의할지, 무엇을 수정할지 결정하기 쉽고 같은 오류가 났을 때 클라이언트 삭제부터 반복하는 일을 피할 수 있습니다.

속도 저하: 첫 응답, 지속 전송, 앱별 차이를 따로 확인

‘속도가 느리다’는 웹사이트를 열기 전 오래 기다리는 현상, 이미지가 끊겨 로딩되는 현상, 파일 전송 불안정, 동영상 버퍼링을 모두 가리킬 수 있습니다. 각각 병목 지점이 다릅니다. 어느 단계에서 느린지 먼저 파악한 다음 같은 기기, 네트워크, 대상, 서버로 조건을 고정해 테스트하세요. 서버 테스트 결과 하나로 실제 앱 사용 경험을 판단하지 마세요. 지연 시간은 왕복 또는 테스트 요청에 걸린 시간일 뿐 지속적인 전송 속도를 직접 나타내지 않으며, 특정 웹사이트의 서비스 상태도 보여주지 않습니다.

비교 가능한 테스트 환경 만들기

먼저 대용량 작업을 일시 중지하고 기기가 절전 모드인지, 무선 신호가 안정적인지 확인하세요. 백그라운드 동기화, 시스템 업데이트, 다른 기기의 네트워크 사용량 때문에 프록시 연결 속도가 들쭉날쭉해질 수 있습니다. 필요하다면 같은 네트워크에서 유선 연결과 비교하거나 무선 액세스 포인트 가까이에서 다시 테스트하세요. 한 번에 조건 하나만 바꾸세요. 서버, 네트워크, 브라우저를 동시에 바꾸면 어느 단계에서 개선됐는지 알 수 없습니다.

웹사이트를 처음 열 때만 느리고 이후 페이지는 괜찮다면 DNS 조회, 연결 설정, TLS 핸드셰이크를 중점적으로 살펴보세요. 페이지는 금방 나타나지만 큰 파일을 계속 느리게 받는다면 출구 대역폭, 원격 서버 부하, 대상 서비스의 속도 제한, 패킷 손실을 확인해야 합니다. 특정 동영상이나 다운로드 사이트만 느리다면 다른 종류의 콘텐츠와 비교하세요. 대상 서비스는 출구 위치, 계정, 콘텐츠 배포 지점에 따라 다르게 대응할 수 있으므로 로컬 포트 변경으로 해결되지 않을 수 있습니다.

실제 라우팅을 확인해 원인 오판 방지

느린 요청이 최종적으로 direct와 proxy 중 어디로 연결되는지 확인하세요. 특히 사이트의 이미지, 동영상, API 도메인을 살펴봅니다. 메인 페이지는 프록시를 통하지만 정적 리소스는 직접 연결되거나, 그 반대인 경우 일부 콘텐츠가 계속 기다릴 수 있습니다. 사용자 지정 규칙의 범위가 너무 넓다면 좁히고 규칙 위치를 확인하세요. 전역 모드 전환은 비교 테스트에 사용할 수 있지만 장기적인 해결책으로 단정해서는 안 됩니다. 전역 모드는 트래픽 경로를 바꿀 뿐 무선 간섭, 원격 서버 혼잡, 대상 서비스의 대기 시간을 없애지는 않습니다.

두 서버 설정을 비교할 때는 다른 조건을 그대로 유지하고 웹페이지 최초 접속과 지속 전송 경험을 나눠 기록하세요. 여러 대상에서 한 설정만 느리고 다른 설정은 정상이라면 해당 경로나 원격 자원이 원인일 수 있습니다. 모든 설정에서 같은 대상만 느리다면 해당 대상의 도메인 확인 및 서비스 정책을 살펴보세요. 특정 테스트 수치를 높이려고 코어를 연속해서 다시 불러오지 마세요. 기존 연결이 끊기고 캐시가 다시 만들어지면 측정이 왜곡되어 실제보다 느린 것처럼 보일 수 있습니다.

전송 설정과 네트워크 환경

다중화 기능을 무작정 켜거나 전송 방식을 임의로 바꾸지 마세요. 다중화의 효과는 프로토콜 지원 여부, 연결 방식, 서버 조건에 따라 달라지며 일부 환경에서는 여러 요청이 같은 혼잡 경로에 집중될 수 있습니다. WebSocket, gRPC 등 전송 방식도 서버 설정과 일치해야 하므로 클라이언트 드롭다운에서만 바꿔서는 안 됩니다. 온라인에서 본 ‘최적화 설정’을 적용하기 전에 해당 코어와 버전에서 사용할 수 있는지 확인하고 원본 설정을 백업하세요. 설명할 수 없는 설정을 계속 유지하기보다 한 항목씩 비교해 효과를 확인하세요.

TUN을 사용할 때 작은 웹페이지는 정상인데 일부 큰 응답이나 특정 앱에서 반복적으로 멈춘다면 경로 MTU와 네트워크의 패킷 처리 방식을 확인할 수 있습니다. 단, 로그와 비교 네트워크, 재현 조건을 먼저 확보해야 합니다. MTU를 낮추는 방법을 모든 속도 문제에 적용하지 마세요. 먼저 일반 시스템 프록시 경로로 같은 대상에 접속해 보세요. 해당 경로가 정상이라면 TUN, 네트워크 어댑터, 네트워크 환경을 집중적으로 확인합니다. 값을 바꾸기 전에 원래 설정을 기록해 개선되지 않을 때 되돌릴 수 있게 하세요.

문제 해결 후에는 평소 사용할 기준 조건을 정해 두세요. 테스트 웹사이트, 정상 작동이 확인된 서버 설정, 일반 라우팅 모드를 고정하면 됩니다. 다음에 문제가 생기면 최적화 방법을 처음부터 전부 적용하기보다 이 기준과 비교하세요. 시간대에 따라 현상이 뚜렷하게 달라진다면 발생 시각을 기록해 서비스 제공자에게 전달할 수 있습니다. 로컬 설정을 안정적으로 유지해야 결과를 비교할 수 있습니다. 분할 라우팅 규칙을 자세히 조정하려면 v2rayN 라우팅 설정 실전 안내를 참고하세요.

DNS 문제: 앱, 코어, 서버 주소의 도메인 확인 구분

DNS 문제는 도메인이 열리지 않거나 연결이 시작되기까지 오래 기다리거나 앱마다 결과가 다르게 나타나는 방식으로 드러날 수 있습니다. 진단 전에 세 가지 대상을 구분하세요. 운영체제가 도메인을 확인하는 방식, 클라이언트 코어가 대상 도메인을 확인하는 방식, 원격 서버에 연결할 때 사용하는 도메인을 확인하는 방식입니다. 브라우저가 별도의 보안 DNS를 사용해 시스템 경로를 우회할 수도 있습니다. DNS 주소 하나를 바꾼다고 모든 단계가 함께 바뀌는 것은 아니므로 실제 오류를 낸 조회가 어디서 시작됐는지 확인해야 합니다.

오류 문구로 도메인 확인 단계 파악

로그에 원격 서버 주소를 확인할 수 없다고 표시되면 먼저 서버 도메인의 기본 DNS 확인을 복구하세요. 프록시 연결이 아직 만들어지지 않았다면 그 연결을 필요로 하는 원격 DNS도 시작할 수 없습니다. 원격 서버 연결은 정상이지만 대상 웹사이트의 도메인만 실패한다면 해당 조회에 사용된 DNS와 아웃바운드 경로를 확인하세요. 서버 주소를 검색해서 나온 IP로 무작정 바꾸고 진단을 끝내지 마세요. 일부 설정은 서버 이름, 인증서, 동적 주소에 의존하므로 IP로 바꾸면 잠시 문제가 우회되더라도 이후 관리에 문제가 생길 수 있습니다.

시스템 조회 도구는 시스템의 현재 DNS 결과만 확인할 수 있으며 브라우저나 코어가 같은 결과를 사용하는지는 보여주지 않습니다. 아래 명령을 터미널에서 실행해 시스템 조회 결과를 비교하세요. 테스트 도메인은 공개 예시 주소이며 계정 정보가 포함되지 않습니다. 명령이 성공해도 앱 로그를 확인해 실제 연결 경로를 살펴봐야 합니다. 시스템 조회는 실패하지만 브라우저에서 사이트가 열린다면 브라우저 자체 조회 기능이나 캐시가 사용되고 있을 수 있습니다. 시스템 조회는 성공하는데 클라이언트에서 실패한다면 코어의 DNS 설정과 아웃바운드 의존성을 확인하세요.

nslookup example.com

라우팅 정책과 DNS 결과의 관계

Xray 라우팅을 예로 들면 domainStrategy는 라우팅 규칙을 찾을 때 도메인을 IP로 조회할 시점을 결정합니다. AsIs는 라우팅 규칙을 찾기 위해 도메인을 적극적으로 조회하지 않습니다. IPIfNonMatch는 도메인 규칙이 일치하지 않을 때 IP 규칙을 찾으려고 시도하고, IPOnDemand는 IP가 필요한 규칙을 확인할 때 도메인 조회를 시도합니다. 이는 라우팅 계층의 정책이지 DNS 서버 목록과 같은 설정이 아닙니다. 아웃바운드의 이름이 같거나 비슷한 필드와 혼동해서도 안 됩니다. 변경하기 전에 설정의 계층을 확인하세요.

아래는 라우팅 객체의 예시입니다. 해당 아웃바운드가 포함된 기존 설정에 병합해야 하며, 클라이언트 전체 설정으로 바로 실행해서는 안 됩니다. 클라이언트에 그래픽 라우팅 편집기가 있다면 먼저 해당 화면에서 수정하세요. 코어는 규칙을 순서대로 확인합니다. 예시는 지정한 도메인을 먼저 처리한 다음 사설 주소를 처리합니다. 실제 아웃바운드 태그는 현재 설정과 일치해야 합니다. 도메인이 코어에 도메인 형식으로 전달되는지는 앱에서 사용하는 프록시 프로토콜과 조회 방식에 따라서도 달라집니다.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

캐시, 암호화 DNS, 순환 의존성

DNS를 바꿔도 운영체제, 브라우저, 앱에 이전 결과가 남아 있을 수 있으며 이미 연결된 세션은 DNS 서버 변경만으로 자동 재연결되지 않습니다. 관련 웹페이지를 닫고 연결을 새로 만든 뒤 필요하다면 운영체제에서 제공하는 방법으로 캐시를 비우고 새 요청을 확인하세요. 조회가 어느 경로로 나가는지 확인하지 않은 채 암호화 DNS 기능을 여러 개 동시에 켜지 마세요. 브라우저, 클라이언트의 원격 DNS, 시스템 DNS가 겹치면 결과 차이를 설명하기 어려워지고 도메인 기반 라우팅도 제대로 확인하지 못할 수 있습니다.

프록시를 통해 접속해야 하는 DNS 서비스를 사용할 때는 순환 의존성을 주의해야 합니다. 프록시 서버의 도메인을 먼저 확인할 수 있어야 프록시 연결이 만들어지지만, 연결이 성립되지 않으면 프록시에 의존하는 DNS 서비스에도 접근할 수 없습니다. 클라이언트 기능에 맞춰 시작 단계에서 사용할 수 있는 DNS 경로를 마련하고 DNS 서비스 자체의 도메인을 어떻게 처리하는지도 확인하세요. 아직 사용할 수 없는 아웃바운드에 모든 DNS 트래픽을 맡기지 말고, 서로 다른 코어의 DNS 설정을 그대로 복사하지 마세요.

복구 여부를 확인할 때는 문제가 났던 도메인과 정상적인 다른 유형의 웹사이트를 모두 테스트하고 라우팅이 예상대로 적용되는지 확인하세요. 웹페이지가 다시 열려도 모든 연결의 출구가 바뀌었다면 분할 라우팅 진단은 끝난 것이 아닙니다. 로그에 geosite 또는 geoip 데이터가 없다고 나오면 규칙 데이터 로딩 문제입니다. DNS 서버를 계속 바꾸지 말고 시작 및 충돌 절에서 리소스를 확인하세요. 규칙 접두사와 우선순위는 Xray 사용자 지정 라우팅 규칙 문법을 참고하세요.

시스템 프록시가 작동하지 않을 때: 앱이 로컬 인바운드를 사용하는지 확인

시스템 프록시와 라우팅 모드는 서로 다른 단계의 설정입니다. 시스템 프록시는 시스템 프록시를 지원하는 앱에 요청을 어디로 보낼지 알려주고, 라우팅 모드는 코어에 들어온 요청이 어떤 아웃바운드로 나갈지 결정합니다. v2rayN에서 라우팅을 ‘전역’으로 바꿔도 운영체제의 모든 트래픽이 자동으로 처리되는 것은 아닙니다. 브라우저는 시스템 프록시를 따를 수 있지만 명령줄 도구, 게임, 다른 앱은 각자 별도 설정을 사용할 수 있습니다. 문제가 발생한 앱의 프록시 방식을 확인한 뒤 앱 내 설정이나 TUN이 필요한지 결정하세요.

상태 표시줄의 세 가지 옵션 이해

‘시스템 프록시 자동 설정’은 클라이언트가 필요한 시스템 프록시 설정을 적용합니다. ‘시스템 프록시 해제’는 관련 시스템 프록시 설정을 제거합니다. ‘시스템 프록시 변경 안 함’은 현재 상태를 클라이언트가 직접 수정하지 않는다는 뜻이지, 프록시를 자동으로 끄는 옵션이 아닙니다. 잘못된 설정이 남아 있다면 ‘변경 안 함’을 선택해도 기존 경로가 유지될 수 있습니다. 테스트 전 기존 설정을 기록해 회사 네트워크나 다른 소프트웨어 설정을 덮어쓰지 않도록 하고, 이번 테스트에 필요한 항목을 명확히 선택하세요.

운영체제의 네트워크 설정에서 프록시 주소와 포트를 확인하세요. 클라이언트 상태 표시줄의 표시만 확인해서는 충분하지 않습니다. 시스템 값이 예상과 다르다면 다른 프록시 소프트웨어, 브라우저 확장 프로그램, 자동 설정 스크립트, 관리 정책이 값을 바꿨을 수 있습니다. 프록시 클라이언트는 한 번에 하나만 실행하고, 프록시를 가로채는 브라우저 확장 프로그램을 잠시 비활성화한 뒤 다시 테스트하세요. 관리 대상 기기의 프록시 정책은 조직에서 일괄 적용할 수 있습니다. 설정이 자동으로 복구된다면 계속 덮어쓰려 하지 말고 관리 정책을 먼저 확인하세요.

수동 연결과 환경 변수

수동 프록시를 지원하는 앱이라면 클라이언트가 실제로 제공하는 로컬 주소와 포트를 임시로 입력해 비교 테스트할 수 있습니다. HTTP 인바운드는 앱에서 지원하는 HTTP 프록시 방식으로, SOCKS 인바운드는 SOCKS 설정으로 연결해야 합니다. 포트 번호가 비슷하다는 이유로 서로 바꿔 사용하지 마세요. 수신 주소가 로컬 기기로 제한되어 있으면 다른 기기에서 해당 포트에 연결할 수 없습니다. 로컬 문제를 진단할 때 LAN 접근을 허용할 필요는 없으며, 일반적인 해결 방법으로 수신 주소를 모든 네트워크 인터페이스에 열지 마세요.

명령줄 프로그램은 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 환경 변수를 읽을 수도 있고 무시할 수도 있습니다. 그래픽 설정에서 시스템 프록시를 바꿔도 이미 열려 있는 터미널의 프로세스 환경에는 적용되지 않을 수 있습니다. 명령줄에서만 문제가 발생하면 해당 도구의 프록시 안내와 현재 환경 변수를 확인하세요. 브라우저에서만 실패한다면 확장 프로그램, 설정 파일, 별도 프록시 설정을 살펴봅니다. 한 앱의 동작으로 전체 시스템 상태를 추측하지 마세요. 앱마다 동작이 다르다는 점이 요청 경로를 찾는 단서입니다.

TUN과 종료 후 설정 복구

TUN은 가상 네트워크 어댑터, 라우팅 테이블, 권한, DNS 처리에 영향을 줄 수 있는 별도의 트래픽 연결 방식이지 시스템 프록시의 다른 이름이 아닙니다. 시스템 프록시 경로가 정상 작동한다면 먼저 해당 경로의 기준 테스트를 완료한 뒤 TUN을 확인할지 결정하세요. 두 방식이 동시에 켜져 있고 설정도 명확하지 않으면 일부 트래픽이 우회하거나 순환할 수 있습니다. 권한 요청이 표시되면 필요한 권한만 허용하세요. 클라이언트를 계속 높은 권한으로 실행하는 것을 유일한 해결 방법으로 삼지 마세요.

클라이언트를 종료한 뒤 네트워크가 바로 끊긴다면 시스템 프록시가 더 이상 수신하지 않는 로컬 포트를 가리키고 있는지 확인하세요. 클라이언트를 다시 열어 ‘시스템 프록시 해제’를 실행한 다음 운영체제의 네트워크 설정에서 복구됐는지 확인하고 앱별 수동 프록시도 점검합니다. 프로세스를 강제 종료하거나 시스템이 비정상적으로 종료되거나 소프트웨어가 충돌하면 종료 과정의 설정 정리가 중단될 수 있습니다. 먼저 남은 설정을 복구한 뒤 재설치 여부를 검토하세요. 프로그램을 다시 설치해도 운영체제에 별도로 저장된 프록시 설정은 지워지지 않을 수 있습니다.

같은 브라우저에서 새 요청을 보내 로그에 해당 연결이 표시되는지 확인한 뒤 아웃바운드 태그가 라우팅 설정과 일치하는지 살펴보세요. 요청 경로는 복구됐지만 잘못된 아웃바운드를 사용한다면 분할 라우팅 규칙을 다시 확인해야 합니다. 시스템 프록시를 계속 바꾸지 마세요. 데스크톱 환경마다 프록시 설정 지원 범위가 다르며 특히 Linux 앱은 각자 다른 네트워크 스택을 사용할 수 있습니다. 필요하면 앱에 프록시를 직접 설정하세요. 처음 설정하는 경우 사용 가이드를 참고해 반복 가능한 연결 절차를 마련할 수 있습니다.

시작 및 충돌: 앱 화면, 코어, 설정 리소스를 나눠 확인

클라이언트 창이 열리지 않는 문제, 창은 열리지만 코어가 시작되지 않는 문제, 연결 도중 프로세스가 종료되는 문제는 서로 다릅니다. 먼저 문제가 발생한 시점을 기록하세요. 프로그램을 두 번 클릭하자마자 종료되는지, 서버를 선택한 뒤 오류가 표시되는지, 구독이나 규칙을 업데이트한 뒤 문제가 시작됐는지 확인합니다. v2rayN의 그래픽 인터페이스와 프록시 코어는 서로 다른 역할을 합니다. 화면이 정상적으로 열려도 코어가 실행 중이라는 뜻은 아니며 코어가 종료됐다고 해서 클라이언트 전체가 충돌한 것도 아닙니다. 앱 안내, 코어 로그, 시스템 오류 기록을 각각 확인하세요.

설치 파일, 아키텍처, 실행 환경

먼저 설치 파일의 대상이 기기의 운영체제와 프로세서 아키텍처에 맞는지 확인하세요. 데스크톱에서는 v2rayN을 우선 사용할 수 있습니다. Windows 데스크톱 버전과 클래식 WPF 버전은 인터페이스와 실행 환경 요구사항이 다를 수 있습니다. macOS와 Linux도 칩과 배포판에 맞는 다운로드 항목을 선택해야 합니다. 프로그램을 다시 받아야 한다면 클라이언트 다운로드에서 플랫폼 안내를 확인하세요. 파일 아이콘만 보고 아키텍처를 판단하지 말고, 오래된 폴더에서 실행 파일 하나만 임의로 꺼내 바꾸지도 마세요. 프로그램과 관련 리소스가 서로 맞지 않을 수 있습니다.

프로그램에 실행 환경이 필요하다면 설치 안내와 시스템 오류에 따라 필요한 구성 요소를 추가하세요. 이름이 비슷한 구성 요소를 아무거나 내려받지 마세요. 설치 위치에 쓰기와 실행 권한이 있는지, 제한된 폴더에 있는지, 보안 소프트웨어가 프로그램이나 리소스를 차단했는지 확인하세요. 차단 기록을 살펴본 뒤 조치 방법을 결정하고 보안 기능 전체를 바로 끄지 마세요. Linux에서는 파일 권한과 데스크톱 실행 항목도 확인해야 합니다. macOS에서는 시스템이 표시하는 보안 및 권한 안내에 따라 프로그램 출처와 허용 방법을 확인하세요.

첫 번째 오류부터 코어 시작 실패 진단

코어 로그에 수신 대기 실패가 표시되면 주소가 올바른지 또는 포트를 다른 프로그램이 사용 중인지 먼저 확인하세요. 설정을 해석하지 못한다는 오류라면 JSON 문법, 필드 위치, 현재 코어의 지원 범위를 살펴봅니다. JSON에는 마지막 항목 뒤에 쉼표를 쓸 수 없으며 필드 값의 자료형도 정확해야 합니다. 숫자, 문자열, 불리언 값을 임의로 바꾸지 마세요. 그래픽 클라이언트에서 설정을 생성한다면 해당 화면의 원본 설정부터 수정하세요. 임시로 생성된 파일을 직접 수정하면 다음에 다시 불러올 때 덮어써져 ‘고쳤는데 또 문제가 생김’이 반복될 수 있습니다.

listen tcp 127.0.0.1:1080: bind: address already in use

위 문구는 포트 사용 중 오류의 대표적인 예이며, 포트 번호는 설명용일 뿐 클라이언트의 기본 포트를 뜻하지 않습니다. 어떤 프로그램이 포트를 사용 중인지 확인한 뒤 충돌한 프로그램을 종료하거나 클라이언트의 수신 포트를 바꾸고 앱의 프록시 설정도 함께 수정하세요. 용도를 모르는 시스템 프로세스를 강제 종료하지 마세요. 이전 코어 프로세스가 끝나지 않았다면 클라이언트를 정상 종료하고 기다린 뒤 다시 시작하세요. 프로세스가 계속 남는다면 보안 소프트웨어의 간섭, 권한, 종료 로그를 확인해야 합니다. 단순히 재시작만 반복하지 마세요.

규칙 데이터, 코어 호환성, 설정 복구

geosite 또는 geoip 오류가 발생하면 데이터 파일이 있는지, 읽을 수 있는지, 참조한 컬렉션이 현재 데이터에 포함되어 있는지 확인하세요. 규칙 이름의 오타와 파일 누락은 서로 다른 문제이므로 데이터를 업데이트해도 잘못된 컬렉션 이름은 해결되지 않습니다. 다른 코어 환경에서 가져온 사용자 지정 규칙은 현재 코어에서 인식하지 못하는 필드를 포함할 수 있습니다. 최근 추가한 규칙 하나를 되돌려 코어가 시작되는지 확인한 뒤 하나씩 다시 적용하세요. 라우팅을 전부 지우는 것보다 유효한 설정을 보존하기 쉽습니다.

Xray와 V2Fly 계열 코어를 전환할 때는 프로토콜, 전송 방식, 확장 필드의 호환성을 다시 확인해야 합니다. 두 코어는 관련 생태계에 속하지만 모든 설정이 공통으로 작동하는 것은 아닙니다. 특정 코어에서만 오류가 난다면 해당 코어가 명확히 지원하는 설정으로 먼저 정상 작동 기준을 만든 다음 차이를 확인하세요. 파일 이름만 바꿔 코어를 강제로 교체하거나 한 코어에서만 사용하는 필드를 다른 코어 설정에 그대로 두지 마세요. 클라이언트가 제공하는 전환 메뉴와 설정 생성 방식을 함께 사용해야 합니다.

사용자 데이터를 불러오는 중 인터페이스가 충돌한다면 프로그램을 종료하고 클라이언트 데이터 폴더를 백업한 뒤, 클라이언트가 지원하는 방식으로 별도의 새 설정을 만들어 비교 테스트하세요. 그룹, 라우팅, 구독 정보가 들어 있을 수 있으므로 원래 폴더를 바로 삭제하지 마세요. 새 설정이 정상이라면 설정을 나눠 복구해 손상되었거나 호환되지 않는 항목을 찾습니다. 새 설정에서도 문제가 계속되면 실행 환경, 권한, 시스템 로그를 확인하세요. 오류를 자세히 살펴보려면 v2rayN 코어 시작 오류 진단을 참고하세요.

모바일 문제: VPN 권한, 앱별 라우팅, 백그라운드 제한

Android의 v2rayNG와 v2flyNG는 대개 시스템 VPN 인터페이스를 통해 앱 트래픽을 연결하므로 데스크톱의 시스템 프록시와 진단 경로가 다릅니다. 상태 표시줄의 VPN 아이콘은 시스템에 해당 연결 상태가 있다는 뜻일 뿐, 원격 핸드셰이크와 대상 사이트 접속까지 성공했다는 의미는 아닙니다. 클라이언트에서 활성 설정을 선택해 연결을 시작하고 로그를 확인한 뒤, 한 브라우저에서 정해 둔 사이트를 테스트하세요. 두 앱은 서로 다른 코어 계열을 사용하므로 특정 프로토콜과 전송 조합을 쓸 때는 호환성을 확인해야 합니다. 화면이 비슷하다는 이유로 동작도 같다고 가정하지 마세요.

시스템 권한과 VPN 충돌

처음 연결할 때 시스템 VPN 권한을 허용해야 합니다. 권한 요청을 취소했거나 시스템 정책이 차단했다면 로컬 트래픽이 예상대로 클라이언트에 전달되지 않습니다. 로컬 네트워크 필터나 업무용 도구처럼 VPN 인터페이스를 사용하는 다른 앱이 실행 중인지 확인하세요. 같은 연결 지점을 두 앱이 함께 사용하려 하면 한 앱을 시작할 때 다른 앱에 영향을 줄 수 있습니다. 충돌하는 앱을 먼저 중지한 뒤 다시 연결하고 시스템 안내를 확인하세요. 조직에서 관리하는 기기에는 별도 제한이 있을 수 있으므로 허용된 사용 방법을 먼저 확인해야 합니다.

시스템의 ‘항상 켜진 VPN’과 ‘VPN 연결 없이 차단’ 옵션은 연결이 끊겼을 때의 네트워크 동작을 바꿉니다. 클라이언트가 실행 중이 아니거나 연결이 성립되지 않았는데도 모든 연결을 VPN으로 보내도록 설정되어 있으면 기기에서 인터넷에 전혀 접속하지 못할 수 있습니다. 이러한 옵션을 확인할 때는 목적을 이해하고 원래 상태를 기록한 뒤 비교하세요. 연결 중단 방지 기능이 네트워크를 차단한 상황을 Wi-Fi 문제로 오해하지 마세요. 네트워크 설정을 전부 초기화하기 전에 클라이언트와 시스템 정책이 일치하는지 확인하세요.

앱별 규칙과 네트워크 전환

특정 앱 하나만 접속되지 않는다면 앱별 프록시 기능이 켜져 있는지, 선택한 앱만 프록시할지 선택한 앱을 우회할지 확인하세요. 두 모드는 방향이 반대이므로 같은 앱을 선택해도 결과가 서로 다릅니다. 목록을 수정한 뒤에는 새 규칙이 현재 연결에 적용되도록 화면의 안내에 따라 연결을 다시 설정해야 할 수 있습니다. 시스템 앱, 업무 프로필의 앱, 일반 설치 앱은 서로 다른 범위에 속할 수 있습니다. 이름이 같다는 이유만으로 올바른 앱이 선택됐다고 판단하지 마세요.

Wi-Fi에서는 정상이지만 모바일 데이터에서 실패한다면 연결을 끊고 대상 네트워크가 안정된 뒤 다시 시작하세요. 모바일 데이터 권한, 데이터 사용 제한, 포털 인증 상태도 확인합니다. 네트워크를 바꾸면 주소, 라우팅, DNS 환경이 달라져 기존 연결을 계속 사용할 수 없을 수 있습니다. 반대의 경우도 같은 방법으로 비교하되 서버와 테스트 사이트는 그대로 유지하세요. 특정 네트워크에서만 DNS 또는 원격 연결 오류가 발생한다면 해당 절로 돌아가 진단하세요. 구독 항목은 네트워크 종류가 바뀐다고 자동으로 무효가 되지 않으므로 바로 삭제하지 마세요.

화면 잠금 후 연결 끊김과 백그라운드 실행

앱을 사용 중일 때는 정상인데 화면을 잠근 뒤 연결이 끊긴다면 배터리 최적화, 백그라운드 활동, 시스템 자동 정리 규칙을 먼저 확인하세요. 설정 메뉴 위치는 기기마다 다르므로 시스템 앱 정보에서 관련 옵션을 찾아 지속 연결이 필요한 클라이언트에만 적용하세요. 절전 정책을 한꺼번에 모두 바꾸면 어떤 설정이 문제였는지 알기 어렵습니다. 설정 변경 후 화면을 잠시 잠갔다가 다시 켜고 클라이언트 프로세스, VPN 상태, 로그 시각을 확인해 프로세스 종료, 일시적인 네트워크 절전, 원격 연결 해제를 구분하세요.

최근 앱 화면에서 앱을 밀어 종료하거나 원터치 정리 기능을 실행하거나 초절전 모드를 켜면 백그라운드 서비스에 영향을 줄 수 있습니다. 시스템에 VPN 아이콘은 남아 있지만 앱 로그가 갱신되지 않는다면 클라이언트로 돌아가 실행 상태를 확인하고 필요하면 정상 종료 후 다시 시작하세요. 알림이 계속 표시되는지만 보고 연결 상태를 판단하지 마세요. 백그라운드 연결은 기기 자원을 계속 사용하므로 복구 후 배터리 소모, 네트워크 사용량, 안정성을 확인하세요. 재연결이 잦으면서 자원을 많이 사용한다면 연결을 반복하게 만드는 네트워크나 설정 문제부터 해결해야 합니다.

설치 업데이트와 복구 확인

설치 파일은 Android 다운로드에서 기기 아키텍처에 맞게 선택하세요. 아키텍처를 모른다면 기기 정보와 다운로드 페이지의 안내를 확인할 수 있습니다. 설치 실패 원인은 아키텍처 비호환, 시스템 요구사항 미충족, 저장 공간 부족, 기존 설치 파일의 출처 차이로 나눠 확인해야 합니다. 다른 설치 파일을 시도하려고 바로 앱을 삭제하지 말고 설정과 구독 정보를 먼저 저장하세요. v2rayNG와 v2flyNG를 바꾸는 것은 단순히 앱 화면만 교체하는 일이 아니므로 가져올 설정이 해당 코어 기능에 맞는지 확인해야 합니다.

최종 확인에서는 앱을 사용 중일 때의 브라우징, 화면 잠금 후 복귀, 네트워크 전환을 각각 테스트해 요청이 계속 클라이언트로 전달되고 라우팅도 예상대로 적용되는지 살펴보세요. 앱별 모드라면 프록시해야 하는 앱 하나와 우회해야 하는 앱 하나를 각각 확인합니다. 복구에 필요한 최소 설정을 기록하고 나머지 시스템 옵션은 그대로 보존하세요. 계속 지원을 요청해야 한다면 기기 운영체제, 클라이언트 이름, 네트워크 종류, 민감한 정보를 가린 오류 일부를 제공하세요. 기본 사용법은 사용 가이드에서, 개별 설정에 관한 질문은 자주 묻는 질문에서 확인할 수 있습니다.