V2Ray 문제 해결

인터넷 연결 안 됨: 요청 경로부터 점검

클라이언트가 실행 중이어도 앱의 요청이 프록시를 거친다는 뜻은 아닙니다. 일반적인 연결은 앱, 로컬 리스너, 코어 라우팅, 원격 연결, 대상 서비스 순으로 이어집니다. 앞 단계에서 요청이 전달되지 않으면 이후 설정이 올바르더라도 요청이 도착하지 않습니다. 모든 앱에서 연결이 안 되는지, 브라우저만 안 되는지, 일부 사이트만 열리지 않는지 먼저 기록하세요. 연결 전후의 변화도 적어 두면 기존 네트워크 문제를 클라이언트 탓으로 오인하지 않을 수 있습니다.

직접 연결과 프록시 연결 비교하기

먼저 클라이언트에서 시스템 프록시를 해제하거나 Android 연결을 중지한 다음, 평소 직접 접속되는 페이지를 열어 보세요. 직접 연결도 실패한다면 Wi-Fi 인증, 라우터 연결, 시스템 시간 또는 네트워크 자체부터 확인해야 합니다. 이미 열려 있는 탭만 확인하지 마세요. 캐시된 페이지일 수 있습니다. 새 페이지를 열어 새로고침하고 실제 네트워크 요청이 발생하는지 확인한 뒤, 클라이언트를 켜 같은 방식으로 다시 접속하세요.

데스크톱에서는 v2rayN으로 점검하는 것이 좋습니다. 설정에서 실제 로컬 리스닝 주소, 포트, 프로토콜을 확인하고 시스템 프록시에 설정된 주소와 비교하세요. 이 사이트의 예시인 10808, 10809는 모든 버전에서 공통으로 사용하는 값이 아닙니다. 일부 화면은 혼합 리스너를 사용하고, 일부 설정은 SOCKS와 HTTP 포트를 따로 제공합니다. 현재 클라이언트 설정과 시작 로그를 기준으로 확인하고 오래된 화면을 보고 시스템을 변경하지 마세요.

그다음 클라이언트 로그를 열고 이전 내용을 지우거나 현재 시간을 기록한 뒤, 실패하는 접속을 한 번만 시도하세요. 새 연결 기록이 전혀 없다면 앱이 시스템 프록시를 사용하는지, 브라우저의 별도 프록시 설정이 이를 덮어쓰는지 먼저 확인하세요. 로컬 인바운드 기록 뒤에 오류가 발생한다면 요청이 코어에 도달한 것이므로 노드, 라우팅, DNS를 확인해야 합니다. 로그 수준이 낮으면 연결별 기록이 보이지 않을 수 있습니다. 잠시 한 단계 높여 확인한 뒤 원래대로 돌리세요.

프록시를 직접 지정해 시스템 설정 분리하기

아래 명령은 127.0.0.1:10808에서 SOCKS 서비스가 제공되는 것을 확인한 경우에만 사용하세요. 포트가 다르면 해당 값으로 바꿔야 합니다. Windows에서는 PowerShell에서 curl.exe를 사용하고 macOS와 Linux에서는 curl을 사용할 수 있습니다. 예시 도메인은 요청 경로 확인용이며 속도 비교용이 아닙니다. 도구가 설치되어 있지 않다면 앱 자체의 프록시 설정을 이용하세요. 이 문제를 해결하려고 별도의 네트워크 도구를 설치할 필요는 없습니다.

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

프록시를 직접 지정했을 때 응답이 오는데 일반 브라우저에서는 접속되지 않는다면 노드부터 의심하지 말고 시스템 프록시 항목을 확인하세요. 로컬 주소에 연결할 수 없다는 메시지가 나오면 코어 프로세스, 리스닝 포트, 포트 충돌을 점검하세요. 로컬 연결이 성립한 뒤 핸드셰이크 실패나 시간 초과가 발생한다면 노드 시간 초과 항목을 확인하세요. HTTP 오류 응답도 전송이 연결되었다는 증거일 수 있으므로 성공 상태가 아니라는 이유만으로 프록시 연결이 끊겼다고 판단하지 마세요.

연결 버튼이 아니라 복구 여부를 확인

복구 여부는 연결 버튼이 아니라 역순으로 확인하세요. 코어가 오류 없이 시작되고, 로컬 리스너가 열려 있으며, 앱 요청이 로그에 기록되고, 대상 페이지에서 응답이 와야 합니다. 한 번에 변수 하나만 바꾸고 처음 실패했던 접속을 다시 테스트하세요. 노드와 DNS, 라우팅, 브라우저 설정을 동시에 변경하면 결과의 원인을 알기 어렵고 기존 설정으로 되돌리기도 힘듭니다. 해결되면 조치 내용을 기록하고 필요한 로그만 보관하세요.

노드 시간 초과: 포트부터 전송 설정까지

시간 초과는 제한 시간 안에 어떤 작업이 끝나지 않았다는 뜻일 뿐, 문제가 발생한 위치를 직접 알려 주지는 않습니다. 노드 목록의 지연 시간 테스트, 전송 연결, 웹페이지 로딩은 서로 다른 대상과 경로를 사용할 수 있습니다. 먼저 어떤 작업에서 오류가 발생했는지 확인한 뒤 같은 시각의 코어 로그를 살펴보세요. 한 번의 테스트 실패만으로 노드가 영구적으로 작동하지 않는다고 단정할 수 없습니다. 연속으로 실패하더라도 로컬 네트워크 변경이나 설정 미적용 여부부터 확인하세요.

연결 거부, 핸드셰이크 실패, 응답 대기 시간 초과 구분하기

로그에 connection refused가 표시되면 해당 주소에서 연결을 받아들이지 않는다는 뜻인 경우가 많습니다. 포트가 잘못되었거나 서비스가 리스닝 중이지 않을 수 있고, 중간 장비가 연결을 거부했을 수도 있습니다. i/o timeout은 대기 시간이 끝났다는 뜻입니다. DNS 조회, 연결 시도, 응답 읽기 중 무엇을 기다렸는지 확인해야 합니다. EOF는 연결이 일찍 종료되었다는 의미일 뿐, 이 한 줄만으로 인증 정보 오류라고 단정할 수 없습니다. 앞뒤의 프로토콜 및 핸드셰이크 기록과 함께 살펴보세요.

