V2Ray 문제 해결 가이드

인터넷 연결 불가: 트래픽이 멈춘 구간부터 확인

기본 네트워크를 복구한 뒤 프록시 입구 테스트

먼저 클라이언트를 종료하거나 프록시를 끄고, 운영체제 네트워크 설정에서 수동 프록시가 해제됐는지 확인하세요. 일반 웹사이트도 열리지 않으면 노드를 계속 바꾸기보다 무선 네트워크 인증, 게이트웨이, 시스템 시간, 네트워크 연결부터 점검하세요. 호텔·학교·공공 무선 네트워크는 브라우저에서 먼저 인증해야 할 수 있습니다. 프록시를 켜면 인증 페이지로 이동하지 못하는 경우도 있습니다. 기본 네트워크가 정상화된 후 클라이언트를 실행해 사용 가능한 것으로 확인된 설정을 선택하세요. 네트워크 접속 문제를 프록시 문제로 오인하지 않도록 하는 것이 중요합니다.

이어서 ‘화면에 실행 중으로 표시되는 상태’와 ‘코어가 실제로 포트를 열고 대기하는 상태’를 구분하세요. v2rayN 메인 화면의 로그에서 설정 로드, 인바운드 리스닝, 시작 실패 메시지를 확인합니다. 주소 충돌, 설정 파싱 실패 또는 코어 종료 메시지가 있으면 브라우저가 원격 서버에 연결을 시도하기도 전입니다. 설정의 기본 설정 또는 인바운드 설정에서 실제 로컬 리스닝 포트를 확인하세요. 메뉴 이름은 버전에 따라 다를 수 있으므로 현재 설정과 시작 로그를 기준으로 판단해야 합니다. 가이드의 포트 번호를 그대로 복사하거나 원격 서버 포트를 시스템 프록시에 입력하지 마세요.

명시적 프록시 요청으로 문제 구간 분리

아래 명령은 로컬에 HTTP 프록시가 제공되고 실제 포트가 10808이라고 가정합니다. Windows에서는 터미널 별칭으로 명령이 바뀌지 않도록 curl.exe를 사용하세요. 다른 데스크톱 운영체제에서는 curl을 사용할 수 있습니다. 테스트 주소는 요청 경로를 확인하기 위한 용도입니다. 로컬에서 SOCKS 인바운드만 활성화했다면 해당 SOCKS 옵션을 사용해야 합니다. SOCKS 포트에 HTTP 프록시 핸드셰이크를 보내면 프로토콜이 맞지 않아 테스트가 실패합니다.

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 25 -I https://example.com/

명시적 프록시 요청은 성공하지만 브라우저에서 실패한다면 시스템 프록시, 브라우저 확장 프로그램 또는 브라우저 자체 프록시 설정을 확인하세요. 명령을 실행하자마자 로컬 주소에 연결할 수 없다는 메시지가 나오면 리스닝 포트, 코어 프로세스, 보안 소프트웨어 규칙을 점검합니다. 로컬 연결은 성공한 뒤 시간 초과가 발생하면 노드, 라우팅, DNS를 확인하세요. 응답 상태 코드가 반드시 성공을 뜻할 필요는 없습니다. 접근 거부 응답도 요청이 목적지에 도달했음을 보여줄 수 있지만, 예상한 아웃바운드를 사용했는지는 로그로 확인해야 합니다.

전체 프록시 모드는 짧은 진단에만 사용

TUN을 잠시 끄고 시스템 프록시만 남긴 뒤, 클라이언트 라우팅을 전체 프록시로 바꾸어 같은 주소를 다시 테스트하세요. 이때 연결이 복구되면 노드 인증보다 분기 규칙 또는 직접 연결 경로에 문제가 있을 가능성이 큽니다. 전체 라우팅은 코어에 들어온 트래픽의 아웃바운드를 프록시로 통일할 뿐, 모든 프로세스의 트래픽을 자동으로 가로채지는 않습니다. 전체 모드로 바꾼 뒤에도 특정 앱이 연결되지 않는다고 해서 노드 자체를 사용할 수 없다고 단정하지 마세요. 테스트가 끝나면 트래픽 범위가 불필요하게 넓어지지 않도록 원래 모드로 되돌리세요.

특정 웹사이트 하나만 실패한다면 같은 브라우저에서 다른 사이트도 확인하고 인증서, 리디렉션, 로그인 상태와 관련된 오류인지 살펴보세요. 프록시 요청이 모두 실패하면 다른 노드 하나를 선택해 비교합니다. 처음부터 전송 프로토콜을 바꾸지 마세요. 프로토콜, 포트, 경로, 흐름 제어와 서버 설정은 함께 맞아야 합니다. 서버에 해당 인바운드가 없으면 클라이언트에서 프로토콜만 바꿔도 연결이 개선되지 않고 새로운 오류만 생길 수 있습니다.

노드 연결 시간 초과: 전송과 인증을 나눠 확인

테스트가 실제로 확인하는 항목부터 파악

