V2Ray 문제 해결 가이드

01 / 영향 범위부터 확인

인터넷 연결 안 됨: 로컬 연결부터 확인

‘연결 성공’은 일반적으로 클라이언트가 트래픽 처리를 시작했다는 뜻일 뿐, 목적지 웹사이트에 접속할 수 있다는 의미는 아닙니다. 브라우저에서 페이지가 열리지 않으면 발생 시각, 사용 중인 노드, 프록시 모드, 영향을 받는 앱을 먼저 기록하세요. 그런 다음 모든 연결이 끊긴 것인지, 특정 웹사이트만 실패하는지 확인합니다. 이후 테스트 결과를 비교할 수 있도록 조건을 유지하세요. 노드와 네트워크를 동시에 바꾸면 일시적으로 연결이 복구되더라도 무엇이 효과를 냈는지 알기 어렵습니다.

기본 네트워크와 프록시 연결을 분리해 점검

먼저 클라이언트에서 시스템 프록시를 해제하고, 사용 중인 TUN 모드도 잠시 끈 다음 평소에 바로 접속되던 웹사이트를 열어 보세요. 그래도 접속할 수 없다면 Wi-Fi에서 웹 인증이 필요한지, 유선 케이블이 연결되어 있는지, 시스템 날짜가 정확한지, 다른 기기에서도 같은 네트워크를 사용할 수 있는지 확인합니다. 이 단계에서는 구독이나 라우팅 설정을 계속 바꾸지 마세요. 프록시를 거치기 전의 기본 연결부터 문제가 있으므로 네트워크를 복구한 뒤 클라이언트를 다시 시작해야 합니다.

기본 네트워크가 정상이라면 v2rayN을 열고 테스트할 구성을 선택해 활성 서버로 지정한 뒤, 하단 로그나 로그 창을 확인하세요. 눈에 띄는 오류를 찾는 것보다 시작 직후 설정 파싱 실패, 리스닝 주소 충돌, 코어 종료가 발생했는지 확인하는 것이 중요합니다. 화면이 열린다고 해서 코어까지 실행 중인 것은 아닙니다. 코어가 정상적으로 포트를 열지 못하면 브라우저가 로컬 포트로 요청을 보내더라도 다음 단계로 진행할 수 없습니다.

‘설정 → 매개변수 설정’에서 로컬 리스닝 포트를 확인하세요. 일부 화면에서는 관련 항목이 ‘Core 기본 설정’에 있으며, 이름은 인터페이스에 따라 다를 수 있습니다. 튜토리얼의 예시 값을 그대로 입력하지 말고 실제 설정된 값을 확인하세요. 여기에서 사용하는 10808은 예시일 뿐입니다. 클라이언트 설정이 다르면 테스트 명령의 포트도 같은 값으로 바꿔야 합니다. 시스템 프록시 포트, 브라우저 수동 프록시 포트, 클라이언트 리스닝 포트가 서로 일치해야 합니다.

프록시를 직접 지정해 테스트 범위 좁히기

아래 Windows 명령은 먼저 루프백 주소에서 프로그램이 포트를 열고 있는지 확인한 뒤, SOCKS 프록시를 명시해 요청을 보냅니다. 두 번째 명령은 해당 포트가 실제로 SOCKS 서비스를 제공할 때만 사용할 수 있습니다. 혼합 포트라면 SOCKS 프로토콜도 지원하는지 확인하세요. 테스트 주소는 예시 도메인입니다. 실제 재테스트에는 접속 가능한 것으로 확인된 HTTPS 주소를 사용하세요. 예시 웹사이트에 일시적으로 접속할 수 없다는 이유만으로 클라이언트 문제라고 판단하지 마세요.

Test-NetConnection -ComputerName 127.0.0.1 -Port 10808
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --head https://example.com/

포트 테스트에 실패하면 코어 실행 여부와 포트 충돌을 다시 확인하세요. 포트는 열려 있지만 요청에 실패한다면 같은 시각의 코어 로그를 확인하고 노드 연결과 도메인 확인을 점검합니다. 프록시를 명시한 요청은 성공하지만 브라우저에서 접속되지 않는다면 해당 프록시 경로는 작동하고 있는 것입니다. 클라이언트를 바로 재설치하기보다 브라우저 확장 프로그램, 시스템 프록시, 앱 자체 프록시 설정을 확인하세요.

전체 연결 문제와 특정 앱 문제 구분하기

특정 웹사이트 하나만 접속되지 않으면 같은 유형의 다른 사이트를 열어 보고 로그에서 어떤 아웃바운드가 선택되는지 확인하세요. 다른 사이트가 정상이라면 대상 사이트, 라우팅 규칙 적용, 인증서, 계정 상태가 원인일 수 있습니다. 브라우저의 HTTP 오류 페이지는 연결 시간 초과와 다릅니다. 명확한 응답 상태가 표시되면 요청이 어떤 서버에는 도달했을 가능성이 있으므로, 모든 페이지 오류를 노드 연결 끊김으로 단정하지 마세요.

특정 앱 하나만 작동하지 않으면 해당 앱이 시스템 프록시 설정을 사용하는지 확인하세요. 일부 프로그램은 자체 네트워크 설정을 사용하고 일부 트래픽은 UDP를 이용하므로, 브라우저에서 페이지가 열린다고 해서 모든 앱이 정상이어야 하는 것은 아닙니다. 먼저 앱 설정에서 프록시 프로토콜과 포트를 확인하세요. 더 많은 트래픽을 처리해야 한다면 TUN 모드의 권한과 라우팅 영향을 확인한 뒤 사용하세요. 여러 트래픽 처리 도구를 동시에 켜서 해결을 기대하지 마세요. 트래픽이 어디로 들어오는지 파악하기 어려워집니다.

02 / 연결이 수립되는 과정 확인

노드 시간 초과: 포트와 핸드셰이크 구분

시간 초과는 특정 단계가 제한 시간 안에 완료되지 않았다는 뜻이며, 노드 설정이 잘못되었다는 의미는 아닙니다. 클라이언트의 지연 시간 테스트, TCP 연결 수립, TLS 핸드셰이크, 실제 웹 요청은 대상과 테스트 방식이 다를 수 있어 결과를 서로 대신할 수 없습니다. 우선 원래 오류와 발생 시각을 기록한 다음 ‘로컬 리스닝 → 서버 주소 확인 → 서버 포트 → 프로토콜 핸드셰이크 → 목적지 접속’ 순서로 점검하세요.