먼저 시스템 날짜, 시간, 시간대를 확인하고 자동 시간 동기화를 켜세요. 인증서 유효 기간 확인과 일부 인증 방식은 정확한 시간을 필요로 합니다. 컴퓨터가 절전 모드에서 깨어났거나 오프라인 상태였을 때, 또는 시스템 시간을 수동으로 변경했을 때 갑자기 연결되지 않을 수 있습니다. 다음으로 점검 중인 항목이 실제 활성 노드인지 확인하고 이전 연결을 중지한 뒤 다시 연결하세요. 목록에서 한 항목을 선택했다고 해서 해당 노드가 활성 서버로 설정된 것은 아닐 수 있습니다.

그다음 서비스 제공업체가 안내한 설정과 비교해 서버 주소, 서버 포트, 사용자 ID 또는 비밀번호, 전송 방식, 보안 설정을 하나씩 확인하세요. 서버 포트는 원격 서비스에 접속하는 포트이고 로컬 리스닝 포트는 앱이 클라이언트에 연결하는 포트이므로 서로 바꿔 쓸 수 없습니다. 구독으로 가져온 항목도 오래된 캐시, 그룹 업데이트 실패, 수동 변경 때문에 현재 서버 설정과 다를 수 있습니다.

현재 노드에서 실제 사용하는 항목만 확인

WebSocket을 사용하는 항목은 경로와 Host를 확인하세요. 경로의 대소문자, 앞쪽 슬래시, 불필요한 공백도 일치 여부에 영향을 줄 수 있습니다. gRPC를 사용한다면 서비스 이름을 확인하세요. TLS를 사용하는 항목은 서버 이름과 인증서의 대응 관계를 확인해야 합니다. 연결 주소와 인증서 이름이 같지 않을 수도 있습니다. 오류를 없애려고 인증서 검증을 바로 끄지 마세요. 설정 문제를 가리고 연결 보안 범위를 바꿀 수 있습니다.

VLESS는 프록시 프로토콜이고 REALITY는 특정 구현과 관련된 보안 메커니즘이므로 같은 설정 스위치로 취급해서는 안 됩니다. REALITY 항목을 점검할 때는 서버가 요구하는 서버 이름, 공개 키, 짧은 ID, 지문 등의 매개변수를 확인하고 현재 코어가 해당 조합을 지원하는지 살펴보세요. v2rayNG와 v2flyNG는 서로 다른 코어 계열을 사용합니다. 같은 공유 링크를 가져올 수 있더라도 모든 필드를 그대로 실행할 수 있다는 뜻은 아닙니다.

전송 설정이 복잡한 항목은 기존 항목에서 여러 옵션을 연달아 시험하기보다 원본 설정을 다시 가져와 비교하세요. 기존 항목은 보존하고 테스트 항목에는 알아보기 쉬운 메모를 추가해 실수로 덮어쓰지 않도록 하세요. 다른 노드의 경로, 서버 이름, 보안 설정을 옮겨 쓰지 마세요. 이런 필드는 대개 함께 맞춰야 하므로 일부만 바꾸면 새로운 오류가 생길 수 있습니다.

변수를 통제해 원격 문제 확인하기

클라이언트 설정은 그대로 둔 채 정상 작동이 확인된 다른 노드로 바꿔 보세요. 새 노드가 연결된다면 원래 항목의 매개변수나 원격 서버 상태가 문제일 가능성이 높습니다. 같은 네트워크에서 모든 노드가 실패한다면 다른 정상 네트워크에서도 시도하고, 다른 프록시나 터널 프로그램은 잠시 중지하세요. 네트워크를 바꾼 뒤에는 연결을 새로 설정해야 합니다. 기존 연결은 네트워크 출구가 바뀌었다고 자동으로 유효한 비교 대상이 되지 않습니다.

주소와 포트가 맞고 클라이언트 호환성도 확인했으며 여러 네트워크에서 반복해서 실패한 경우에만 서비스 제공업체에 서버 리스너, 방화벽, 계정 상태를 문의하세요. 실패 시각, 사용한 코어, 개인정보를 가린 오류 로그, 모든 노드에서 실패했는지 여부를 전달하면 됩니다. 전체 구독 주소, 사용자 ID, 비밀번호, 공유 링크를 공개하지 마세요. 이 정보는 접속 인증 정보로 사용될 수 있습니다.

구독 실패: 가져오기와 파싱을 나눠 확인

구독 업데이트는 콘텐츠 가져오기, 형식 인식, 노드 파싱, 그룹에 저장하는 단계를 거칩니다. 업데이트 실패 메시지가 나온다고 해서 링크가 만료된 것은 아닙니다. 네트워크 연결 실패, 로그인 페이지 반환, 지원하지 않는 형식, 잘못 선택한 그룹도 원인일 수 있습니다. 전체 오류 문구를 먼저 기록하고 '요청 실패'와 '파싱 실패'를 구분한 뒤 네트워크와 콘텐츠 중 무엇을 확인할지 결정하세요. 처음부터 모든 노드를 삭제하면 비교에 필요한 정상 설정까지 잃을 수 있습니다.

기존 그룹과 정상 노드부터 보존

v2rayN에서 구독 그룹을 열고 업데이트할 그룹의 이름과 주소가 일치하는지 확인하세요. 중복 그룹이나 비슷한 메모가 있는지도 살펴보세요. 클라이언트에서 설정 내보내기를 지원한다면 백업을 로컬에 저장하고 안전하게 보관하세요. 백업에 계정 정보가 포함될 수 있습니다. 새 주소를 시험할 때는 기존 그룹을 덮어쓰지 말고 별도 그룹을 만들어야 되돌리기 쉽고 업데이트 전후의 노드도 비교하기 편합니다.