노드 목록의 지연 시간 테스트가 항상 완전한 프록시 요청을 수행하는 것은 아닙니다. TCP 테스트는 보통 서버 포트에 연결할 수 있는지만 확인합니다. 실제 연결 테스트는 프록시 핸드셰이크를 거쳐 테스트 주소에 요청을 보냅니다. 따라서 TCP 연결은 되지만 실제 연결 테스트가 실패할 수 있습니다. 인증, TLS, 전송 경로 또는 테스트 대상에 문제가 있을 수 있습니다. 반대로 목록에 시간 초과가 표시돼도 모든 앱에 연결할 수 없다는 뜻은 아닙니다. 먼저 선택된 테스트 방식과 시간 초과 범위를 확인한 뒤 실제 웹 요청으로 검증하세요.

노드 하나만 선택해 테스트하고 같은 시간대의 로그를 확인하세요. 목록 전체를 연속해서 테스트하면 동시 연결이 많이 발생해 원격 서버의 속도 제한이나 연결 수 제한, 로컬 자원 경쟁을 유발할 수 있습니다. 그 결과 원래 오류가 묻힐 수 있습니다. 주소 확인, 연결 수립, TLS 핸드셰이크, 응답 수신 중 어느 단계에서 오류가 발생하는지 기록하세요. 로그에 단순히 시간 초과라고만 표시되면 먼저 입구와 테스트 대상을 하나씩으로 좁힌 뒤 로그 상세 수준을 잠시 높여 보세요. 원인을 찾은 후에는 일반 로그 수준으로 되돌리세요.

주소와 포트를 먼저 확인하고 핸드셰이크 설정 점검

서버 주소 앞뒤에 공백이 없는지, 포트를 잘못 입력하지 않았는지, 도메인이 정상적으로 해석되는지 확인하세요. 같은 서비스의 모든 노드에서 동시에 문제가 생기면 계정 상태, 서버 점검, 구독 만료가 원인일 수 있습니다. 노드 하나만 실패한다면 해당 노드의 설정이나 경로를 의심해 볼 수 있습니다. 다른 네트워크로 접속해 비교하면 로컬 네트워크 경로와 원격 문제를 구분하는 데 도움이 됩니다. 비교할 때는 노드와 다른 설정을 그대로 유지하세요. 여러 항목을 함께 바꾸면 어떤 변경이 영향을 줬는지 알 수 없습니다.

TLS 연결은 서버 이름, 인증서 일치 여부, 전송 방식, 시스템 시간을 확인하세요. 연결 주소와 인증서 검증에 사용하는 이름은 다를 수 있으므로 연결 주소가 특정 도메인이라고 해서 서버 이름을 임의로 덮어쓰면 안 됩니다. WebSocket 경로와 Host, gRPC 서비스 이름도 서버 설정과 일치해야 합니다. 단순한 메모 필드가 아닙니다. 서비스 제공자가 요청하지 않았다면 가져온 설정을 그대로 유지하고, 인터넷의 예시 경로나 요청 헤더를 기존 노드에 복사하지 마세요.

REALITY와 흐름 제어 설정을 함께 맞추기

VLESS와 REALITY를 함께 사용하는 경우 서버에서 제공한 공개 키 매개변수, 짧은 식별자, 서버 이름, 흐름 제어 설정도 확인해야 합니다. 화면마다 필드 이름이 다를 수 있으므로 클라이언트의 실제 안내를 따르세요. 클라이언트 공개 키 매개변수를 서버 개인 키로 입력해서는 안 됩니다. 흐름 제어 xtls-rprx-vision도 어디서나 사용할 수 있는 속도 향상 옵션이 아닙니다. 현재 코어와 서버 구성에서 지원되어야 합니다. 원리와 설정 항목의 관계는 REALITY와 XTLS Vision 해설을 참고하세요.

인증서 검증 허용을 일반적인 해결 방법으로 사용하지 마세요. 이 옵션은 신원 확인의 경계를 바꾸며, 포트 오류나 REALITY 매개변수 오류, 서버 오프라인 문제를 해결하지 못합니다. 시스템 시간, 서버 이름, 설정 출처를 바로잡고 필요한 경우 서비스 제공자에게 해당 연결 지점이 유효한지 확인하세요. 오래된 코어에서 지원하지 않는 필드 오류가 발생하면 다운로드 페이지에서 적합한 클라이언트를 선택한 뒤 실제 실행 중인 코어를 확인하세요. 그래픽 인터페이스만 업데이트됐다고 코어 기능까지 같아진 것은 아닙니다.

구독 오류: 가져오기·파싱·적용 단계 구분

기존 노드를 유지하고 구독 출처 확인

구독 업데이트는 구독 주소 요청, 응답 내용 파싱, 결과를 해당 그룹에 저장하는 세 단계로 이루어집니다. 업데이트에 실패해도 기존 노드를 바로 삭제하지 마세요. 기존 노드가 계속 작동할 수 있으며 네트워크 복구나 구독 요청의 프록시 경로로 활용할 수 있습니다. 먼저 구독 그룹 설정에서 업데이트 대상 그룹을 확인한 뒤 실패 로그를 살펴보세요. 그룹 이름이 비슷하면 만료된 주소와 현재 사용하는 주소를 혼동하기 쉽습니다.

서비스 제공자에게서 전체 구독 주소를 다시 받아 쿼리 매개변수가 잘리지 않았는지, 복사할 때 줄바꿈이나 불필요한 문장 부호가 섞이지 않았는지 확인하세요. 구독 주소에는 계정 인증 정보가 포함되는 경우가 많으므로 공개 온라인 변환 도구에 붙여 넣거나 공개 스크린샷에 노출하지 마세요. 브라우저에서 구독 주소를 열었을 때 클라이언트가 읽을 수 있는 구독 내용 대신 로그인 페이지, 만료 안내, 웹 오류가 표시된다면 요청은 사이트에 도달했지만 응답 내용이 유효한 노드 목록이 아닌 것입니다. 같은 업데이트를 반복해도 해결되지 않습니다.