클라이언트에서 실제로 사용 중인 설정 확인

v2rayN에서 활성 서버가 방금 테스트한 항목과 같은지 확인하세요. 이름이 같은 노드, 서로 다른 구독 그룹, 업데이트 후 다시 나타난 이전 설정에 특히 주의해야 합니다. 노드 이름은 구분을 위한 라벨일 뿐 실제 주소나 프로토콜을 나타내지 않습니다. 편집 창을 열어 서버 주소, 포트, 사용자 ID, 전송 방식, TLS 설정을 확인하고 설정 제공자가 안내한 원본 정보와 하나씩 비교하세요. 익숙해 보이는 값을 임의로 채워 넣지 마세요.

TLS를 사용하는 설정에서는 서버 주소와 핸드셰이크에 사용하는 서버 이름이 다를 수 있습니다. 후자는 보통 SNI 또는 serverName에 해당합니다. WebSocket을 사용한다면 경로와 Host도 확인하고, gRPC라면 서비스 이름을 확인하세요. 각 필드에는 정해진 용도가 있으므로 웹사이트 도메인으로 임의 교체하지 마세요. 구독에서 설정을 정상적으로 가져왔다면 원래 값을 유지하세요. 먼저 다른 항목이나 만료된 설정을 잘못 선택하지 않았는지 확인합니다.

시스템 시간도 핸드셰이크에 영향을 줍니다. 로그에 인증서가 아직 유효하지 않거나 만료되었거나 이름이 일치하지 않는다는 메시지가 있으면 기기의 날짜, 시간대, 자동 시간 설정을 먼저 확인한 다음 서버 이름을 점검하세요. 인증서 검증을 끄는 방법을 일반적인 해결책으로 사용하지 마세요. 주소 설정 오류나 중간 장비의 간섭을 숨길 수 있습니다. 기기 시간이 정상인데도 인증서 문제가 계속되면 서비스 운영자에게 인증서와 서버 설정을 확인해 달라고 요청하세요.

포트 접속 가능 여부와 프로토콜 작동 여부를 따로 확인

Windows에서는 아래 명령으로 원격 TCP 포트를 확인할 수 있습니다. 주소와 포트는 명령 형식을 설명하기 위한 예시이므로 설정에 지정된 실제 값으로 바꿔야 합니다. 테스트할 때 계정 식별 정보가 포함된 전체 링크를 공개하지 마세요. 연결에 성공했다는 것은 TCP 연결을 수립할 수 있다는 뜻일 뿐, 인증·TLS·전송 계층·프록시 아웃바운드까지 모두 정상이라는 의미는 아닙니다. 연결에 실패해도 클라이언트 화면 문제가 아니라 방화벽, 네트워크 경로, 서버 리스닝 문제일 수 있습니다.

Test-NetConnection -ComputerName example.com -Port 443

TCP 포트에 연결할 수 없다면 같은 기기에서 정상 작동이 확인된 다른 네트워크로 바꿔 다시 테스트하고, 다른 설정과도 비교하세요. 연결 시간 초과까지 기다려야 하므로 짧은 시간에 테스트를 반복해서 보내지 마세요. 특정 네트워크에서만 실패한다면 네트워크 차이를 단서로 기록하세요. 여러 네트워크에서 같은 서버 포트에 연결할 수 없다면 서비스 운영자에게 리스닝 포트, 인바운드 규칙, 인증서 갱신, 서비스 작동 상태를 확인해 달라고 요청해야 합니다.

비교 결과에 따라 수정할 위치 결정

포트에 연결되지만 핸드셰이크에 실패한다면 프로토콜과 전송 매개변수를 다시 확인하고, 사용 중인 코어가 해당 설정 조합을 지원하는지 점검하세요. V2Fly와 Xray는 모든 필드에서 기능이 완전히 동일하지 않습니다. 설정을 가져올 수 있다는 이유만으로 현재 코어에서 실행할 수 있다고 단정하지 마세요. 시작 로그에 알 수 없는 필드나 미지원 기능이 명시되어 있다면 오류가 사라질 때까지 필드를 지우는 대신, 설정에 맞는 호환 클라이언트를 선택하세요.

노드 테스트는 정상이지만 실제 요청에만 실패한다면 서버의 목적지 접속 기능과 클라이언트 라우팅을 확인하세요. 노드 테스트 성공은 테스트에서 확인한 경로만 정상이라는 뜻입니다. 해결 후에는 원래 요청을 다시 보내고 로그에서 예상한 아웃바운드가 선택되었는지 확인하세요. 단계별 점검 방법은 노드 시간 초과 점검 순서를 참고하세요. 어느 단계까지 성공했는지 기록하면 처음부터 다시 추측할 필요가 없습니다.

03 / 가져오기와 파싱 구분

구독 실패: 업데이트 경로부터 확인

구독 업데이트는 주소에서 콘텐츠 가져오기, 콘텐츠 형식 확인, 노드 목록에 기록하기의 세 단계 이상으로 이루어집니다. ‘업데이트 실패’는 어느 단계에서든 발생할 수 있으며, 이미 저장한 노드의 연결 가능 여부와 반드시 관련이 있는 것은 아닙니다. 기존 그룹을 유지하고 모든 노드를 처음부터 삭제하지 마세요. 업데이트할 때 ‘구독 업데이트(프록시 사용 안 함)’을 선택했는지, 프록시를 사용했는지 기록하고 로그에서 구독 관련 마지막 오류도 확인하세요.

전체 주소를 확인하되 접근 정보를 공개하지 않기

‘구독 그룹 설정’에서 해당 그룹을 열고 주소에 불필요한 공백, 줄 바꿈, 전각 문장 부호, 잘린 쿼리 매개변수가 없는지 확인하세요. 구독 주소에는 계정을 식별할 수 있는 정보가 포함되는 경우가 많습니다. 신뢰할 수 있는 출처에서 전체 주소를 복사해야 하며, 브라우저에 표시된 일부만 복사해서는 안 됩니다. 이 문서의 예시 https://example.com/sub은 사용할 수 있는 구독 주소가 아닙니다. 노드를 가져오려고 클라이언트에 입력하지 마세요.