링크를 붙여넣을 때 앞뒤에 공백, 줄바꿈, 따옴표, 메신저가 추가한 안내 문구가 섞이지 않았는지 확인하세요. 물음표 뒤의 쿼리 매개변수에는 인증 정보나 형식 선택 정보가 포함될 수 있으므로 임의로 삭제하지 마세요. 유효 기간이 있는 링크는 다시 받아야 할 수 있지만, 길어 보인다는 이유만으로 문제가 있다고 판단할 수는 없습니다. 서비스 제공업체가 새 주소를 발급했다면 이전 주소의 유효 여부는 안내를 따르세요.

이번 업데이트가 직접 연결과 프록시 연결 중 어떤 방식으로 진행되는지도 확인하세요. 업데이트 메뉴의 이름은 클라이언트와 버전에 따라 다를 수 있으므로 해당 작업의 실제 안내를 확인해야 합니다. 현재 프록시 노드가 작동하지 않으면 그 노드로 구독을 업데이트하는 과정이 반복적으로 막힐 수 있습니다. 이 경우 직접 연결이 허용되는 네트워크에서 일반 업데이트를 시도하세요. 반대로 사용할 수 있는 프록시를 통해서만 구독 주소에 접근할 수 있다면 먼저 정상 연결을 선택한 뒤 업데이트하세요.

업데이트 버튼을 반복해서 누르지 말고 반환된 콘텐츠 확인

로그에 HTTP 상태가 기록된다면 인증 관련 오류는 주소와 계정 권한부터 확인하고, 요청이 너무 많다는 오류가 나오면 재시도를 멈추고 서버 안내를 따르세요. 성공 상태 코드가 나와도 노드 콘텐츠가 반환되었다는 뜻은 아닙니다. 네트워크 인증 포털, 로그인 페이지, 리버스 프록시 오류 페이지도 일반 웹페이지로 반환될 수 있습니다. 클라이언트가 이를 구독으로 파싱하면 페이지 내용은 알리지 않은 채 빈 목록이나 형식 오류만 표시할 수 있습니다.

응답 내용을 확인해야 한다면 신뢰할 수 있는 로컬 환경에서만 확인하고 구독 주소를 온라인 디코더나 테스트 도구에 붙여넣지 마세요. 반환된 내용이 클라이언트에서 지원하는 공유 링크 모음이나 구독 형식인지, 안내 페이지인지 확인하세요. 브라우저에 긴 텍스트가 표시된다는 것은 콘텐츠를 가져왔다는 뜻일 뿐, 모든 노드 프로토콜과 필드, 인코딩이 현재 클라이언트와 호환된다는 증거는 아닙니다.

같은 구독에서 일부 노드만 가져와졌다면 건너뛴 항목의 프로토콜과 전송 방식을 확인하세요. 필드가 빠졌거나 확장 형식을 지원하지 않을 수 있으며, 서버가 다른 설정 체계용 콘텐츠를 반환했을 수도 있습니다. 서비스 제공업체에 현재 클라이언트에 맞는 출력 형식을 요청하세요. 다른 용도의 전체 설정을 단일 노드 가져오기 창에 붙여넣지 마세요. 코어를 변경할 때도 지원하는 프로토콜을 먼저 확인해야 합니다.

필터, 그룹, 업데이트 결과 확인

업데이트 성공 메시지가 나왔는데도 목록이 비어 있다면 검색어를 지우고 전체 그룹으로 전환한 뒤, 노드 이름 필터나 숨김 설정이 켜져 있는지 확인하세요. 그런 다음 상태 메시지만 보지 말고 로그의 가져오기 개수와 현재 목록을 비교하세요. 일부 클라이언트는 새 구독 내용으로 그룹의 기존 항목을 교체할 수 있습니다. 서버가 빈 콘텐츠를 반환한 경우 업데이트를 반복하면 기존 노드가 사라질 수 있으므로 백업을 남겨 두면 복구가 수월합니다.

업데이트 성공이 연결 검증 성공을 뜻하지는 않습니다. 새로 가져온 항목 하나를 활성 노드로 선택해 다시 연결한 뒤 구독 가져오기 절차에 따라 접속을 확인하세요. 새 노드가 모두 실패하고 기존 노드는 작동한다면 설정 매개변수와 출력 형식을 중점적으로 비교하세요. 업데이트만 실패하고 기존 노드는 작동한다면 노드 라우팅, DNS, 전송 설정을 동시에 바꾸지 마세요.

형식 호환성 문제가 있다면 클라이언트 다운로드 페이지에서 운영체제와 아키텍처에 맞는 클라이언트를 선택하고 설정을 유지하는 방식으로 업그레이드하세요. 프로그램 업데이트가 모든 구독 문제를 해결해 주지는 않습니다. 만료된 주소, 계정 권한, 서버 오류는 각각 따로 확인해야 합니다. 가져오기 경로, 오류가 발생한 단계, 최종 가져오기 결과를 기록해 두면 다음 점검을 확인된 단계부터 시작할 수 있습니다.

속도 저하: 지연 시간, 처리량, 끊김 구분하기

'속도가 느리다'는 말에는 페이지를 처음 열 때 오래 기다리는 문제, 계속 다운로드 속도가 낮은 문제, 연결 후 자주 멈추는 문제 등 적어도 세 가지 상황이 포함됩니다. 지연 시간 테스트는 특정 요청의 응답 시간을 주로 측정하므로 대용량 파일의 처리량이나 모든 사이트의 성능을 그대로 나타내지 않습니다. 먼저 '같은 페이지가 처음에는 늦게 열리지만 새로고침하면 정상'처럼 증상을 구체적으로 기록한 뒤 이를 확인할 수 있는 테스트를 선택하세요.

조건을 고정해 정확하게 비교하기

테스트할 때는 기기, 네트워크, 클라이언트 라우팅, 대상 서비스를 고정하고 노드만 바꾸세요. 시스템 업데이트, 클라우드 동기화, 대용량 작업을 잠시 중지하고 로컬 대역폭이 이미 포화 상태가 아닌지 확인하세요. Wi-Fi 신호가 약하거나 라우터 부하가 높거나 연결된 기기가 많아도 프록시 속도가 느려질 수 있습니다. 프록시 없이 접속 가능한 서비스도 느리다면 코어를 계속 바꾸기보다 로컬 네트워크부터 점검하세요.