상태와 응답 내용을 나눠 확인

요청 시간이 초과되면 네트워크 경로와 도메인 해석을 확인하세요. 인증되지 않음 또는 접근 금지 응답이 오면 구독 권한, 주소 재설정 여부, 계정 상태를 확인합니다. 요청이 너무 잦다는 응답을 받으면 버튼을 연속해서 누르지 말고 서버가 허용할 때까지 기다리세요. 성공 상태 코드가 반환돼도 내용이 올바르다는 뜻은 아닙니다. 일부 주소는 웹 인증 페이지, 로그인 양식, 점검 페이지를 반환해 클라이언트에서 파싱 오류가 발생합니다. 요청 결과와 응답 콘텐츠 유형을 함께 확인해야 합니다.

로그에 알 수 없는 형식이라고 표시되면 해당 구독이 현재 클라이언트에서 지원되는 형식인지 확인하세요. 일반 공유 링크 모음, 인코딩된 링크 내용, 다른 설정 체계는 서로 같은 형식이 아닙니다. 파일 확장자만 보고 호환성을 판단하지 말고, 이해하지 못한 필드를 직접 삭제한 뒤 원본 구독을 덮어쓰지도 마세요. v2rayN, v2rayNG 또는 v2flyNG용 주소를 제공자에게 요청하는 것이 좋습니다. 테스트 그룹 하나에만 가져와 먼저 확인한 뒤 원래 그룹을 교체할지 결정하세요.

업데이트 요청이 직접 연결인지 프록시 연결인지 확인

클라이언트에는 보통 프록시를 통해 업데이트하거나 프록시를 사용하지 않고 업데이트하는 옵션이 있습니다. 메뉴 위치는 버전에 따라 다를 수 있습니다. 구독 주소에 직접 연결할 수 없다면 사용 가능한 노드로 연결된 상태에서 프록시 업데이트를 시도하세요. 현재 노드가 작동하지 않고 구독 업데이트도 해당 노드에 의존한다면 복구 경로가 막히는 순환이 발생합니다. 이때는 직접 업데이트를 시도하거나 아직 사용할 수 있는 기존 노드를 이용하거나 다른 네트워크로 전환하세요. 실패한 노드에서 계속 재시도하지 마세요.

업데이트가 성공했는데도 노드가 보이지 않으면 그룹 필터, 검색 조건, 목록 정렬, 가져온 개수 안내를 확인하세요. 이름 필터를 사용 중이면 서버에서 받은 노드가 모두 제외됐을 수 있습니다. 업데이트 정책에 따라 기존 항목이 교체되어 현재 사용 중인 노드가 더 이상 유효하지 않을 수도 있습니다. 새 항목 하나를 선택해 활성 노드로 설정한 뒤 실제 연결 테스트를 실행하세요. 구독 업데이트 성공은 설정을 가져왔다는 뜻일 뿐, 모든 노드가 온라인이거나 시스템 프록시가 자동으로 켜졌다는 뜻은 아닙니다.

자동 업데이트만 실패한다면 작업 실행 당시 네트워크 상태, 활성 노드, 프록시 모드를 기록해 수동 업데이트 경로와 비교하세요. 컴퓨터를 켠 직후 네트워크가 아직 준비되지 않았거나, 절전에서 막 깨어났거나, 노드를 전환하는 중이면 일시적인 실패가 발생할 수 있습니다. 마지막 오류 한 줄만 남기지 말고 발생 시각을 기록해야 네트워크 이벤트와 겹치는지 확인할 수 있습니다. 관련 설정 방법은 구독 업데이트 오류와 자동 업데이트 간격을 참고하세요.

속도 저하: 핸드셰이크 지연과 전송 속도 구분

어느 단계에서 느린지 먼저 확인

‘속도가 느리다’는 현상은 크게 세 가지로 나뉩니다. 웹페이지를 처음 열 때 오래 기다리는 경우, 페이지 리소스가 하나씩 늦게 로드되는 경우, 다운로드가 계속 느린 경우입니다. 첫 대기 지연은 DNS, 연결 수립, TLS 핸드셰이크, 재시도와 관련되는 경우가 많습니다. 지속적인 다운로드 속도는 회선 혼잡, 서버 출구, 계정 제한, 로컬 대역폭의 영향을 더 많이 받습니다. 같은 사이트에 연속으로 두 번 요청한 뒤 대용량 파일 전송도 확인하세요. 특정 노드의 한 번 측정한 지연 시간만으로 전체 성능을 판단하지 마세요. 지연 시간이 짧아도 실제 처리량은 매우 낮을 수 있습니다.

테스트 전에 다른 다운로드, 클라우드 동기화, 시스템 업데이트를 일시 중지하고 무선 신호와 로컬 네트워크가 안정적인지 확인하세요. 클라이언트 하나와 트래픽을 가로채는 방식 하나만 사용해 여러 프록시 프로그램이 서로 연결을 전달하지 않도록 합니다. 노드, 테스트 대상, 시간 범위를 고정한 뒤 한 번에 변수 하나만 바꿔 비교하세요. 사이트마다 서버 위치, 캐시 사용 여부, 콘텐츠 크기가 다를 수 있으므로 서로 다른 사이트의 결과는 해당 경로에 대해서만 의미가 있습니다. 노드 전체의 순위를 나타내는 결과로 볼 수는 없습니다.