기존 주소가 채팅 기록, 스크린샷, 공개 문서에 노출된 적이 있다면 제공자가 안내하는 방법으로 구독 접근 정보를 먼저 재설정한 뒤 새 주소를 사용하세요. 문제 해결에는 도메인 확인 여부, 응답 상태, 오류 요약만 기록하면 됩니다. 전체 링크를 다른 사람에게 전달할 필요가 없습니다. 임시로 도움을 요청하는 경우에도 쿼리 매개변수, 사용자 ID, 전체 구독 응답은 숨기세요. 노드 목록에 다른 연결 정보가 포함될 수 있으므로 이름만 가리는 것으로는 부족합니다.

계정이 유효한지, 구독 주소가 변경되었는지 확인하세요. 목록이 비어 있으면 현재 그룹에 사용할 수 있는 항목이 없거나 제공자가 해당 계정에 설정을 할당하지 않았을 수 있습니다. 이는 클라이언트가 데이터를 파싱하지 못하는 문제와는 다릅니다. 먼저 업데이트 로그에서 응답과 항목 수를 확인한 뒤 제공자에게 계정 상태를 문의하세요. 주소 경로를 추측하거나 접근 매개변수를 임의로 바꿔 다른 주소를 찾지 마세요.

직접 연결 업데이트와 프록시 업데이트를 따로 테스트

현재 노드가 작동하지 않고 구독 업데이트에도 해당 노드가 필요하면 ‘새 노드를 받아야 업데이트할 수 있지만, 새 노드를 받으려면 업데이트가 필요한’ 상황이 생길 수 있습니다. 현재 네트워크에서 구독 도메인에 직접 접속할 수 있다면 ‘구독 업데이트(프록시 사용 안 함)’을 먼저 사용하세요. 직접 연결이 불가능하지만 정상 작동이 확인된 다른 설정이 있다면 프록시를 통한 업데이트를 시도할 수 있습니다. 두 방법이 모두 실패했다면 결과를 각각 기록하세요. 단순히 ‘구독이 열리지 않음’이라고만 적지 마세요.

브라우저에서 구독 주소를 직접 열어 보면 인증 페이지나 안내 페이지가 표시되는지 확인하는 데 도움이 될 수 있지만, 이를 근거로 클라이언트에서도 업데이트할 수 있다고 판단하면 안 됩니다. 브라우저는 다른 프록시, 캐시, 로그인 상태를 사용할 수 있고 클라이언트가 받는 응답도 다를 수 있습니다. 로그인, 웹 인증, 네트워크 인증을 요구하는 페이지에서는 응답 상태가 정상처럼 보여도 내용은 클라이언트가 해석할 수 있는 구독 데이터가 아니라 HTML일 수 있습니다.

형식 호환성과 업데이트 이후 변경 사항 확인

일부 구독 서비스는 클라이언트 종류에 따라 다른 형식으로 응답합니다. 웹페이지에서 다운로드할 수 있다고 해서 해당 콘텐츠가 v2rayN, v2rayNG, v2flyNG에서 사용할 수 있는 것은 아닙니다. 로그에 콘텐츠를 가져왔지만 노드를 인식하지 못했다고 표시되면 제공자의 구독 옵션에서 클라이언트에 맞는 형식을 선택하세요. 아무 설정 파일이나 확장자만 바꾸거나 출처를 알 수 없는 변환 서비스에 전체 구독 정보를 전달하지 마세요. 연결 정보가 유출될 수 있습니다.

업데이트 후 노드 수가 달라졌다면 항목이 실제로 사라졌는지 판단하기 전에 현재 필터, 선택된 구독 그룹, 목록 정렬을 확인하세요. 이름이 같아도 주소는 업데이트되었을 수 있으며, 기존 항목이 교체된 것이 반드시 오류는 아닙니다. 직접 추가한 설정은 별도 그룹에서 관리하세요. 필요한 로컬 백업은 구독 업데이트 전에 보관하되, 공개 공유 폴더나 자동 업로드되는 스크린샷 폴더에 두지 마세요.

04 / 테스트 조건 유지

속도 저하: 지연 시간과 전송 속도 구분

웹페이지가 느리게 열리는 문제, 다운로드 속도 저하, 동영상 버퍼링은 서로 다른 성능 문제입니다. 웹페이지는 도메인 확인, 연결 수립, 핸드셰이크, 여러 리소스 요청을 거칩니다. 다운로드는 지속적인 전송 성능에 더 크게 좌우되고, 실시간 앱은 지터와 패킷 손실의 영향을 받습니다. 먼저 어떤 작업이 느린지 구체적으로 기록한 뒤 그에 맞는 비교 테스트를 선택하세요. 노드 목록의 지연 시간 숫자 하나만으로 모든 작업에서 더 빠른 노드를 판단할 수는 없습니다.

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

테스트할 때 같은 기기와 네트워크, 같은 대상, 비슷한 시간대를 유지하고 백그라운드 동기화, 시스템 업데이트, 다른 다운로드는 중지하세요. 먼저 직접 연결 속도도 저하되었는지 확인한 뒤 같은 요청으로 여러 노드를 비교합니다. 테스트 사이트와 노드를 동시에 바꾸면 대상 서버의 부하 차이가 결과에 섞입니다. 한 번의 속도 변화는 단서일 뿐입니다. 같은 조건에서 다시 테스트해 우연한 변동을 안정적인 결과로 오해하지 마세요.

v2rayN 테스트 기능을 사용할 때는 TCP 연결 테스트와 실제 요청 테스트를 구분해야 합니다. 전자는 주로 연결 수립 시간을 확인하고, 후자는 더 많은 네트워크 단계를 거칩니다. 결과가 비어 있거나 시간 초과가 발생해도 테스트 대상에 접속할 수 없어서일 수 있으며, 모든 대상에 실패한다는 뜻은 아닙니다. 테스트 유형과 대상을 기록하고 브라우저의 실제 접속 결과와 함께 판단하세요. 보기 좋은 숫자를 얻으려고 테스트 설정을 반복해서 바꾸면 결과를 비교하기 어렵습니다.