각 노드를 여러 번 테스트하고 일시적인 실패와 지속적인 이상을 구분해 기록하세요. 대상 서비스가 단일 연결의 속도를 제한하거나 출구 주소에 따라 콘텐츠 전송 경로를 다르게 선택할 수 있습니다. 한 노드에서 서비스마다 속도가 다른 것은 드문 일이 아닙니다. 한 사이트에서 한 번 측정한 결과로 모든 서비스의 성능을 판단하지 마세요. 페이지, 파일, 동영상을 테스트할 때는 가능한 한 같은 콘텐츠와 화질을 사용하세요.

노드 테스트에서 지연 시간이 낮은데도 페이지 로딩이 느리다면 로그에서 DNS 조회가 오래 걸리는지, 같은 연결을 반복하는지 확인하세요. 페이지는 여러 도메인에 동시에 요청하는 경우가 많아 기본 문서가 빨리 응답해도 이미지, 스크립트, API가 올바른 경로를 이용한다는 보장은 없습니다. 브라우저 개발자 도구로 DNS 조회, 연결 수립, 응답 대기 단계를 구분할 수 있습니다. 요청 주소에 개인정보가 포함될 수 있으니 주의하세요.

실제 출구 경로와 기기 자원 확인하기

잠시 프록시 라우팅이 확실한 설정을 선택해 느린 요청이 부적절한 직접 연결 경로로 빠지지 않는지 비교하세요. 라우팅을 임시 변경한 뒤 속도가 크게 나아진다면 원래 모드로 되돌리고 해당 규칙을 찾아야 합니다. 문제를 덮으려고 프록시 적용 범위를 계속 넓히지 마세요. 로그인이 필요한 서비스는 출구가 바뀌면 추가 인증을 요구할 수 있으므로 인증 대기 시간과 실제 전송 시간을 구분해 기록하세요.

다운로드가 계속 느리다면 시스템 작업 관리 도구에서 네트워크, 프로세서, 메모리 사용량을 확인하세요. 저전력 기기는 처리량이 높거나 암호화가 복잡하거나 연결이 많을 때 자원이 부족할 수 있습니다. 프로세서 사용률이 계속 높다면 지연 시간이 낮은 노드로 바꿔도 속도가 나아지지 않을 수 있습니다. 로그 수준을 지나치게 높이면 디스크 쓰기와 화면 갱신 부담도 커질 수 있으므로 진단 후에는 평소 설정으로 되돌리세요.

다중 연결은 모든 노드에 효과가 있는 가속 스위치가 아닙니다. 연결을 구성하는 방식이 바뀌며 실제 성능은 프로토콜, 전송 방식, 서버 지원, 네트워크 품질에 따라 달라집니다. 서비스 제공업체가 명시적으로 지원하는 경우에만 한 항목씩 비교하고 적용 전후 결과를 기록하세요. 다중 연결, 혼잡 관련 매개변수, DNS를 동시에 변경하면 속도 변화의 원인을 파악할 수 없습니다.

간헐적인 멈춤은 네트워크 변화부터 확인

대용량 전송은 시작한 뒤 멈추지만 작은 페이지는 열린다면 패킷 손실, 연결 재설정, 경로 차이, 서버 제한을 확인하세요. 연결이 한 번 성립했다고 해서 장시간 연결이 안정적으로 유지된다는 뜻은 아닙니다. 같은 노드를 다른 정상 네트워크에서 먼저 테스트한 뒤 경로 MTU를 확인할지 결정하세요. 작은 MTU 값을 그대로 적용하지 마세요. 일부 연결은 복구될 수 있지만 효율이 떨어지거나 새로운 호환성 문제가 생길 수도 있습니다.

연결한 지 한참 지난 뒤 느려진다면 기기 온도, 전원 모드, Android 백그라운드 제한, 네트워크 전환 기록도 확인하세요. 절전 모드에서 깨어나거나 Wi-Fi에 다시 연결된 뒤 이전 연결은 종료를 기다리는 중인데 새 연결은 이미 정상일 수 있습니다. 먼저 클라이언트 연결을 다시 설정해 비교하세요. 장시간 연결만 실패한다면 발생 시각과 네트워크 전환 상황을 기록해 추가로 진단하고, 노드 전체를 사용할 수 없다고 단정하지 마세요.

같은 시간대에 여러 기기에서 같은 노드의 처리량이 떨어지고 다른 노드로 바꾸면 회복된다면 원격 서버 부하나 출구 회선 문제일 가능성이 높습니다. 조건을 고정해 재현한 절차를 서비스 제공업체에 전달하세요. '속도 측정이 느리다'는 말만으로는 원인을 찾기 어렵습니다. 대상 서비스, 지속 시간, 직접 연결은 정상인지, 지연 시간은 낮지만 처리량은 낮은지 함께 설명하면 도움이 됩니다.

DNS 문제: 도메인을 어디서 조회하는지 확인

DNS 문제는 일부 도메인만 열리지 않거나 첫 접속에 오래 걸리거나 라우팅을 바꾼 뒤 결과가 달라지는 식으로 나타날 수 있습니다. 요청에 따라 시스템 DNS, 브라우저의 암호화 DNS, 코어 내장 DNS를 사용하거나 도메인 조회를 원격으로 전달할 수 있습니다. 먼저 앱이 클라이언트에 도메인을 전달하는지 이미 확인된 IP 주소를 전달하는지 파악한 뒤 해당 DNS 경로를 점검하세요. 시스템 DNS만 바꿔도 브라우저나 코어가 별도로 보내는 조회에는 영향을 주지 않을 수 있습니다.

같은 도메인으로 DNS 조회 단계 확인

먼저 실패한 도메인과 오류 문구를 기록하세요. 시스템에서 호스트를 찾을 수 없다는 메시지와 DNS 조회 후 연결 시간이 초과되는 문제는 발생 단계가 서로 다릅니다. 아래 시스템 명령으로 시스템 DNS 리졸버가 결과를 반환하는지 확인할 수 있습니다. 다만 프록시 코어가 같은 결과를 사용하는지, 대상 서비스에 연결할 수 있는지까지 증명하지는 않습니다. 캐시 영향을 배제하려면 설정을 변경한 뒤 연결을 다시 설정하고 다른 사이트가 아니라 같은 도메인을 다시 테스트하세요.