직접 연결·시스템 프록시·TUN 비교

기본 네트워크도 느리다면 먼저 로컬 네트워크를 점검하세요. 프록시를 사용할 때만 느리다면 노드와 원격 경로를 확인합니다. 시스템 프록시는 정상인데 TUN에서만 느리다면 트래픽 가로채기 범위, DNS 경로, 다른 가상 네트워크 어댑터, 앱의 프로토콜 차이를 살펴보세요. TUN은 더 많은 프로그램의 트래픽을 클라이언트에 전달하므로 백그라운드 업데이트와 동기화가 대역폭을 차지할 수 있습니다. TUN에서 전체 트래픽이 늘었다고 바로 코어 성능 저하로 단정하지 말고 테스트 중 네트워크를 사용하는 프로세스를 확인하세요.

웹페이지의 기본 문서는 빠르게 열리지만 이미지나 동영상이 멈춘다면 리소스 도메인별로 서로 다른 라우팅이 적용됐을 수 있습니다. 브라우저 개발자 도구의 네트워크 패널에서 어떤 도메인에서 대기하는지 확인하고 클라이언트 로그에서 해당 요청이 어느 아웃바운드를 사용하는지 살펴보세요. 특정 리소스 도메인이 잘못 직접 연결되면 페이지 전체가 느린 것처럼 보일 수 있습니다. 문제가 확인된 도메인 범위만 수정하세요. 사이트 하나 때문에 전체 라우팅 규칙을 삭제하면 다른 앱의 네트워크 동작까지 바뀝니다.

멀티플렉싱·UDP·MTU는 신중하게 조정

멀티플렉싱은 모든 프로토콜에서 속도를 높이는 만능 옵션이 아닙니다. 연결을 반복해서 설정하는 비용을 줄일 수 있지만 여러 요청이 하나의 하위 연결을 공유하면서 혼잡이나 장애의 영향을 함께 받을 수도 있습니다. 프로토콜, 흐름 제어, 코어의 실제 호환성에 따라 사용 여부를 결정하세요. 비교 테스트에서는 이 옵션만 바꾸고 같은 환경에서 관찰합니다. 동시 연결 수, 전송 방식, DNS를 한꺼번에 바꾸지 마세요. 서비스 제공자가 별도로 안내하지 않는다면 클라이언트와 노드 설정의 기본 동작을 유지하세요.

일부 앱은 UDP 기반 전송을 먼저 시도합니다. 현재 트래픽 가로채기 방식이나 원격 서버가 해당 경로를 지원하지 않으면 실패 후 다른 방식으로 전환될 때까지 앱이 기다려 처음에 멈춘 것처럼 보일 수 있습니다. 모든 UDP를 무작정 끄지 말고 로그와 앱 프로토콜을 확인하세요. 일부 사이트에서만 로딩이 멈추고 TUN이나 특정 네트워크에서만 발생할 때는 경로 MTU를 추가로 점검할 수 있습니다. 값을 바꾸기 전 원래 값을 기록하고 조금씩 테스트하세요. 온라인에서 본 고정값을 그대로 적용하면 새로운 호환성 문제가 생길 수 있습니다.

마지막으로 시간대와 네트워크를 바꿔 비교하세요. 같은 노드에서 여러 대상에 계속 느리다가 다른 노드로 바꾼 뒤 정상화되면 구체적인 시간대, 대상 유형, 테스트 조건을 서비스 제공자에게 전달하는 편이 효과적입니다. 같은 무선 네트워크에서 여러 노드가 모두 느리다면 네트워크와 기기를 먼저 점검하세요. 한 번의 테스트 결과를 쫓아 노드를 계속 바꾸지 마세요. 반복 가능한 비교를 해야 일시적인 변동과 지속적인 문제를 구분할 수 있고 불필요한 설정 변경도 줄일 수 있습니다.

DNS 문제: DNS 응답 주체와 조회 경로 확인

시스템·브라우저·코어의 DNS 해석 구분

한 기기에서도 시스템 리졸버, 브라우저의 보안 DNS, 클라이언트 코어 DNS, TUN의 DNS 가로채기가 동시에 사용될 수 있습니다. 브라우저에서 도메인을 해석할 수 있다고 해서 코어도 같은 결과를 사용한다는 뜻은 아닙니다. 시스템 명령의 조회가 실패해도 프록시 요청까지 반드시 실패하는 것은 아닙니다. 어떤 프로그램에서, 어떤 프록시 모드로, 어떤 도메인에 접속할 때 문제가 생기는지 먼저 확인한 뒤 해당 DNS 경로를 점검하세요. 모든 DNS 설정을 같은 주소로 바꾸면 경로별 차이만 가려질 수 있습니다.