Wi-Fi 신호가 강하다고 연결이 안정적인 것은 아닙니다. 같은 컴퓨터로 공유기에 가까이 가서 다시 테스트하거나, 가능하다면 유선 네트워크와 비교하세요. 모바일 네트워크는 신호 변화, 핫스팟 공유, 요금제 속도 제한을 확인합니다. 집에서 여러 기기가 동시에 많은 데이터를 전송하면 외부 연결 대역폭이 혼잡해져 모든 노드에 영향을 줄 수 있습니다. 이 경우 클라이언트를 바꿔도 도움이 되지 않을 수 있으니 먼저 로컬 네트워크의 트래픽 경쟁을 확인한 뒤 프록시 경로도 계속 느린지 살펴보세요.

속도가 느려지는 단계 확인

페이지를 처음 열 때는 느리지만 새로 고침하면 크게 빨라지는 경우 DNS, 연결 재사용, 핸드셰이크 단계를 먼저 확인하세요. 다운로드가 처음에는 빠르다가 점점 느려진다면 서버 대역폭, 대상의 속도 제한, 네트워크 혼잡을 점검해야 합니다. 특정 웹사이트만 느리다면 비슷한 대상과 비교하고 라우팅 규칙이 적용되는지 확인해 요청이 부적절한 아웃바운드로 전달되지는 않는지 살펴보세요. 웹사이트 하나의 결과만으로 모든 트래픽을 같은 라우팅 방식으로 바꾸지 마세요.

로그에서 연결이 자주 다시 수립되는지, 도메인 확인 오류가 반복되는지 살펴볼 수 있습니다. 다만 문제 해결 중에도 매우 높은 로그 상세 수준을 계속 사용하지 마세요. 디스크 쓰기량이 늘고 더 많은 접속 기록이 보관될 수 있습니다. 문제가 발생하기 전후의 짧은 구간만 저장한 뒤, 원인을 찾으면 평소 로그 수준으로 되돌리세요. 로그를 공유해야 한다면 오류와 관련된 부분만 남기고 구독 주소, 사용자 ID, 공개할 필요가 없는 접속 대상은 삭제하세요.

UDP를 사용하는 앱은 프로토콜 조합, 클라이언트 설정, 서버가 해당 트래픽을 지원하는지 확인해야 합니다. 브라우저에서 웹페이지가 열린다고 해서 실시간 앱도 같은 경로를 사용한다는 뜻은 아닙니다. 일부 네트워크는 UDP를 다르게 처리하므로 앱 자체의 연결 상태를 기준으로 판단하세요. TUN 모드를 켜기 전에 트래픽을 처리하는 범위를 확인하세요. TUN은 대역폭을 높이는 스위치가 아닙니다. 트래픽이 들어오는 지점을 바꿀 뿐 외부 대역폭을 늘려 주지는 않습니다.

위험한 설정으로 성능 문제를 덮지 않기

일부 대형 페이지가 멈추거나 특정 연결만 오랫동안 대기한다면 경로 MTU를 후속 점검 항목으로 고려할 수 있지만, 처음부터 임의로 지나치게 낮은 값을 설정하지 마세요. 먼저 DNS, 프로토콜 호환성, 대상 서비스 문제를 확인하고 문제가 특정 네트워크나 터널 모드와 관련 있는지 확인한 뒤 클라이언트 안내에 따라 조금씩 조정하고 기존 값을 기록하세요. 설정을 바꿀 때마다 정상적으로 열리던 사이트와 원래 문제가 발생한 대상을 모두 다시 테스트해 한 곳을 고친 대신 다른 연결에 영향을 주지 않았는지 확인합니다.

전송 방식, 멀티플렉싱, 동시 연결 설정은 값이 클수록 좋은 것이 아닙니다. 서버 리소스가 부족하거나 연결이 불안정한 상황에서 동시 연결을 늘리면 경쟁이 심해질 수 있습니다. 호환되지 않는 멀티플렉싱 설정도 문제를 일으킬 수 있습니다. 우선 설정 제공자가 안내한 조합을 사용하고, 명확한 비교 조건이 있을 때만 항목을 하나씩 테스트하세요. 로컬 설정을 바꾸지 않아도 작동하는 다른 노드로 바꾸면 문제가 해결된다면 매개변수를 더 추가하기보다 노드 간 차이를 기록하는 편이 유용합니다.

05 / 도메인을 확인하는 주체 점검

DNS 문제: 도메인 확인 경로 추적

DNS는 도메인을 연결에 필요한 주소로 변환합니다. 프록시 환경에서는 운영체제, 브라우저, 클라이언트, 원격 서버가 모두 도메인 확인에 관여할 수 있습니다. ‘서버를 찾을 수 없음’이나 도메인 관련 시간 초과가 발생해도 모든 DNS 주소를 같은 공개 서비스 주소로 바로 바꾸지 마세요. 먼저 확인할 대상이 노드 서버의 도메인인지 접속하려는 웹사이트의 도메인인지 구분한 뒤, 어느 단계에서 요청이 발생하는지와 요청에 사용할 수 있는 네트워크 경로가 있는지 확인하세요.

노드 도메인과 대상 도메인 구분

클라이언트가 노드에 연결하기도 전에 서버 주소 확인에 실패했다고 표시한다면 문제는 프록시 진입점 이전 단계에서 발생한 것입니다. 아직 수립되지 않은 프록시를 통해 모든 도메인 확인 요청을 보내면 순환 의존이 생길 수 있습니다. 시스템 도구로 노드 도메인을 조회해 현재 네트워크의 DNS 서버에 접근할 수 있는지 확인하세요. 필요하면 설정 제공자가 안내한 적절한 경로를 사용하되, 노드 도메인을 임의로 조회한 주소로 바꾸지 마세요. 인증서와 라우팅도 도메인에 의존할 수 있습니다.

노드에는 연결되지만 일부 대상 도메인에만 접속할 수 없다면 클라이언트 로그의 도메인 확인 오류와 아웃바운드 선택을 확인하세요. 도메인 규칙으로 트래픽을 라우팅할 때 도메인이 유지되는지, 어느 단계에서 주소로 변환되는지가 규칙 적용에 영향을 줍니다. 브라우저에서 별도의 보안 DNS를 사용하면 시스템 조회 결과와 다를 수도 있습니다. 현재 설정을 기록한 다음 한 가지 설정만 임시로 바꿔 비교하세요. 브라우저, 시스템, 클라이언트의 DNS 설정을 동시에 변경하지 마세요.