nslookup example.com

시스템 DNS 조회는 실패하지만 SOCKS 프록시를 직접 지정하면 접속된다면 프록시가 다른 DNS 경로로 도메인 조회를 전달할 수 있습니다. 앞서 나온 명령에서 socks5h는 curl이 도메인을 SOCKS 서버에 전달하게 합니다. socks5를 사용하면 일반적으로 curl이 로컬에서 먼저 도메인을 조회합니다. 두 방식은 비교 테스트에 유용하지만, 로컬 프록시가 도메인을 받은 뒤 실제로 어디서 조회하는지는 코어 라우팅과 DNS 설정에 따라 달라집니다.

브라우저 하나에서만 문제가 발생한다면 브라우저에 별도의 보안 DNS 설정이 켜져 있는지 확인하세요. 브라우저가 시스템 DNS를 사용하지 않거나 자체 DNS 조회에 실패해 로컬 프록시에 요청을 보내지 못할 수 있습니다. 잠시 시스템 DNS를 사용하도록 바꾸면 원인을 좁히는 데 도움이 됩니다. 테스트 후에는 실제 사용 환경에 맞춰 유지 여부를 결정하세요. 브라우저 설정과 코어 DNS를 동시에 변경하면 두 단계의 문제를 구분하기 어렵습니다.

코어 DNS와 라우팅의 관계 확인

코어의 DNS 설정에는 서버 주소뿐 아니라 조회 유형, 요청이 사용할 아웃바운드, 라우팅 규칙 적용을 위해 도메인을 IP 주소로 변환할지 여부도 포함됩니다. 아래는 필드 구성을 설명하는 부분 JSON입니다. 초기 라우팅 판단에 도메인을 유지하고 주소 규칙 적용을 위해 자동으로 조회하지 않습니다. 이 예시는 완전한 실행 설정이 아니므로 클라이언트가 생성한 전체 파일을 대신해 사용할 수 없습니다.

{
  "routing": {
    "domainStrategy": "AsIs"
  }
}

해당 필드를 지원하는 Xray 및 V2Fly 설정에서 AsIs는 모든 도메인이 절대 조회되지 않는다는 뜻이 아닙니다. 실제 연결이나 다른 구성 요소에서 주소가 필요할 수 있습니다. 도메인이 규칙에 일치하지 않은 뒤 조회하는 정책을 선택하면 이후 주소 규칙을 적용할 수 있지만 DNS 의존성도 늘어납니다. 먼저 분기 라우팅의 목표를 분명히 한 뒤 정책을 선택하세요. DNS 오류가 보인다고 모든 옵션을 무작정 바꾸지 마세요.

암호화 DNS를 사용할 때는 DNS 서버 자체의 도메인에서 IP 주소를 어떻게 얻는지, 해당 서버 연결이 직접 연결과 프록시 중 어떤 경로를 사용하는지도 고려해야 합니다. 프록시를 연결하기 위해 노드 주소를 먼저 조회해야 하는데 DNS 조회가 아직 연결되지 않은 프록시에 의존하면 시작 단계에서 순환이 발생할 수 있습니다. 시작 시점에 접근 가능한 DNS 경로를 남기고 클라이언트의 해당 설정 안내를 따르세요. DNS 서버를 단순히 더 추가하는 방식으로 해결하지 마세요.

IPv6, 캐시, FakeDNS는 따로 확인

일부 네트워크는 IPv6 주소를 반환하지만 대상까지의 IPv6 경로가 불완전해 연결이 지연된 뒤 IPv4로 전환되거나 간헐적으로 시간 초과가 발생할 수 있습니다. 먼저 기기가 안정적인 IPv6 연결을 실제로 지원하는지 확인한 다음 지원되는 설정에서 주소 계열 정책을 비교하세요. 임시로 IPv4를 사용해 확인할 수 있지만 모든 문제를 IPv6 비활성화로 해결해야 한다는 뜻은 아닙니다. 네트워크마다 결과는 다를 수 있습니다.

DNS 설정을 바꾼 뒤에도 기존 연결, 앱 캐시, 시스템 캐시에 이전 주소가 남아 있을 수 있습니다. 관련 페이지와 연결을 닫고 운영체제에서 제공하는 방법으로 캐시를 새로고침하세요. 재현 조건을 놓치지 않도록 기기 전체를 반복해서 재시작하지 마세요. FakeDNS를 사용하는 경우 앱이 받은 가상 주소는 해당 코어가 도메인으로 되돌려야 합니다. 트래픽 처리 방식을 바꾼 뒤 남은 가상 주소는 라우팅되지 않을 수 있으므로 앱에서 다시 DNS 조회를 수행하게 해야 합니다.

문제 해결을 시작할 때는 먼저 단순하고 동작을 설명할 수 있는 DNS 경로로 복구한 뒤, 정상 여부를 확인하고 복잡한 기능을 하나씩 추가하세요. 로그에서 조회 오류뿐 아니라 최종 아웃바운드도 확인해야 합니다. DNS 조회 성공 기록만 보고 이후 연결 실패를 놓치지 마세요. 가상 IP 방식의 원리와 적용 범위는 FakeDNS 원리 자세히 알아보기에서, 관련 용어는 용어 설명에서 확인할 수 있습니다.

시스템 프록시가 작동하지 않음: 트래픽 전달과 분기 확인

시스템 프록시, 코어 라우팅, 투명 프록시 처리는 서로 다른 단계입니다. 시스템 프록시는 해당 설정을 지원하는 앱에 요청을 전달할 위치를 알려 줍니다. 라우팅은 코어가 받은 요청을 어떤 아웃바운드로 보낼지 결정합니다. 투명 프록시는 다른 계층에서 트래픽을 가져오려는 방식입니다. 따라서 라우팅을 전역 모드로 바꾸더라도 시스템 프록시를 무시하는 앱이 클라이언트에 자동 연결되지는 않습니다. 먼저 요청이 코어에 도달하는지 확인한 다음 적용할 규칙을 살펴보세요.

주소, 포트, 앱 동작 확인