로그에 표시되는 호스트를 찾을 수 없음, DNS 조회 시간 초과, 연결 대상 주소 연결 실패는 서로 다른 단계의 오류입니다. 앞의 두 경우는 우선 DNS 조회를 점검하세요. 마지막 오류는 주소를 이미 얻었지만 연결을 설정하지 못한 경우일 수도 있습니다. 먼저 시스템 도구로 도메인이 레코드를 반환하는지 확인한 뒤 프록시 요청으로 코어가 접속할 수 있는지 테스트하세요. Windows에서는 nslookup example.com을 사용할 수 있고, 다른 시스템에서는 설치된 DNS 조회 도구를 사용하세요. 시스템 조회 결과는 기준점일 뿐 브라우저나 코어가 실제로 같은 응답을 사용한다는 뜻은 아닙니다.

라우팅용 DNS 해석과 프록시 DNS 해석의 차이

라우팅의 domainStrategy는 도메인과 IP를 규칙 매칭에 어떻게 사용할지 정합니다. 전역 DNS 스위치와는 다릅니다. IPIfNonMatch를 사용하면 먼저 도메인 관련 규칙과 매칭을 시도하고, 일치하는 항목이 없을 때 필요에 따라 주소를 해석해 IP 규칙과 추가로 대조합니다. 모든 요청을 미리 해석하거나 최종 목적지가 특정 DNS 서비스를 사용하도록 보장하지는 않습니다. 로그에서 잘못된 아웃바운드로 요청이 전달됐다면 규칙 순서, 도메인 조건, 해석된 주소의 분류를 함께 확인하세요.

아래는 사용자 지정 설정을 위한 Xray DNS 객체 예시입니다. 완전한 클라이언트 설정이 아니며 클라이언트가 생성한 파일 전체를 덮어쓰면 안 됩니다. 필드의 역할을 설명하기 위해 조회 정책을 명시했지만 공개 DNS 서버에 연결할 수 있는지는 현재 네트워크에 따라 달라집니다. 그래픽 클라이언트를 사용한다면 DNS 설정에서 해당 옵션을 변경하고 생성된 설정이 예상대로인지 확인하세요. 클라이언트가 설정 파일을 다시 생성한다면 임시 파일을 직접 수정해도 변경 사항이 유지되지 않을 수 있습니다.

{
  "dns": {
    "servers": [
      "1.1.1.1"
    ],
    "queryStrategy": "UseIPv4"
  }
}

IPv6·캐시·암호화 DNS의 초기 조회 확인

일부 네트워크는 IPv6 주소를 반환하지만 기기에서 대상까지의 IPv6 경로가 작동하지 않아 간헐적인 대기가 발생할 수 있습니다. 비교를 위해 IPv4만 조회하도록 잠시 설정할 수 있지만 이는 원인을 찾기 위한 방법이지, 모든 네트워크에서 IPv6를 계속 꺼야 한다는 뜻은 아닙니다. DNS 조회 우선순위와 실제 아웃바운드 연결 정책은 서로 다른 계층입니다. 설정을 바꾼 뒤에도 실패하면 캐시에 이전 응답이 남아 있는지 확인하고 새 요청을 생성하세요. 기존 연결이 이전 주소를 계속 사용하는 상황을 피해야 합니다.

암호화 DNS는 초기 조회 과정도 고려해야 합니다. DNS 리졸버의 도메인 역시 먼저 해석해야 하기 때문입니다. 이 해석에 아직 연결되지 않은 프록시가 필요하고 프록시 서버 주소는 다시 해당 리졸버에 의존한다면 순환이 발생할 수 있습니다. 클라이언트가 별도의 초기 조회 설정을 지원하는지 확인하고 조회가 직접 연결인지 프록시 연결인지 점검하세요. 암호화 DNS 주소 하나를 모든 입력란에 넣지 마세요. 입력란에 따라 서버 주소, URL, 규칙, 정책 등 필요한 값이 다를 수 있습니다.

TUN에서 가상 주소 매핑을 사용하는 경우 시스템 도구에 표시되는 주소가 목적지 사이트의 실제 주소가 아니라 클라이언트가 관리하는 매핑 결과일 수 있습니다. 이런 환경에서는 클라이언트의 DNS 모드를 확인해야 합니다. 낯선 주소가 보인다고 DNS 변조로 단정하지 마세요. 반대로 앱이 매핑 주소를 캐시했는데 요청은 해당 TUN으로 전달되지 않으면 접속에 실패할 수 있습니다. 트래픽 가로채기 방식을 바꾼 뒤 테스트 앱을 완전히 종료하고 다시 열어 확인하세요. 필요하면 관련 캐시를 지우고 같은 도메인으로 비교합니다.

시스템 프록시가 적용되지 않을 때: 앱이 설정을 읽는지 확인

시스템 프록시가 모든 연결을 가로채는 것은 아닙니다

시스템 프록시는 앱이 읽어 사용하는 네트워크 설정이지 모든 패킷을 자동으로 리디렉션하는 규칙이 아닙니다. 브라우저는 시스템 설정을 따를 수 있지만 명령줄 도구는 환경 변수만 읽을 수 있고, 일부 앱은 별도의 프록시 설정을 사용합니다. 따라서 브라우저는 되는데 터미널에서는 실패하는 일이 드물지 않습니다. 명시적 프록시 명령으로 로컬 입구와 원격 경로가 작동하는지 먼저 확인한 뒤 앱 설정을 바꿀지, 사용 환경에 맞는 TUN을 사용할지 결정하세요. 앱 동작 문제를 코어 오류로 오인하지 않도록 주의해야 합니다.