아래 조회 명령은 Windows와 일반적인 데스크톱 환경에서 사용할 수 있습니다. 명령 결과는 현재 시스템의 도메인 확인 경로를 보여 주지만, 클라이언트 내장 DNS 확인기도 반드시 같은 결과를 얻는다는 뜻은 아닙니다. 조회에 성공하더라도 실제 HTTPS 요청을 테스트해야 합니다. 조회한 IP 주소를 직접 여는 것은 같은 테스트가 아닙니다. 많은 웹사이트가 인증서 확인, 가상 호스트 선택, 콘텐츠 전달에 도메인을 사용합니다.

# Windows PowerShell
Resolve-DnsName example.com

# nslookup을 사용할 수 있는 시스템
nslookup example.com

프록시 테스트로 도메인 확인 주체 파악

SOCKS 테스트에서 socks5h는 대상 도메인을 프록시 서버에서 확인하도록 합니다. 일부 도구에서 socks5를 사용하면 먼저 로컬에서 확인할 수 있습니다. 두 결과가 다르면 도메인 확인 경로를 더 살펴볼 필요가 있지만, 이 차이만으로 정확한 문제 위치를 판단할 수는 없습니다. 클라이언트의 DNS 설정, 라우팅 정책, 로그를 함께 확인해 원격 도메인 확인 요청이 어디로 전달되는지, 실수로 로컬로 되돌아오지는 않는지 점검하세요.

암호화 DNS를 사용할 때도 먼저 DNS 서버 자체에 접속할 수 있는지 확인해야 합니다. DNS 서버 주소가 도메인이라면 연결 전에 해당 도메인을 확인해야 할 수 있습니다. 서버 연결에 현재 문제가 발생한 경로가 필요하다면 시작 단계에서 계속 대기하는 문제가 생길 수 있습니다. 출처를 알 수 없는 설정을 통째로 복사하지 마세요. 어떤 도메인을 처리하는지, 어느 아웃바운드를 통해 접속하는지, 실패 시 어떻게 처리할지 먼저 확인한 뒤 현재 코어가 지원하는 형식으로 설정해야 합니다. 서로 다른 코어의 필드를 섞어 사용하지 마세요.

IPv4와 IPv6의 연결 가능성 차이도 접속이 간헐적으로 되거나 대기하는 원인이 될 수 있습니다. 도메인이 두 종류의 주소를 모두 반환하더라도 현재 네트워크는 한쪽만 정상적으로 연결될 수 있습니다. 먼저 로그에서 실제로 시도한 주소 유형을 비교한 뒤 클라이언트가 지원하는 범위에서 임시로 정책을 비교하세요. 한 번 실패했다는 이유로 기기 전체에서 IPv6를 영구적으로 끄지 마세요. 설정 변경이 문제와 실제 관련 있는지 확인하고 원래 설정으로 복원할 수 있도록 기록을 남기세요.

DNS와 라우팅 규칙 함께 확인

라우팅 문제는 간단한 규칙부터 확인할 수 있습니다. 아래는 Xray 형식의 라우팅 예시이며, 바로 실행할 수 있는 완전한 설정은 아닙니다. proxy와 direct는 현재 설정의 아웃바운드 태그와 일치해야 합니다. 도메인 규칙과 주소 규칙의 차이를 보여 주기 위한 예시이므로 클라이언트가 생성한 전체 설정을 그대로 덮어쓰지 마세요. GUI 클라이언트는 일반적으로 실행 설정을 다시 생성합니다. 설정을 유지하려면 ‘라우팅 설정’ 등 지원되는 메뉴를 사용하세요.

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

규칙은 대개 순서대로 적용됩니다. 앞쪽의 범위가 지나치게 넓은 규칙이 뒤의 세부 규칙보다 먼저 일치하면 해당 규칙은 적용되지 않을 수 있습니다. 로컬 네트워크 주소를 무조건 원격 프록시로 보내서도 안 됩니다. 로컬 관리 페이지와 사내 서비스에 영향을 줄 수 있습니다. DNS 문제를 해결한 뒤 같은 대상에 예상한 아웃바운드가 적용되는지 확인하세요. 도메인 확인으로 주소가 반환되었다는 것만으로 라우팅과 연결까지 완료된 것은 아닙니다. 검증을 위해 실제 요청 로그를 남기는 것이 좋습니다.

마지막으로 캐시 삭제를 고려하세요. Windows의 ipconfig /flushdns는 시스템 DNS 캐시만 지우며 브라우저 자체 캐시, 클라이언트 캐시, 원격 캐시까지 자동으로 지우지는 않습니다. 먼저 오류의 원인을 수정한 다음 관련 앱을 종료하고 다시 열어 테스트하세요. 캐시를 지울 때만 잠시 복구된다면 반복해서 캐시를 비우기보다 도메인 확인 정책과 네트워크 전환을 계속 점검해야 합니다.

06 / 앱 트래픽이 들어오는 경로 확인

시스템 프록시가 작동하지 않음: 적용 범위 확인

시스템 프록시는 운영체제가 앱에 제공하는 프록시 설정이며, 모든 네트워크 트래픽을 강제로 처리하지는 않습니다. v2rayN에서 ‘시스템 프록시 자동 설정’을 선택하면 일반적으로 해당 설정을 읽는 앱만 프록시를 사용합니다. 앱 자체 프록시 설정, 브라우저 확장 프로그램, 명령줄 환경 변수, TUN 모드가 별도의 트래픽 경로를 만들 수도 있습니다. 문제를 확인할 때는 먼저 대상 앱이 어떤 설정을 사용하는지 파악한 뒤 해당 위치를 점검하세요.

시스템 프록시 주소와 로컬 리스닝 확인