v2rayN에서 시스템 프록시 자동 설정을 선택한 뒤 운영체제의 네트워크 설정에서 프록시 주소가 클라이언트의 실제 리스너와 일치하는지 확인하세요. 같은 기기에서 사용할 때는 보통 루프백 주소를 지정하지만 포트는 현재 설정을 기준으로 해야 합니다. 원격 노드 주소를 시스템 프록시 항목에 입력하거나 SOCKS 전용 포트를 HTTP 프록시로 사용하지 마세요. 혼합 리스너를 사용한다면 앱에서 쓰는 프로토콜을 실제로 지원하는지 확인해야 합니다.

Windows에서는 앱마다 서로 다른 프록시 설정을 참조할 수 있고 명령줄 도구가 브라우저 설정을 따르지 않을 수도 있습니다. macOS 프록시 설정은 현재 네트워크 서비스와 연결되므로 유선과 무선 네트워크를 전환한 뒤 다시 확인하세요. Linux에서는 데스크톱 환경, 앱 설정, 터미널 환경 변수가 서로 독립적일 수 있습니다. 따라서 브라우저가 작동한다고 해서 다른 프로그램의 경로까지 정상이라고 볼 수는 없습니다.

일부 앱에는 자체 HTTP 또는 SOCKS 설정이 있으므로 시스템 프록시 설정을 덮어쓰는지 확인하세요. 브라우저 확장 프로그램, 개발 도구, 다운로드 도구가 이전 주소를 저장했을 수도 있습니다. 터미널 도구는 프록시 환경 변수와 제외 목록을 읽을 수 있습니다. 제외 규칙이 적용되면 요청이 지정된 프록시를 우회합니다. 시스템 설정 화면의 스위치 하나만 보지 말고 해당 프로세스가 설정을 어디서 가져오는지 확인하세요.

라우팅 규칙과 아웃바운드를 순서대로 확인

요청이 코어에 도달하는 것을 확인한 뒤 어떤 라우팅 규칙이 적용되는지 확인하세요. 대부분의 규칙은 순서대로 검사하므로 앞쪽의 넓은 규칙이 뒤쪽의 구체적인 규칙보다 먼저 적용될 수 있습니다. 아래 일부 규칙 예시는 예시 도메인과 하위 도메인을 direct라는 아웃바운드로 보내는 설정입니다. 전체 설정에 해당 아웃바운드 태그가 정의된 경우에만 사용할 수 있습니다. 이 조각을 독립된 설정으로 가져오지 마세요.

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

규칙에 표시되는 이름이 실제 아웃바운드 태그와 같지 않을 수 있으므로 사용자 지정 규칙을 변경하기 전에 생성된 설정을 확인하세요. 앱이 도메인을 IP 주소로 바꾼 뒤 요청을 보내면 인바운드에 주소 정보만 남아 도메인 규칙이 적용되지 않을 수 있습니다. 일부 환경에서는 트래픽 탐지로 도메인 정보를 보완할 수 있지만 프로토콜과 설정의 제약이 있어 모든 요청의 원래 도메인을 복원할 수는 없습니다. 로그에서 규칙 적용에 필요한 정보가 있는지 확인하세요.

라우팅을 잠시 전역 모드로 바꾼 뒤 정상화된다면 기존 규칙, DNS 결과, 기본 아웃바운드가 원인일 수 있습니다. 원래 모드로 되돌린 뒤 실패한 도메인 하나에 구체적인 비교 규칙을 추가하고 적용 후 정상화되는지 확인하세요. 모든 규칙을 지우거나 적용 범위를 계속 넓히지 마세요. 직접 연결해야 하는 로컬 네트워크 서비스, 업무 네트워크, 로컬 기기까지 영향을 받을 수 있습니다.

여러 프록시 설정이 서로 덮어쓰는지 확인

프록시 프로그램을 여러 개 실행하면 시스템 프록시 설정이나 로컬 포트를 두고 충돌할 수 있습니다. 하나를 닫아도 다른 프로그램이 자동으로 트래픽을 가져오지 않을 수 있습니다. 테스트할 때는 클라이언트 하나만 남기고 시스템 프록시를 다시 적용한 뒤 실제 주소를 확인하세요. 투명 프록시나 가상 네트워크 어댑터 모드를 사용 중이라면 어느 단계에서 트래픽을 가져오는지 분명히 해야 합니다. 요청 순환이나 중복 처리를 막을 수 있습니다.

앱이 시스템 프록시를 사용하지 않고 다른 방식의 트래픽 전달이 꼭 필요한 경우에만 클라이언트가 지원하는 다른 모드를 고려하세요. 권한이 필요한 모드는 플랫폼 안내에 따라 승인해야 하며, 원인을 찾는 대신 항상 관리자 권한으로 실행하지 마세요. 관리되는 기기의 시스템 프록시는 조직 정책에 의해 설정될 수 있습니다. 이때 로컬 변경이 덮어써진다면 설정을 계속 강제로 바꾸지 말고 기기 관리 지침을 따르세요.

복구를 확인할 때는 원래 실패했던 앱과 정상적인 직접 연결 서비스 하나를 모두 테스트하고, 클라이언트를 종료한 뒤에도 네트워크가 복구되는지 확인하세요. 로컬 네트워크에서만 문제가 발생한다면 제외 목록, 리스닝 범위, 규칙 순서를 점검하세요. 모든 인바운드 인터페이스를 무작정 열지 마세요. 용어가 헷갈린다면 먼저 라우팅 및 DNS 용어를 확인한 뒤 이 장에서 각 설정의 단계와 역할을 점검하세요.

시작 실패 및 충돌: 화면과 코어 구분하기

시작 문제는 먼저 화면이 열리지 않는 경우, 화면은 정상인데 코어가 종료되는 경우, 일정 시간 실행 후 프로그램 전체가 종료되는 경우로 나눠 확인하세요. 각 문제는 실행 환경, 설정이나 포트, 리소스 및 시스템 이벤트와 관련될 가능성이 높습니다. 마지막으로 확인한 화면과 전체 오류 내용을 기록하고 설정 폴더를 바로 삭제하지 마세요. 클라이언트 화면이 계속 실행 중이어도 트레이 아이콘이 있다는 이유만으로 코어가 정상적으로 시작된 것은 아닙니다.