v2rayN에서 시스템 프록시 상태를 ‘프록시 해제’나 ‘현재 설정 유지’가 아닌 상태로 설정했는지 확인한 다음 운영체제의 네트워크 프록시 설정도 점검하세요. Windows는 ‘설정 → 네트워크 및 인터넷 → 프록시’, macOS는 현재 네트워크 서비스의 프록시 옵션을 확인합니다. Linux 데스크톱 환경에서는 보통 네트워크 설정에 프록시 메뉴가 있습니다. 주소는 로컬 리스닝 주소와, 포트는 클라이언트의 실제 인바운드 포트와 일치해야 합니다. 네트워크 어댑터를 전환했다면 현재 사용하는 네트워크 서비스에 올바른 설정이 적용됐는지도 확인하세요.

설정 덮어쓰기와 우회 규칙을 하나씩 확인

브라우저 프록시 확장 프로그램, 자동 프록시 스크립트, 조직 정책, 앱 내장 프록시가 시스템 설정을 덮어쓸 수 있습니다. 테스트용 브라우저에서 관련 확장 프로그램을 잠시 끄고 별도의 프록시 모드가 설정되어 있는지 확인하세요. 자동 프록시 스크립트는 주소에 따라 직접 연결 또는 프록시 연결을 선택하므로 모든 트래픽을 로컬 포트로 보내는 것과 다릅니다. 특정 도메인만 우회한다면 클라이언트의 켜기 버튼을 계속 누르기보다 우회 목록과 스크립트 규칙을 점검하세요.

터미널에서는 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY 등의 환경 변수도 확인해야 합니다. 도구마다 지원하는 변수 이름과 우선순위가 다르며, 오래된 변수가 이미 종료된 포트를 가리킬 수 있습니다. 도구 동작을 모른 채 환경 변수를 일괄적으로 영구 설정하지 마세요. 먼저 명령 자체의 프록시 매개변수로 임시 테스트를 하고, 작동 여부를 확인한 뒤 도구 설명에 따라 설정하세요. 로컬 주소나 특정 도메인을 우회하는 규칙이 있는지도 확인해야 합니다.

아래 SOCKS 테스트도 실제 SOCKS 인바운드 포트가 10808이라고 가정합니다. 매개변수의 socks5h는 대상 도메인을 프록시 쪽에서 해석하도록 지정해 로컬 DNS 경로와 비교할 때 유용합니다. 그렇다고 시스템 DNS까지 해결된 것은 아닙니다. SOCKS 테스트는 성공하지만 일반 접속은 실패한다면 원격 노드를 계속 바꾸기보다 앱 프록시 설정이나 로컬 DNS 점검으로 돌아가세요.

curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 25 -I https://example.com/

다른 트래픽 가로채기에는 TUN이 적합할 수 있습니다

시스템 프록시를 읽지 않는 앱도 프록시 경로로 보내야 한다면 현재 플랫폼에서 TUN을 사용할 수 있는지 확인하세요. TUN은 가상 네트워크 인터페이스, 권한, 라우팅 설정에 의존하며 시스템 프록시와는 다른 기능입니다. 활성화한 뒤 인터페이스가 생성됐는지, 라우팅이 기록됐는지, DNS가 예상대로 처리되는지 확인한 다음 기존에 실패하던 앱을 테스트하세요. 시작 단계에서 권한 오류가 발생하면 노드를 바꿔도 트래픽 가로채기 문제는 해결되지 않습니다. 먼저 클라이언트 안내에 따라 권한을 부여하세요.

다른 VPN, 가상 네트워크 어댑터 도구, 별도의 TUN 프로그램을 동시에 실행하면 라우팅 충돌이 생길 수 있습니다. 진단할 때는 트래픽을 가로채는 프로그램 하나만 남기고, 종료한 뒤 기존 라우팅이 복구됐는지 확인하세요. 로컬에서 접속하기 위해 서버 포트를 모든 네트워크 인터페이스에 바인딩하지 마세요. 로컬 프록시는 보통 루프백 주소만 사용하면 됩니다. 리스닝 범위를 넓히면 네트워크 노출 범위가 달라집니다. LAN 공유가 꼭 필요하다면 이번 로컬 문제 해결과 분리해 접근 제어와 방화벽을 설정하세요.

클라이언트 충돌: UI·코어·시스템 환경 구분

어느 프로세스가 종료됐는지 먼저 확인

창은 그대로인데 연결되지 않는다면 코어 시작에 실패했을 수 있습니다. 창 전체가 사라졌다면 UI 프로세스 충돌 여부를 확인해야 합니다. 클라이언트 로그, 시스템 이벤트, 프로세스 상태를 확인하고 시작, 노드 전환, TUN 활성화, 구독 업데이트 중 어느 시점에 종료됐는지 기록하세요. UI가 정상이라고 코어도 정상인 것은 아니며, 코어가 정상이어도 시스템 프록시가 적용됐다는 뜻은 아닙니다. 프로그램 폴더 전체를 삭제하기보다 발생 단계를 구분하면 문제 해결에 필요한 단서를 보존하기 쉽습니다.