Windows에서는 먼저 v2rayN의 ‘시스템 프록시’ 메뉴에서 ‘시스템 프록시 자동 설정’을 선택한 다음, 시스템 ‘설정 → 네트워크 및 인터넷 → 프록시’에서 실제 적용된 주소와 포트를 확인하세요. 구체적인 항목은 수동 프록시나 설정 스크립트로 표시될 수 있으므로 클라이언트의 현재 작동 방식에 맞춰 확인해야 합니다. 트레이 아이콘 색상만 보고 판단하지 마세요. 다른 프로그램이 시스템 설정을 덮어쓰면 클라이언트 화면에 모든 변경 사항이 바로 반영되지 않을 수 있습니다.

주소가 로컬 루프백이면 클라이언트에서 실제로 리스닝 중인 포트와 일치해야 합니다. 127.0.0.1은 현재 기기를 의미하므로 로컬 앱이 같은 기기의 클라이언트에 연결할 때 사용할 수 있습니다. 휴대폰에서 컴퓨터 프록시에 접속하는 주소로는 사용할 수 없습니다. 포트를 바꾼 적이 있다면 시스템이나 브라우저에 이전 값이 남아 있을 수 있습니다. 먼저 프록시를 명시한 요청으로 새 포트가 작동하는지 확인한 다음 시스템 프록시 설정을 다시 적용하세요. 리스닝하지 않는 주소에서 모드만 반복해서 바꾸지 마세요.

macOS에서는 ‘시스템 설정 → 네트워크’에서 현재 네트워크 서비스를 선택하고 ‘세부사항 → 프록시’에서 설정을 확인할 수 있습니다. 시스템 버전에 따라 메뉴 이름은 조금씩 다를 수 있습니다. Wi-Fi와 유선 연결이 서로 다른 네트워크 서비스로 표시될 수 있으므로 네트워크를 전환한 뒤 현재 선택된 항목을 확인하세요. Linux 데스크톱은 시스템 프록시 설정 위치와 앱의 적용 방식이 환경마다 다릅니다. 일부 앱은 자체 설정만 사용하므로 다른 데스크톱 환경의 절차를 그대로 적용하지 마세요.

여러 프록시 설정의 충돌 방지

브라우저와 다른 앱의 동작이 다르다면 브라우저 프록시 확장 프로그램을 잠시 끄고 시작 매개변수나 관리 정책이 적용되어 있는지 확인하세요. 명령줄 도구는 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY 등의 환경 변수를 사용할 수 있습니다. 환경 변수를 바꿔도 이미 실행 중인 프로세스에는 이전 값이 남아 있을 수 있으므로 터미널이나 앱을 다시 열어야 합니다. 시스템 프록시를 바꿔도 해당 변수가 자동으로 변경되지는 않습니다.

시스템 프록시나 기본 라우트를 바꾸는 도구를 여러 개 동시에 실행하지 마세요. 도구가 서로 주소를 덮어쓸 수 있고, 직접 연결해야 하는 프록시 아웃바운드가 다시 다른 터널로 들어가 순환 경로가 생길 수도 있습니다. 다른 트래픽 처리 프로그램을 종료하고 하나의 클라이언트와 명확한 진입 경로만 유지한 상태에서 원래 앱을 테스트하세요. 여러 도구를 함께 사용해야 한다면 각 단계의 리스닝 주소와 트래픽 흐름을 먼저 파악하세요. 기본 설정이 자동으로 연결해 줄 것이라고 기대하지 마세요.

‘시스템 프록시를 변경하지 않음’은 ‘시스템 프록시 삭제’와 다릅니다. 전자는 보통 시스템의 현재 상태를 유지하고, 후자는 클라이언트가 설정한 프록시 경로를 직접 제거합니다. 따라서 창 닫기, 트레이에서 종료, 프록시 해제는 서로 대신할 수 없습니다. 클라이언트를 종료한 뒤 인터넷에 연결할 수 없다면 시스템 프록시가 여전히 로컬 포트를 가리키는지 확인하세요. 설정을 정상적으로 복구한 뒤 다시 테스트하고, 기본 네트워크 연결을 유지하려고 작동하지 않는 노드를 다시 시작하지 마세요.

LAN 공유와 TUN을 분리해 점검

휴대폰에서 컴퓨터의 프록시를 사용하려면 컴퓨터의 ‘매개변수 설정’에서 ‘LAN 연결 허용’을 켜고 리스닝 포트와 컴퓨터의 로컬 네트워크 주소를 확인한 뒤 필요한 방화벽 인바운드 규칙을 설정하세요. 방화벽 규칙은 신뢰할 수 있는 네트워크와 필요한 포트로 제한해야 합니다. 문제를 해결한다며 방화벽 보호 기능 전체를 끄지 마세요. 휴대폰과 컴퓨터가 LAN에서 서로 통신할 수 있어야 합니다. 게스트 네트워크 격리나 핫스팟 제한이 연결을 막을 수도 있습니다.

TUN 모드에 문제가 있다면 가상 인터페이스, 권한, 라우팅이 정상적으로 설정되었는지 확인하세요. TUN을 켠 뒤 노드 서버 자체에도 접속할 수 없다면 외부 연결이 다시 TUN으로 들어가는 순환이 발생했는지 점검해야 합니다. 우선 TUN을 끄고 프록시 주소를 명시해 노드가 작동하는지 확인한 뒤 TUN만 켜서 비교하세요. LAN 공유 방법은 LAN 연결 허용 설정을 참고하세요. 재테스트할 때 대상 앱뿐 아니라 로컬 네트워크 서비스에도 계속 접속할 수 있는지 확인합니다.

07 / 인터페이스와 코어 프로세스 구분

클라이언트 충돌: 현재 상태를 보존한 뒤 복구

클라이언트가 열리지 않는 문제, 창이 바로 닫히는 문제, 노드 코어가 종료되는 문제는 각각 나눠서 확인해야 합니다. 앞의 두 문제는 주로 GUI에 영향을 주지만, 코어가 종료되면 화면은 남아 있어도 모든 요청이 실패할 수 있습니다. 운영체제, CPU 아키텍처, 다운로드한 패키지 종류, 오류가 발생한 시점이 실행·가져오기·연결 중 언제였는지 기록하세요. 사용자 디렉터리 전체를 바로 삭제하지 마세요. 구독 그룹, 라우팅 규칙, 문제 로그가 들어 있을 수 있어 원인을 파악하기 더 어려워집니다.