설치 파일과 시스템 아키텍처 확인

먼저 클라이언트 다운로드 페이지에서 운영체제와 프로세서 아키텍처에 맞는 항목을 선택했는지 확인하세요. Windows 데스크톱 버전과 클래식 WPF 버전은 화면과 실행 환경이 다를 수 있으므로 각 설치 항목의 안내를 따르세요. macOS는 Apple Silicon과 Intel을 구분해야 합니다. Linux는 프로세서 아키텍처뿐 아니라 배포판에 맞는 패키지 형식도 확인해야 하며 파일 확장자가 비슷하다는 이유만으로 설치를 시도해서는 안 됩니다.

시스템에서 실행 구성 요소가 없다고 알리면 오류가 가리키는 구성 요소와 현재 클라이언트 버전을 먼저 확인하세요. 출처를 알 수 없는 동적 라이브러리를 복사하지 마세요. Linux 그래픽 프로그램은 데스크톱 세션과 그래픽 환경도 필요합니다. 명령줄 환경만 있다면 화면이 나타나지 않는 것이 코어의 네트워크 기능 오류를 의미하지는 않습니다. 설치 권한이나 시스템 보안 경고는 운영체제가 지원하는 절차에 따라 처리하고 보안 기능 전체를 끄지 마세요.

업데이트 후 문제가 생겼다면 이전 인스턴스를 완전히 종료하고 백그라운드에 남은 프로세스가 없는지 확인한 뒤 새 프로그램을 실행하세요. 여러 인스턴스가 설정 파일과 리스닝 포트를 두고 충돌할 수 있습니다. 기존 설정은 백업하고 별도의 테스트 디렉터리나 클라이언트가 지원하는 새 설정 방식으로 확인하세요. 이전 프로그램 디렉터리의 코어와 새 화면을 임의로 섞어 쓰면 원인을 찾기 어려운 호환성 차이가 생길 수 있습니다.

리스닝 포트 사용 여부 확인

로그에 주소 사용 중 또는 바인딩 실패가 표시되면 먼저 해당 포트를 사용 중인 프로세스를 확인하세요. 아래에서는 10808로 조회 방법을 설명하지만 모든 버전의 기본 포트라는 뜻은 아닙니다. Windows 명령은 PowerShell에서 실행하세요. macOS와 Linux에서는 도구 설치 여부에 따라 사용할 수 있는 명령이 다를 수 있습니다. 조회 결과가 없더라도 해당 시점에 리스너를 발견하지 못했다는 뜻일 뿐입니다. 코어를 다시 시작하고 로그를 확인해야 합니다.

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

# macOS
lsof -nP -iTCP:10808 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :10808'

프로세스 식별자를 확인한 뒤 시스템 프로세스 도구에서 프로그램 이름과 경로를 먼저 확인하세요. 정체를 모르는 프로세스를 바로 종료하지 마세요. 이전 클라이언트 인스턴스라면 정상 종료한 뒤 다시 시도하고, 계속 실행해야 하는 다른 서비스라면 클라이언트 설정에서 사용하지 않는 포트로 바꾸세요. 변경 후에는 시스템 프록시와 앱별 프록시 설정도 함께 업데이트해야 합니다. 그렇지 않으면 코어가 정상적으로 시작되어도 요청은 이전 주소로 전송됩니다.

로그에 설정 파싱 실패가 표시되면 처음 나타난 문법 또는 필드 오류부터 확인하세요. 사용자 지정 JSON에서는 불필요한 쉼표, 잘못된 따옴표, 필드 계층 오류, 존재하지 않는 아웃바운드 태그가 자주 문제가 됩니다. 최근 변경을 먼저 되돌린 뒤 설정을 다시 생성하세요. 여러 부분을 한꺼번에 추측해 수정하지 말고 로그 끝부분의 종료 메시지를 근본 원인으로 오인하지 마세요. 실제 오류는 그보다 앞에 나타나는 경우가 많습니다.

실행 중 종료와 리소스 문제 진단

일정 시간 실행한 뒤에 충돌한다면 발생 직전에 구독 업데이트, 네트워크 전환, 시스템 절전 해제, 상세 로그 사용이 있었는지 기록하세요. 디스크 여유 공간, 메모리 압박, 설정 디렉터리의 쓰기 권한을 확인하세요. 동기화 프로그램이 설정 파일을 함께 수정하거나 디렉터리 권한이 바뀌거나 디스크 쓰기가 실패해도 문제가 생길 수 있습니다. 여러 프로그램이 동시에 변경하는 위치에 활성 설정을 두지 마세요.

화면은 종료됐는데 코어가 남아 있다면 관련 인스턴스를 정상 종료한 뒤 시스템에서 이전 리스너를 가리키는 프록시 설정을 정리하세요. 바탕 화면 바로 가기를 삭제해도 백그라운드 프로세스는 종료되지 않습니다. 운영체제에 충돌 이벤트 기록이 있다면 오류 발생 시각을 기준으로 관련 이벤트를 찾아 모듈과 오류 유형을 기록하세요. 기록을 공유하기 전에는 사용자 이름, 개인 경로, 노드 매개변수가 포함될 수 있는 명령줄 내용을 가리세요.

깨끗한 테스트 설정에서는 정상적으로 시작되지만 기존 설정을 복원한 뒤 문제가 재현된다면 구독 그룹, 사용자 지정 라우팅, DNS, 기타 확장 설정을 나눠서 복원하세요. 이렇게 하면 기존 설정을 한꺼번에 되돌리는 대신 문제를 일으키는 조건을 찾을 수 있습니다. 포트 충돌에 관한 자세한 해결 방법은 충돌 프로세스 확인 및 리스닝 포트 변경을 참고하세요.

Android 문제 해결: 권한, 백그라운드, 앱별 설정