클라이언트를 정상 종료하고 백그라운드 프로세스가 남아 있지 않은지 확인한 뒤 사용자 설정과 구독 그룹 정보를 백업하세요. 백업에는 전체 구독 주소와 인증 매개변수가 포함될 수 있으므로 안전한 위치에 보관해야 합니다. 데이터 디렉터리 전체를 공개 업로드하거나 백업을 웹사이트 디렉터리에 두지 마세요. 재설치하려면 원본을 보관하고 새 설정 환경에서 테스트하세요. 기존 디렉터리에 그대로 덮어쓰면 새 파일과 이전 파일이 섞여 문제가 과거 설정 때문인지 확인하기 어려워질 수 있습니다.

플랫폼·아키텍처·쓰기 권한 확인

다운로드 페이지에서 패키지 종류를 다시 확인하세요. Windows용 v2rayN 데스크톱 버전과 클래식 WPF 버전은 실행 인터페이스가 다릅니다. macOS에서는 Apple Silicon과 Intel을 구분해야 하며, Linux에서는 프로세서 아키텍처와 배포판의 패키지 형식을 모두 확인해야 합니다. 아키텍처가 맞지 않거나 실행 환경이 없거나 설치가 불완전하면 시작할 수 없습니다. 필요한 종속성은 설치 프로그램과 시스템 오류 안내를 기준으로 판단하고, 오래된 가이드를 따라 출처가 불분명한 실행 구성 요소를 내려받지 마세요.

설정과 로그를 사용자 데이터 위치에 쓸 수 있어야 합니다. 프로그램이 접근이 제한된 디렉터리, 읽기 전용 미디어, 동기화 도구가 계속 잠그는 위치에 있으면 저장 실패, 설정 초기화, 시작 오류가 발생할 수 있습니다. 실행 파일이 있는 폴더만 확인하지 말고 클라이언트가 실제로 사용하는 데이터 디렉터리를 확인하세요. 모든 사용자에게 파일 전체 권한을 열어 주지 말고 해당 사용자 디렉터리의 접근 권한을 바로잡으세요. 관리자 권한이 필요한 작업과 일반 설정 저장 문제도 분리해 판단해야 합니다.

코어 시작 실패는 가장 먼저 발생한 오류부터 확인

주소가 이미 사용 중이라는 오류는 보통 인바운드 포트를 다른 프로세스가 사용 중이거나 이전 인스턴스가 종료되지 않았다는 뜻입니다. Windows에서는 시스템 리소스 모니터로 리스닝 프로세스를 확인하거나 아래 명령으로 예시 포트를 조회할 수 있습니다. 프로세스 정보를 확인할 때 권한도 고려하세요. 충돌 프로세스를 확인한 뒤 정상 종료하거나 클라이언트에서 사용하지 않는 포트로 바꾸고 시스템 프록시와 앱 설정도 함께 갱신하세요. 정체를 모르는 시스템 프로세스를 종료하지 말고, 코어 인바운드는 그대로 둔 채 시스템 프록시 포트만 바꾸지도 마세요.

netstat -ano | findstr :10808

설정 파싱 오류는 로그에서 가장 먼저 표시된 필드나 행부터 확인하세요. 뒤이어 발생하는 ‘연결 실패’는 앞선 오류의 연쇄 결과일 수 있습니다. JSON을 직접 편집했다면 여분의 쉼표와 따옴표, 필드 형식을 확인하세요. 자동 생성된 설정은 그래픽 설정에서 원인이 되는 값을 수정해야 합니다. GeoIP 또는 GeoSite 파일을 찾을 수 없다는 오류가 발생하면 경로와 파일 존재 여부, 클라이언트의 읽기 권한을 확인한 뒤 클라이언트의 업데이트 기능을 사용하세요. 다른 프로그램의 데이터베이스를 임의로 복사하면 태그나 형식 차이가 생길 수 있습니다.

사용자 지정 규칙을 바꾼 직후 문제가 발생했다면 테스트 설정에서 기본 라우팅으로 되돌리고 정상 작동이 확인된 노드 하나만 가져오세요. 최소 설정이 정상이라면 기존 옵션을 하나씩 복원합니다. 이렇게 하면 설정 문제와 설치 환경 문제를 구분하고, 이전 디렉터리 전체를 복원할 때 충돌이 다시 발생하는 상황도 피할 수 있습니다. 코어 호환성은 Xray-core와 V2Fly의 차이를 참고하세요. 두 코어가 모든 설정 항목을 똑같이 지원한다고 가정하지 마세요.

Android 점검: 권한·백그라운드·앱 범위 확인

VPN 아이콘은 트래픽 가로채기 기능이 시작됐다는 표시일 뿐

v2rayNG와 v2flyNG는 Android VPN 서비스를 사용해 기기 트래픽을 처리합니다. 처음 연결할 때 시스템 팝업에서 명시적으로 권한을 허용해야 합니다. 권한을 거부하면 노드를 가져왔더라도 트래픽을 가로채지 못합니다. 상태 표시줄에 VPN 아이콘이 나타난 뒤에도 클라이언트 로그와 실제 요청을 확인하세요. 이 아이콘은 시스템에서 해당 서비스가 만들어졌다는 뜻이지 원격 인증, DNS, 라우팅까지 모두 정상이라는 뜻은 아닙니다. 먼저 노드 하나를 선택해 테스트하고 복잡한 앱별 규칙은 잠시 사용하지 마세요.