설치 파일과 시스템 환경 확인

먼저 클라이언트 다운로드 페이지에서 운영체제와 아키텍처를 확인하세요. Windows용 v2rayN 데스크톱 버전과 클래식 WPF 버전은 서로 다른 인터페이스 구현입니다. 선택한 패키지 안내에 따라 필요한 런타임과 시스템 호환성을 확인해야 합니다. macOS는 Apple Silicon과 Intel을 구분하고, Linux는 CPU 아키텍처와 배포판의 패키지 형식도 확인하세요. 다운로드가 완료되었다고 해서 기기에 맞는 패키지라는 뜻은 아닙니다. 아키텍처가 잘못되면 실행 단계에서 종료될 수 있습니다.

Windows에서 런타임이 없다는 메시지가 명확하게 표시되면 오류에서 지정한 구성 요소와 아키텍처에 맞게 처리하세요. 출처를 알 수 없는 개별 DLL 파일을 다운로드하지 마세요. 포터블 버전은 폴더 전체를 압축 해제한 뒤 실행해야 하며, 메인 프로그램만 압축 파일 밖으로 꺼내 실행하면 안 됩니다. 경로 권한, 임시 폴더 정리, 보안 프로그램의 파일 격리도 실행 실패를 일으킬 수 있으니 시스템 안내를 따라 하나씩 확인하세요. 모든 오류를 운영체제 버전 문제로 단정하지 마세요.

macOS에서 개발자를 확인할 수 없다는 메시지가 나타나면 먼저 파일 출처와 다운로드한 패키지 종류를 확인한 뒤 ‘시스템 설정 → 개인정보 보호 및 보안’에 표시되는 안내에 따라 처리하세요. 앱 하나를 열기 위해 시스템 보안 기능 전체를 끄지 마세요. 파일 손상, 구성 요소 누락, 아키텍처 불일치도 모두 권한 문제라고 단정해서는 안 됩니다. macOS 첫 실행 및 권한 안내를 참고해 보안 차단 메시지와 실제 프로그램 오류를 구분하세요.

계속 재시작하지 말고 로그 확인

인터페이스가 열리면 클라이언트 로그와 코어 로그가 각각 있는지 먼저 확인하세요. 설정을 가져온 직후 오류가 발생했다면 처음 나타난 파싱 실패나 미지원 필드 메시지를 우선 확인해야 합니다. 뒤이어 대량으로 발생하는 연결 실패는 그 오류 때문에 생겼을 수 있습니다. 연결을 누를 때마다 포트 충돌 메시지가 표시되면 포트를 계속 바꾸기보다 다른 인스턴스가 실행 중인지 확인하세요. 포트를 반복해서 변경하면 시스템 프록시와 리스닝 설정이 더 어긋날 수 있습니다.

Windows에서는 아래 명령으로 예시 포트의 리스닝 프로세스 ID를 확인할 수 있습니다. 번호를 확인한 뒤 작업 관리자에서 어떤 프로그램인지 알아보세요. 익숙하지 않은 번호라는 이유만으로 시스템 프로세스를 종료하지 마세요. 클라이언트가 중복 실행된 경우 불필요한 인스턴스를 트레이에서 정상 종료한 다음 하나만 다시 시작하세요. 해당 포트를 다른 서비스에서 사용해야 한다면 클라이언트에 비어 있는 포트를 지정하고, 그 포트를 참조하는 모든 앱 설정도 함께 수정해야 합니다.

Get-NetTCPConnection -State Listen -LocalPort 10808 |
  Select-Object LocalAddress, LocalPort, OwningProcess

Linux GUI 프로그램이 시작 직후 종료되면 터미널에서 설치된 프로그램을 실행해 누락된 의존성, 디스플레이 환경, 권한 관련 오류를 확인할 수 있습니다. 패키지 설치 과정에 오류가 있었다면 앱을 테스트하기 전에 먼저 해결하세요. 실행 파일 하나만 수동으로 복사해도 의존성이 모두 갖춰지는 것은 아닙니다. 일반 권한으로 실행할 수 있다면 편의를 위해 관리자 권한으로 계속 실행하지 마세요. 필요한 네트워크 트래픽 처리 기능의 권한만 별도로 설정하세요.

최소 설정으로 문제 범위 좁히기

사용자 설정이 손상되었을 가능성이 있다면 프로그램을 종료한 뒤 클라이언트가 지원하는 방법으로 설정 폴더를 백업하고 원본 파일은 그대로 보관하세요. 새 설정 환경이 필요하다면 새 사용자 데이터 폴더를 사용하거나 안내에 따라 초기화하세요. 설치 경로만 바꾸면 설정도 분리될 것이라고 가정하지 마세요. 먼저 빈 환경에서 인터페이스가 열리는지 확인한 뒤 정상 작동이 확인된 설정 하나만 추가합니다. 라우팅 전체, 구독, 사용자 지정 매개변수는 아직 가져오지 마세요.

최소 환경에서 정상 작동한다면 구독, 라우팅, 특수 네트워크 기능 순으로 하나씩 복원하고 매번 다시 테스트하세요. 특정 항목을 복원한 뒤 문제가 재현되면 모든 설정을 버리지 않고도 원인 범위를 좁힐 수 있습니다. 두 인터페이스 버전의 동작이 다르다면 데스크톱 버전과 WPF 버전의 차이를 참고해 시스템에 맞는 버전을 선택하세요. 인터페이스를 바꾸는 것을 노드나 DNS 문제의 일반적인 해결책으로 생각하지 마세요.

08 / Android 네트워크 및 백그라운드 제한

모바일 문제: 권한과 네트워크 전환

Android에서는 v2rayNG를 우선 권장하며 V2Fly 코어 호환 경로가 필요한 경우 v2flyNG를 고려할 수 있습니다. 두 앱의 화면 조작은 비슷하지만 지원하는 코어와 일부 설정이 완전히 같다고 볼 수는 없습니다. 휴대폰이 연결된 것으로 표시되는데도 접속이 되지 않거나, 화면을 잠그면 연결이 끊기거나, 네트워크를 전환한 뒤 작동하지 않는다면 VPN 권한, 앱별 라우팅, 백그라운드 실행 상태부터 확인하세요. 이후 노드와 DNS를 점검해 모바일 운영체제의 제한을 서버 문제로 오해하지 않도록 합니다.