Android의 v2rayNG와 v2flyNG는 일반적으로 VpnService로 앱 트래픽을 전달합니다. 시스템 연결 권한, 백그라운드 정책, 앱별 규칙이 실제 동작에 영향을 줄 수 있습니다. 연결 버튼이 실행 상태로 바뀌어도 시작 절차가 해당 단계에 도달했다는 뜻일 뿐입니다. 시스템의 VPN 표시, 알림, 클라이언트 로그도 확인하세요. 시작 직후 실패하는지, 화면을 잠근 뒤 끊기는지, 일부 앱에서만 작동하지 않는지 먼저 구분하세요.

VpnService 권한과 연결 앱 확인

처음 연결할 때 시스템에서 앱의 VPN 연결을 허용하라는 메시지가 표시됩니다. 현재 사용하는 클라이언트가 권한을 요청하는지 확인하세요. 창이 나타나지 않거나 곧바로 닫힌다면 다른 시스템 화면에 가려졌는지, 기기 관리 정책이 연결을 제한하는지 확인해야 합니다. 시작 버튼을 빠르게 반복해서 누르지 마세요. 권한 요청, 중지, 재시작이 뒤섞여 로그를 파악하기 어려워질 수 있습니다.

일반적으로 같은 시스템 사용자에서는 한 번에 하나의 앱만 VPN 연결을 사용할 수 있습니다. 같은 인터페이스를 쓰는 다른 네트워크 도구가 기존 연결을 바꿀 수 있으며, 반대로 v2rayNG를 시작하면 다른 연결이 중지될 수도 있습니다. 문제를 확인할 때는 다른 유사 도구를 먼저 중지하고 대상 클라이언트를 시작한 뒤 시스템에 표시된 연결 앱을 확인하세요. 노드 비교를 위해 v2rayNG와 v2flyNG를 동시에 실행하지 말고 각각 따로 테스트하세요.

시스템에서 VPN 항상 사용 또는 VPN을 통하지 않는 연결 차단을 켰다면 클라이언트를 중지한 뒤에도 직접 연결이 안 될 수 있습니다. 구독이 자동으로 손상된 것이 아니라 시스템 정책이 트래픽을 계속 제한하는 상황입니다. 시스템의 VPN 설정에서 현재 앱과 관련 옵션을 확인하고 필요에 따라 조정하세요. 업무 프로필과 개인 프로필의 관리 정책이 다를 수 있으므로 문제가 발생한 프로필 공간에서 확인해야 합니다.

화면을 잠근 뒤 연결이 끊기면 전원 및 데이터 제한부터 확인

화면이 켜져 있을 때는 작동하지만 잠시 잠근 뒤 실패한다면 클라이언트 프로세스가 계속 실행 중인지, 알림이 사라졌는지, 로그가 끊겼는지 확인하세요. 시스템 절전 정책이 백그라운드 네트워크를 제한하거나 프로세스를 종료할 수 있습니다. 현재 클라이언트의 백그라운드 실행을 허용하거나 적절한 배터리 정책을 설정하고 제조업체의 자동 시작 및 백그라운드 관리 옵션도 확인하세요. 메뉴 이름은 시스템마다 다르므로 기기 화면을 기준으로 확인해야 합니다.

백그라운드 실행을 허용해도 모든 네트워크 조건이 허용되는 것은 아닙니다. 백그라운드 데이터와 데이터 절약 설정도 확인하세요. Wi-Fi에서는 정상인데 모바일 네트워크에서 실패한다면 클라이언트와 대상 앱이 해당 네트워크를 사용할 수 있는지 확인하세요. 설정을 바꾼 뒤 다시 연결하고 같은 앱을 사용해 같은 시간 동안 화면을 잠근 채 테스트하세요. 잠금을 해제한 뒤 정상으로 돌아왔다고 해서 백그라운드 문제가 해결된 것은 아닙니다. 앱이 전면으로 돌아올 때 연결을 새로 설정했을 수 있습니다.

알림은 그대로인데 네트워크가 바뀌었다면 이전 연결이 제때 복구되지 않았을 수 있습니다. Wi-Fi와 모바일 네트워크 전환 시각을 기록하고 연결을 중지한 뒤 다시 시작해 비교하세요. 재연결 직후 정상으로 돌아온다면 DNS를 계속 바꾸기보다 네트워크 전환 후 복구 과정을 살펴보세요. 깊은 절전 모드 진입, 일시적인 신호 끊김, 액세스 포인트 전환은 기존 연결에 영향을 줄 수 있습니다.

앱별 목록이 어떤 의미인지 확인

앱별 프록시를 켠 뒤에는 현재 모드가 선택한 앱만 프록시를 통과시키는지, 선택한 앱을 프록시에서 제외하는지 확인하세요. 반대 모드에서는 같은 체크 목록이 정반대로 작동할 수 있으므로 앱에 체크 표시가 있는지만 보면 안 됩니다. 설정을 바꾼 뒤 클라이언트 연결을 다시 설정하고 대상 앱을 완전히 종료한 다음 다시 실행해 기존 연결이 이전 경로를 계속 사용하지 않도록 하세요. 새로 설치한 앱이 자동으로 범위에 포함되는지도 선택한 모드에 따라 달라집니다.

일부 서비스는 시스템 구성 요소, 다운로드 서비스, 별도의 로그인 프로세스를 호출하므로 실제 요청이 화면에 보이는 앱에서만 발생하지 않을 수 있습니다. 문제를 점검할 때 앱별 제한을 잠시 해제해 전체 트래픽 전달이 정상인지 확인하세요. 정상화되면 범위를 단계적으로 좁히세요. 메인 앱에서 홈 화면이 열린다고 모든 기능이 정상인 것은 아닙니다. 로그인, 첨부 파일 다운로드, 미디어 재생은 서로 다른 경로를 사용할 수 있습니다.

v2rayNG에서 v2flyNG로 바꿀 때는 시스템 권한, 앱별 설정, 프로토콜 호환성을 다시 확인해야 합니다. 두 클라이언트는 각각 Xray와 V2Fly 코어 계열을 사용하므로 모든 확장 매개변수가 서로 호환된다고 가정할 수 없습니다. 노드 요구 사항에 맞는 클라이언트를 우선 선택하고 명확하게 지원되는 항목 하나로 확인한 뒤 사용자 지정 설정을 복원하세요. 설치 항목과 아키텍처 선택은 Android 클라이언트 다운로드를 참고하세요.