Android에서는 일반적으로 같은 사용자나 프로필 공간에서 VPN 서비스를 하나만 활성화할 수 있습니다. 다른 프록시, VPN 인터페이스를 사용하는 방화벽, 트래픽 필터링 앱이 현재 연결을 대체할 수 있습니다. 다른 관련 서비스를 종료한 뒤 대상 클라이언트를 실행하세요. 시스템에서 상시 VPN 또는 VPN 미사용 시 연결 차단을 켰다면 현재 클라이언트를 대상으로 설정했는지도 확인해야 합니다. 설정이 다르면 클라이언트가 중지되거나 권한 부여에 실패했을 때 시스템 정책으로 네트워크가 차단될 수 있습니다.

화면이 켜져 있을 때는 정상이고 잠금 후 끊기면 백그라운드 제한부터 확인

화면을 잠근 뒤에만 연결이 끊긴다면 시스템 배터리 관리, 백그라운드 실행, 자동 시작 제한을 우선 확인하세요. 클라이언트가 필요한 백그라운드 동작을 계속할 수 있도록 허용하고 절전 모드가 포그라운드 서비스를 종료하지 않는지 확인합니다. 기기마다 메뉴 이름이 크게 다르므로 다른 제조사의 메뉴를 그대로 따라 하지 말고 앱 정보 화면의 배터리 또는 백그라운드 관리로 이동하세요. 설정을 바꾼 뒤 화면을 잠그고 기다렸다가 다시 켜서 서비스가 계속 실행 중인지, 알림이 유지되는지, 로그에 네트워크 재연결이 표시되는지 확인하세요.

백그라운드 제한과 원격 세션 시간 초과가 함께 발생할 수도 있습니다. 클라이언트 서비스는 계속 실행 중인데 화면을 켠 뒤 첫 요청만 느리다면 연결을 다시 설정하는 중일 수 있습니다. 서비스 자체가 종료됐다면 시스템의 프로세스 정리나 앱 종료에 가까운 문제입니다. 잠금 문제를 해결하려고 모든 연결 시간 초과를 무작정 늘리거나 연결 유지 수단으로 전체 목록의 속도를 반복 측정하지 마세요. 서비스 종료 또는 연결 재설정의 증거를 먼저 확인한 뒤 관련 설정만 조정해야 배터리 소모만 늘고 원인은 그대로인 상황을 피할 수 있습니다.

앱별 프록시와 네트워크 전환을 나눠 재검증

브라우저는 되는데 특정 앱만 작동하지 않는다면 앱별 프록시 목록을 확인하세요. 이 목록이 ‘선택한 앱만 프록시 사용’을 뜻하는지 ‘선택한 앱은 프록시 우회’를 뜻하는지 구분해야 합니다. 두 방식은 같은 앱을 선택해도 결과가 반대입니다. 설정을 바꾼 뒤 테스트 앱을 완전히 종료하고 다시 실행해 연결을 새로 맺도록 하세요. 업무 프로필, 복제 앱, 다른 사용자 공간은 별도의 네트워크 경계를 가질 수 있습니다. 기본 사용자 공간의 VPN이 같은 방식으로 적용되지 않을 수 있으므로 시스템 권한 범위를 기준으로 판단하세요.

무선 네트워크에서 모바일 네트워크로 전환한 뒤 문제가 발생하면 새 네트워크 자체가 정상인지 먼저 확인한 다음 클라이언트 연결을 중지하고 다시 시작하세요. 네트워크를 바꾸면 주소와 라우팅이 달라지고 기존 세션이 끊길 수 있습니다. 한 네트워크에서만 실패한다면 노드는 그대로 둔 채 해당 네트워크의 DNS, IPv6, UDP 경로를 점검하세요. 새 네트워크에서 노드 도메인의 해석 결과가 달라진다면 로그와 함께 확인해야 합니다. 모바일 네트워크 문제를 곧바로 클라이언트 버전 탓으로 돌리지 마세요.

프로토콜 요구 사항에 맞춰 클라이언트 선택

Android에서는 보통 먼저 v2rayNG를 사용합니다. V2Fly 코어 설정이 필요할 때 v2flyNG를 고려하세요. 이름만 바꿔 부른다고 두 앱이 완전히 같은 것은 아니며 구독에 포함된 프로토콜과 설정 항목을 해당 코어가 지원해야 합니다. 설치 패키지는 기기의 프로세서 아키텍처에 맞춰 선택하세요. 최신 기기는 대부분 arm64를 사용하며, 확실하지 않다면 기기 정보를 확인하거나 범용 패키지를 선택할 수 있습니다. 자세한 항목은 Android 다운로드 옵션을 확인하세요. 호환성 점검 대신 기존 앱을 반복해서 덮어 설치하지 마세요.

마지막으로 노드 하나, 브라우저 하나, 기본 라우팅, 안정적인 네트워크만 사용하는 최소 테스트 환경을 구성하세요. 이 상태에서 정상 작동하면 앱별 규칙, 사용자 지정 DNS, 기타 옵션을 차례로 복원하고 항목을 하나 복원할 때마다 다시 테스트합니다. 그래도 실패한다면 권한 상태, 네트워크 유형, 코어 오류, 재현 절차를 정리하고 스크린샷에서 구독 및 인증 정보를 삭제하세요. 가져오기와 연결 순서를 다시 확인하려면 빠른 시작 가이드를 참고하세요. 용어의 의미는 용어집에서 확인해 비슷한 이름의 다른 계층 설정을 잘못 변경하지 않도록 하세요.