VPN 서비스가 실제로 시작되었는지 확인

처음 연결을 시작하면 시스템에서 VPN 연결 권한을 요청합니다. 권한을 허용한 뒤에야 클라이언트가 해당 로컬 가상 네트워크 인터페이스를 만들 수 있습니다. 상태 표시줄에 VPN 아이콘이 보이더라도 서비스가 실행되었다는 뜻일 뿐 원격 노드에 연결되었다는 의미는 아닙니다. 시작 직후 앱 로그를 확인해 설정 파싱 실패, 권한 거부, 서비스 즉시 종료가 없는지 살펴본 다음 접속이 확인된 대상으로 실제 요청을 테스트하세요.

일반적으로 같은 사용자 환경에서는 여러 앱이 VPN 서비스를 동시에 사용할 수 없습니다. 다른 네트워크 도구, 업무 환경 정책, 시스템 서비스가 이미 연결을 사용 중이면 새 연결이 기존 서비스를 대체하거나 설정에 실패할 수 있습니다. 먼저 다른 트래픽 처리 앱을 종료하고 클라이언트 하나만 실행하세요. 조직에서 관리하는 기기라면 관리 정책이 VPN 설정을 제한하는지도 확인해야 합니다. 기기 자체의 권한 요구를 우회하려고 여러 클라이언트를 번갈아 설치하지 마세요.

‘항상 켜기 VPN’ 또는 ‘VPN을 사용하지 않는 연결 차단’이 설정되어 있으면 클라이언트가 실행되지 않았거나 연결에 실패할 때 시스템 정책에 따라 다른 네트워크도 차단될 수 있습니다. 문제를 해결하기 전에 이 옵션의 상태를 기록하세요. 필요한 경우 기본 네트워크를 비교할 때만 잠시 끄고, 점검이 끝나면 필요에 따라 다시 켜세요. 앱 안에서 연결을 중지했더라도 시스템이 중지된 서비스를 통해 모든 트래픽을 보내도록 설정되어 있지 않은지 확인해야 합니다.

앱별 프록시와 백그라운드 실행 확인

일부 앱만 문제가 생긴다면 클라이언트에서 앱별 프록시나 제외 목록을 사용 중인지 확인하고 현재 모드가 ‘선택한 앱만 프록시 사용’인지 ‘선택한 앱 우회’인지 살펴보세요. 같은 앱 목록이라도 모드에 따라 의미가 반대입니다. 설정을 바꾼 뒤 연결을 다시 수립하고 대상 앱을 완전히 종료했다가 다시 열어 이전 경로를 계속 사용하지 않도록 하세요. 업무용 프로필과 개인 프로필이 분리되어 있다면 테스트하는 앱이 어느 환경에 속하는지도 확인해야 합니다.

화면을 잠그면 연결이 끊기고 화면을 켰을 때 복구된다면 시스템 배터리 최적화, 백그라운드 데이터, 제조사의 자동 시작 관리가 원인일 수 있습니다. 시스템 앱 정보에서 배터리 정책과 백그라운드 네트워크 권한을 확인하고 지속적인 연결에 필요한 권한을 허용하세요. 기기 전체의 절전 기능을 끌 필요는 없습니다. 연결이 끊길 때 VPN 아이콘이 사라지는지, 앱 서비스가 다시 시작되는지, 로그에 재시작 기록이 있는지 관찰해 프로세스가 종료된 문제와 원격 연결 시간 초과를 구분하세요.

포그라운드 서비스 알림은 실행 상태를 파악하는 데 도움이 되며 일부 시스템은 알림 표시를 별도로 관리합니다. 알림이 사라져도 코어가 중지되었다고 단정할 수는 없으므로 시스템 VPN 상태와 로그를 함께 확인하세요. 반대로 알림이 남아 있어도 원격 연결이 정상이라는 보장은 없습니다. 백그라운드 권한을 복구한 뒤에도 같은 조건에서 연결이 끊긴다면 화면 잠금 시간, 전원 상태, 네트워크 유형을 기록해 하나씩 비교하세요. 여러 시스템 옵션을 한 번에 바꾸지 마세요.

네트워크 전환 후 도메인 확인과 아웃바운드 재검증

Wi-Fi에서 모바일 데이터로 전환하면 기존 연결이 끊기고 DNS, IPv6, 기본 라우트가 바뀔 수 있습니다. 먼저 네트워크가 정상적으로 연결될 때까지 기다린 다음 클라이언트 연결을 끊었다가 다시 연결하고 새로운 요청을 테스트하세요. 특정 Wi-Fi에서만 실패한다면 웹 인증이 필요한지, 기기 격리가 설정되어 있는지 확인하세요. 모바일 데이터에서만 실패한다면 모든 앱 데이터를 초기화하기보다 노드 포트 연결 여부와 도메인 확인 결과를 비교해야 합니다.

휴대폰에서 컴퓨터가 공유하는 프록시를 사용하려면 Wi-Fi 프록시 설정에 컴퓨터의 로컬 네트워크 주소와 실제 HTTP 또는 혼합 포트를 입력하세요. 휴대폰의 루프백 주소를 입력하거나 SOCKS만 제공하는 포트를 HTTP 포트로 사용하면 안 됩니다. 이 설정은 보통 Wi-Fi 프록시를 따르는 앱에만 적용됩니다. 테스트 전에 컴퓨터가 켜져 있고 클라이언트가 포트를 열고 있는지 확인한 다음 시스템 프록시 항목에 따라 LAN 연결과 방화벽을 점검하세요.

설정을 가져오는 데 성공했지만 시작 중 오류가 발생한다면 해당 설정에 필요한 코어 기능을 확인하세요. v2rayNG와 v2flyNG가 지원하는 설정 형식과 기능 조합은 서로 다를 수 있습니다. 노드 이름을 바꿔 호환성을 판단하지 마세요. 재설치가 필요하다면 Android 다운로드 페이지에서 CPU 아키텍처에 맞는 패키지를 선택하세요. 비교적 최신 기기는 대부분 arm64에 적합합니다. 확실하지 않다면 파일 크기로 추측하지 말고 범용 패키지 안내를 참고하세요.