v2rayN 문제 해결 가이드

인터넷에 연결되지 않을 때: 트래픽이 막힌 지점부터 확인

인터넷 연결이 안 되는 원인은 로컬 네트워크 끊김, 앱의 프록시 미사용, 코어 실행 실패, 원격 연결 불가 등 다양합니다. 먼저 영향을 받는 범위를 확인하세요. 모든 앱이 안 되는지 브라우저만 안 되는지, 모든 사이트가 안 되는지 특정 도메인만 안 되는지 살펴봅니다. 범위에 따라 점검할 곳이 달라집니다. 구독 업데이트, 코어 변경, TUN 활성화를 한꺼번에 하지 마세요. 연결이 복구되더라도 어떤 변경이 효과가 있었는지 알 수 없습니다.

직접 연결을 복구해 기준 상태 만들기

v2rayN에서 ‘시스템 프록시 해제’를 선택하고 ‘TUN 모드 사용’을 끄세요. 운영체제 네트워크 설정에 수동 프록시가 남아 있지 않은지도 확인합니다. 다른 프록시 프로그램을 종료한 뒤 브라우저를 다시 열어 평소 직접 접속하던 사이트에 접속해 보세요. 그래도 연결되지 않으면 무선 연결, 네트워크 케이블, 게이트웨이, 네트워크 로그인 페이지부터 확인하세요. 이 경우 클라이언트가 우선 점검 대상은 아닙니다. 공용 네트워크는 웹 인증을 먼저 완료해야 할 수 있으며, 프록시 설정 때문에 인증 페이지에 접속하지 못할 수도 있습니다.

직접 연결이 복구되면 클라이언트를 다시 실행하되 TUN은 끈 상태로 두고 시스템 프록시 경로만 테스트하세요. 클라이언트를 종료한 뒤 오히려 인터넷 전체가 끊긴다면, 남은 프록시 주소가 중지된 로컬 수신 포트를 가리키는지 확인해야 합니다. 프록시를 해제한 뒤 앱을 다시 열어 이전 연결이 계속 재사용되지 않도록 하세요. 브라우저에 캐시된 페이지가 표시되는 것만으로 네트워크 복구를 확인할 수는 없습니다. 실제로 인터넷이 필요한 페이지를 새로고침하세요.

활성 설정과 로컬 수신 상태 확인

목록에 사용할 수 있는 설정이 있는지 확인하고 테스트할 설정을 활성 항목으로 지정하세요. 구독 그룹이 있다고 해서 그 안에 노드가 있다는 뜻은 아닙니다. 주소를 추가한 것만으로 업데이트가 끝난 것도 아닙니다. 그런 다음 로그에서 코어가 시작 직후 종료되지 않았는지 확인하세요. 설정 파싱, 포트 바인딩, 리소스 파일 읽기에 실패했다면 로컬 실행 문제부터 해결해야 합니다. 원격 노드를 계속 바꿔도 이런 오류는 해결되지 않습니다.

클라이언트 기본 설정에서 실제 수신 주소, 포트, 프로토콜을 확인해 기록하세요. 앱 설정의 프록시 포트는 여기에 표시된 값과 일치해야 합니다. 가이드의 예시만 보고 값을 추측하지 마세요. 루프백 주소로 수신하는 것은 로컬 기기에서만 사용할 수 있는 정상적인 설정입니다. 로그에 주소가 이미 사용 중이라고 나오면 충돌 프로그램을 찾거나 수신 포트를 변경하고 앱 설정도 함께 수정하세요. 한쪽만 바꾸면 안 됩니다.

최소한의 경로로 진입 지점과 출구 구분

브라우저 하나, 테스트 대상 하나, 활성 설정 하나만 사용하세요. 시스템 프록시를 ‘시스템 프록시 자동 설정’으로 지정하고 브라우저에서 프록시를 가로채는 확장 프로그램은 잠시 사용 중지합니다. 클라이언트 로그에 해당 요청이 기록되면 트래픽이 최소한 로컬 진입점까지 도달한 것입니다. 다음으로 라우팅 규칙 적용 여부와 원격 오류를 확인하세요. 요청이 전혀 기록되지 않으면 브라우저 자체 설정, 시스템 프록시 적용 여부, 앱의 프록시 우회 여부부터 점검합니다.

실패한 요청이 최종적으로 직접 연결과 프록시 중 어느 쪽으로 전달되는지도 확인하세요. 규칙에 따라 테스트 도메인이 직접 연결로 분류됐다면, 그 실패만으로 프록시 노드에 문제가 있다고 판단할 수 없습니다. 클라이언트에서 명확하게 프록시를 사용하는 테스트 경로를 임시로 선택할 수 있습니다. 테스트가 끝나면 원래 라우팅으로 되돌리세요. 테스트를 위해 모든 트래픽을 프록시로 보내도록 영구 변경하거나 기존 규칙을 삭제하지 마세요. 변경을 되돌릴 수 있어야 로컬 네트워크, 사내 리소스, 다른 앱에 미치는 영향을 막을 수 있습니다.

결과에 따라 다음 항목 확인

로컬 진입은 정상이지만 원격 핸드셰이크가 실패하면 노드 시간 초과 항목을 확인하세요. 도메인만 실패하고 다른 대상은 정상이면 DNS 문제 항목을, 브라우저는 정상인데 터미널이 실패하면 시스템 프록시 항목을 확인하세요. 변경할 때마다 동일한 대상으로 다시 테스트하고 오류 메시지가 바뀌었는지 기록합니다. 연결 거부가 핸드셰이크 실패로 바뀌었다면 문제 위치가 달라진 것입니다. 이를 모두 ‘여전히 작동하지 않음’으로 묶어 판단하지 마세요.

노드 시간 초과: 연결·핸드셰이크·응답 단계 구분

시간 초과는 대기 시간이 제한을 넘었다는 뜻일 뿐, 서버가 중단됐다는 의미는 아닙니다. 연결 수립, 프로토콜 핸드셰이크, 도메인 확인, 대상 페이지 응답 중 어느 단계에서도 시간 초과가 발생할 수 있습니다. 로그를 열어 테스트 시각과 가까운 첫 오류를 찾으세요. 마지막 줄만 확인하지 마세요. 앞서 발생한 이름 확인 실패나 연결 거부가 연이어 발생한 시간 초과보다 원인을 찾는 데 더 중요한 경우가 많습니다. 테스트 중에는 다른 네트워크 작업을 줄여 로그의 대상이 쉽게 구분되도록 하세요.

테스트가 무엇을 측정하는지 확인

TCP 연결 테스트는 지정한 주소와 포트에 연결할 수 있는지만 확인하는 경우가 많습니다. 사용자 인증 정보, 전송 경로, 대상 웹사이트까지 검증하지는 않습니다. 실제 요청 테스트는 사용 상황에 더 가깝지만 테스트 주소, DNS, 라우팅의 영향을 받습니다. 특정 테스트에서 결과가 나오지 않아도 설정을 바로 삭제하지 마세요. 먼저 브라우저에서 알고 있는 주소에 접속하고, 클라이언트에 같은 요청이 기록되는지 확인하세요.

목록의 모든 설정이 동시에 실패하면 로컬 네트워크, 시스템 시간, 구독 매개변수, 테스트 대상처럼 공통된 요인을 먼저 확인하세요. 한 항목만 실패한다면 같은 구독에 있는 다른 항목의 결과와 비교합니다. 비교할 때는 같은 네트워크와 같은 테스트 방법을 유지하세요. 서로 다른 시간과 대상을 사용한 결과를 한데 섞지 마세요. 동시 테스트를 많이 하면 연결 제한에 걸릴 수도 있으므로, 진단할 때는 항목별로 하나씩 테스트하는 편이 결과를 해석하기 쉽습니다.

로그에 나타난 단계별로 조치

‘연결이 거부됨’은 대상 주소까지는 도달했지만 해당 포트가 연결을 받지 않거나 중간 장비가 연결을 거부했음을 뜻하는 경우가 많습니다. 주소와 포트를 확인한 뒤 서비스 제공자에게 서버 상태를 문의하세요. ‘네트워크에 연결할 수 없음’은 로컬 라우팅, 주소 체계, 네트워크 출구 문제일 가능성이 큽니다. ‘시간 초과’는 연결 수립 전인지 핸드셰이크 이후인지 더 확인해야 합니다. 코어마다 오류 문구가 다를 수 있으므로 앞뒤 로그를 함께 살펴보세요.

인증서, 서버 이름, 핸드셰이크 관련 오류가 발생하면 전송 보안 설정, 서버 이름, 전송 유형과 경로를 확인하세요. 일부 설정에서는 연결 주소와 서버 이름이 원래 다를 수 있으므로, 보기 좋게 맞춘다고 임의로 바꾸지 마세요. REALITY 설정이라면 공개 키, 짧은 ID, 지문이 모두 제대로 입력됐는지도 확인합니다. 항목을 하나씩 추측해 바꾸기보다 서비스 제공자가 준 원본 링크를 다시 가져오는 편이 안전합니다.

시간·주소 체계·네트워크 차이 확인

운영체제의 날짜와 시간을 자동으로 설정하고 실제 시각이 맞는지 확인하세요. 시간 오차는 인증서 유효 기간 확인이나 일부 프로토콜 인증에 영향을 줄 수 있습니다. 시각은 그대로 둔 채 시간대만 바꾸는 것으로는 해결되지 않습니다. 기기가 절전 모드에서 막 깨어났다면 네트워크와 시간 동기화가 완료될 때까지 기다린 뒤 클라이언트를 재시작해 테스트하세요. 시간이나 이름 오류를 가리기 위해 인증서 검증을 끄지 마세요. 기존 연결의 보안 경계가 달라집니다.

노드 도메인에서 IPv4와 IPv6 주소가 함께 반환될 수 있습니다. 기기에 IPv6 주소가 있다고 해서 원격 경로도 사용할 수 있다는 뜻은 아니며, 반대로 IPv6에 반드시 문제가 있다고 단정할 수도 없습니다. 클라이언트가 지원하는 주소 정책에서 주소 체계 하나를 임시로 제한해 다른 조건은 유지한 채 비교 테스트하세요. 테스트가 끝나면 원래 설정으로 복구합니다. 사용이 허용된 다른 네트워크로 바꿔 보는 것도 도움이 됩니다. 결과가 네트워크에 따라 달라진다면 전체 설정을 다시 만들기보다 네트워크 출구 라우팅을 더 살펴보세요.

설정은 유지하고 제공자에게 유용한 정보 전달

구독을 새로고침한 뒤 다시 테스트해 서비스 제공자가 주소, 포트, 전송 매개변수를 변경했는지 확인하세요. 같은 설정이 서로 다른 네트워크에서도 계속 실패한다면 노드 표시 이름, 테스트 시각, 오류 단계, 민감 정보를 가린 로그를 전달해 서버 상태를 확인해 달라고 요청하세요. 인증 정보를 공개하거나 다른 설정의 비밀번호나 식별 정보를 조합해 사용하지 마세요. 코어를 선택할 수 있다고 해서 모든 코어가 같은 확장 매개변수를 해석할 수 있는 것은 아닙니다.

노드가 복구된 뒤에는 연결 테스트만 확인하지 말고 원래 실패했던 실제 작업도 테스트하세요. 핸드셰이크는 성공했지만 특정 사이트만 시간 초과가 발생한다면 해당 사이트의 라우팅, DNS, 대상 서비스 제한을 확인합니다. 프로토콜 필드의 의미는 용어집에서, VMess와 VLESS의 차이는 프로토콜 차이 안내에서 확인할 수 있습니다. 필드의 용도를 이해한 뒤 수정하면 옵션을 반복해서 바꾸는 것보다 안정적인 결과를 얻기 쉽습니다.

구독 실패: 주소·다운로드·파싱을 나누어 확인

구독 업데이트는 클라이언트가 구독 주소로 요청을 보내고, 서버가 본문을 반환하며, 클라이언트가 본문을 설정 목록으로 변환하는 세 단계로 진행됩니다. 어느 단계에서든 실패하면 ‘업데이트 실패’가 표시될 수 있지만 해결 방법은 다릅니다. 먼저 요청이 완료되지 않았는지, 요청은 성공했지만 설정을 인식하지 못했는지 구분하세요. 그룹 이름만 보고 업데이트 성공 여부를 판단하지 말고, 아직 사용할 수 있는 기존 설정을 다시 가져오려고 바로 지우지도 마세요.

주소 저장 후 업데이트 실행

‘구독 그룹 설정’에서 주소가 완전히 저장됐는지 확인한 다음 ‘모든 구독 업데이트’를 실행하세요. 그룹만 추가한다고 노드가 자동으로 생기지는 않습니다. 복사할 때 앞뒤 공백, 줄바꿈, 채팅 앱이 덧붙인 문장 부호가 들어가지 않았는지 확인하세요. 쿼리 매개변수가 있는 주소는 특히 잘리지 않도록 주의해야 합니다. 예시 주소 https://example.com/sub?token=xxxx는 형식을 보여 주기 위한 것입니다. 실제로는 서비스 제공자가 발급한 전용 주소를 사용하세요.

구독 주소와 단일 노드 공유 링크는 서로 다른 입력 방식입니다. 일반 웹페이지 링크나 로그인 후 표시되는 관리 페이지 주소가 구독 API 주소인 것도 아닙니다. 화면 모양만 보고 판단하지 말고 서비스 제공자가 구독 주소로 명확히 안내한 링크를 복사하세요. 주소가 재설정됐다면 이전 링크는 접근 거부나 빈 내용을 반환할 수 있습니다. 이때는 클라이언트의 파싱 옵션을 계속 바꾸지 말고 새 주소로 교체하세요.

요청 실패와 응답 내용 오류 구분

업데이트 로그의 상태와 오류를 확인하세요. 이름 확인에 실패하면 DNS를 점검하고, 연결 시간 초과가 발생하면 현재 네트워크에서 구독 서버까지의 경로를 확인하세요. 인증서 오류는 시스템 시간과 서비스 도메인을 확인해야 합니다. 접근 거부가 표시되면 구독 자격, 주소 만료, 접근 제한을 살펴보세요. 서버가 바쁠 때 업데이트 버튼을 연속해서 누르면 제한이 더 심해질 수 있습니다. 잠시 기다렸다가 다시 시도하고 처음 발생한 오류를 기록해 두세요.

요청에 성공했다고 해서 설정이 반환된 것은 아닙니다. API가 로그인 페이지, 점검 안내, 네트워크 인증 페이지를 반환하면 클라이언트는 이를 설정으로 파싱할 수 없습니다. 응답 내용을 확인해야 한다면 통제된 로컬 환경에서만 작업하고 주소 전체가 공개 기록에 남지 않도록 주의하세요. 브라우저에서 페이지가 열린다는 것은 브라우저가 내용을 받아왔다는 뜻일 뿐입니다. 브라우저와 클라이언트의 프록시, 로그인 상태, DNS 설정이 다를 수 있으므로 요청 경로도 같다고 단정할 수 없습니다.

작동하는 업데이트 경로 선택

현재 직접 연결로 구독 서버에 접근할 수 있다면 우선 직접 연결로 업데이트해 의존성을 줄이세요. 직접 접속할 수 없고 클라이언트에 사용할 수 있는 설정이 남아 있다면 인터페이스의 프록시 경유 업데이트 기능을 사용할 수 있습니다. 메뉴는 인터페이스에 따라 다를 수 있으므로 실제 설정을 확인하세요. 기존 설정이 모두 작동하지 않는 상황에서 프록시 경유 업데이트를 사용하면 연결해야 업데이트할 수 있는데 업데이트해야 연결할 수 있는 의존성 순환이 생깁니다. 이때는 새롭고 유효한 주소나 단일 노드 설정을 받아야 합니다.

업데이트 전에 사용한 경로를 기록하고, 업데이트 후 로그를 확인하세요. 시스템 프록시를 켜면 클라이언트 자체의 구독 요청도 반드시 프록시로 전달된다고 생각하지 마세요. 업데이트 모듈은 별도의 네트워크 경로를 사용할 수 있습니다. 접근할 수 없는 구독 주소를 출처가 불분명한 온라인 변환 서비스에 입력하지도 마세요. 구독에는 접근 자격 정보가 포함될 수 있어 변환 서비스 운영자가 내용을 읽을 수 있습니다. 형식을 변환해야 한다면 수신자, 처리 방식, 자격 정보 노출 범위를 확인하세요.

형식 호환성과 업데이트 후 목록 변경 처리

본문은 비어 있지 않은데 유효한 설정이 없다고 표시된다면, 서비스 제공자가 현재 클라이언트에서 사용할 수 있는 형식으로 제공하는지 먼저 확인하세요. 클라이언트와 코어의 역할은 다릅니다. 클라이언트가 구독을 파싱하고 코어가 변환된 설정을 실행합니다. 코어를 바꾼다고 구독 형식 인식 문제가 해결되는 경우는 드뭅니다. 설치 파일 페이지에서 운영체제에 맞는 클라이언트를 선택한 뒤, 기존 사용 환경을 덮어쓰지 말고 설정을 백업해 별도로 테스트하세요.

업데이트 후 항목이 줄었다면 서비스 제공자가 설정을 제거했거나 그룹 필터가 일부 항목을 숨겼을 수 있습니다. 먼저 목록 필터를 지우고 해당 구독 그룹의 업데이트 결과를 확인하세요. 새 항목이 작동하는 것을 확인한 뒤 오래된 항목을 정리합니다. 문제를 비교해야 한다면 민감 정보를 가린 프로토콜 종류와 오류 정보만 일부 남겨도 됩니다. 인증 정보를 그대로 저장하거나 전달하지 마세요.

속도 저하: 처리량·응답 시간·앱별 차이를 나눠 측정

웹페이지가 느리게 열리는 현상, 동영상 버퍼링, 대용량 파일 다운로드 지연은 같은 문제로 단정할 수 없습니다. 웹페이지는 이름 확인, 핸드셰이크, 여러 리소스 요청의 영향을 받습니다. 연속 다운로드는 처리량과 혼잡의 영향을 더 많이 받고, 실시간 통신은 지터와 패킷 손실도 중요합니다. 먼저 ‘어떤 작업이 느린지’를 구체적으로 정한 뒤 알맞은 테스트를 선택하세요. 목록의 응답 시간은 특정 테스트 조건에서 얻은 값일 뿐 모든 작업의 속도 순위나 서비스 품질을 종합적으로 나타내지 않습니다.

같은 조건으로 비교 기준 만들기

안정적인 대상 하나를 정해 같은 기기와 네트워크에서 비슷한 시간대에 직접 연결과 프록시 연결을 비교하세요. 시스템 업데이트, 클라우드 동기화, 기타 대용량 작업을 일시 중지해 백그라운드 트래픽이 업로드 대역폭을 모두 차지하지 않도록 합니다. 무선 네트워크는 신호 세기, 주파수 대역, 라우터 부하도 확인하세요. 라우터 가까이 있는 컴퓨터라도 무선 간섭이 없다고 단정할 수 없습니다. 가능하다면 유선 연결을 비교 기준으로 삼아 로컬 접속 구간의 변동부터 배제하세요.

한 번에 두 설정만 비교하고 같은 라우팅과 DNS를 유지하세요. 여러 속도 측정 도구를 동시에 실행하거나 한 번의 극단적인 결과로 결론을 내리지 마세요. 측정 과정에서 실제 트래픽이 발생하므로 종량제 서비스를 사용한다면 테스트 규모를 조절해야 합니다. 특정 시간대에 전반적으로 느려졌다가 다른 시간에 회복된다면 반복해서 재설치하기보다 시간대별 패턴을 기록하는 것이 유용합니다. 네트워크 혼잡이나 서버 부하를 추가로 확인해야 할 수 있습니다.

실제 출구와 대상 서비스 확인

느린 요청이 예상한 프록시를 실제로 거치는지 먼저 확인하세요. 라우팅 규칙에 따라 페이지 본문과 리소스 도메인이 서로 다른 출구를 사용해 본문은 열리지만 이미지 로딩은 멈출 수 있습니다. 로그에서 실패한 도메인을 찾아 반복 재시도가 있는지, 특정 리소스가 계속 직접 연결되는지 확인하세요. 페이지가 결국 열리더라도 시간 초과를 무시하지 마세요. 브라우저는 여러 리소스를 기다린 뒤에야 로딩을 완료할 수 있습니다.

특정 사이트만 느리다면 웹사이트 자체, 콘텐츠 전송 노드, 계정 제한도 원인일 수 있습니다. 프록시 출구를 바꾸면 사이트가 할당하는 서비스 노드가 달라질 수 있지만 반드시 개선된다고 보장할 수는 없습니다. 일반 페이지는 빠른데 특정 다운로드 소스만 느리다면 합법적인 다른 다운로드 소스나 같은 사이트의 다른 자료로 먼저 비교하세요. 대상 서버의 속도 제한은 로컬 수신 포트 변경으로 해결되지 않으며, 클라이언트 설정으로 실제 네트워크 대역폭을 넘을 수도 없습니다.

연결 재사용·UDP·경로 문제 확인

다중화는 연결을 구성하는 방식을 바꿀 뿐, 많이 사용할수록 빨라지는 기능은 아닙니다. 서버 호환성, 패킷 손실, 앱 종류에 따라 결과가 달라집니다. 진단할 때는 기본값이나 서비스 제공자가 권장하는 설정을 유지하세요. 다중화가 의심된다면 해당 설정만 끄고 비교합니다. 다른 코어의 매개변수를 현재 코어에 그대로 복사하지 마세요. 같은 이름의 기능도 구현 방식과 사용할 수 있는 필드가 다를 수 있으며, 잘못된 매개변수는 코어 실행 실패를 일으킬 수 있습니다.

브라우저가 UDP 기반 전송을 시도할 수 있지만 현재 경로에서 UDP와 TCP가 다르게 처리될 수 있습니다. 특정 유형의 앱만 문제가 있다면 앱이 지원하는 범위에서 전송 방식을 잠시 바꿔 확인하세요. 시스템 전체의 UDP를 바로 비활성화하지 마세요. TUN을 켠 뒤 일반 페이지는 정상인데 대용량 다운로드가 멈춘다면 경로 MTU 문제일 수도 있습니다. 네트워크 환경에 맞춰 테스트해야 하며, 모든 기기에 고정값 하나를 적용해서는 안 됩니다.

재현 가능한 결과를 바탕으로 최적화

동시 연결 수를 줄였을 때 안정성이 크게 좋아진다면 연결 제한과 혼잡을 먼저 확인하세요. 첫 요청만 느리고 이후 요청은 빨라진다면 DNS와 최초 핸드셰이크를 점검합니다. 화면 잠금이나 절전 모드에서 돌아온 뒤에만 느려진다면 네트워크 어댑터 상태와 클라이언트 재연결을 살펴보세요. 증상마다 확인할 방향이 다릅니다. 대상, 시각, 출구, 전송 방식, 결과를 간단히 기록하면 속도 측정 스크린샷 한 장만 저장하는 것보다 유용합니다.

효과가 확인된 변경만 유지하고 나머지는 원래 값으로 되돌리세요. 네트워크 최적화에 통용되는 만능 설정은 없습니다. 여러 설정을 한꺼번에 바꾸면 비교 기준을 잃게 됩니다. DNS 경로를 더 점검하려면 다음 항목을 확인하세요.

DNS 문제: 누가 어떤 경로로 조회하는지 확인

DNS는 도메인을 IP 주소로 변환하지만 프록시 환경에서는 조회 지점이 하나만 있는 것이 아닙니다. 운영체제, 브라우저, 클라이언트 코어, 원격 프록시가 각각 관여할 수 있습니다. 웹페이지에 도메인을 찾을 수 없다고 표시되면 어느 한 단계에서 사용 가능한 결과를 얻지 못했다는 뜻일 뿐입니다. 먼저 노드 서버 도메인을 확인할 수 없는 경우인지, 대상 사이트 도메인을 확인할 수 없는 경우인지 구분하세요. 전자는 프록시 연결을 막지만 후자는 대개 프록시가 실행된 뒤 나타나므로 같은 방법으로 해결할 수 없습니다.

시스템 DNS와 프록시 측 DNS 비교

Windows 터미널에서 아래 시스템 명령을 사용해 대상 도메인이 응답하는지 확인할 수 있습니다. 예시 도메인은 명령 사용법을 보여 주기 위한 것이므로 실제 오류가 발생한 도메인으로 바꾸세요. 응답한 DNS 서버, 주소 체계, 오류 메시지를 기록합니다. 주소가 한 줄 표시됐다고 조회 경로가 올바르다고 단정하지 마세요. DNS 리졸버마다 다른 콘텐츠 전송 주소를 반환할 수 있습니다.

nslookup example.com

시스템 조회에 성공했다고 코어의 원격 DNS도 성공한다는 뜻은 아닙니다. 시스템 조회가 실패해도 일부 요청은 도메인 이름을 원격으로 전달하므로 프록시 연결이 반드시 실패하는 것은 아닙니다. 이어서 클라이언트 로그에서 DNS 요청과 최종 연결 주소를 확인하세요. 브라우저에서 별도의 보안 DNS를 사용한다면 해당 설정도 기록합니다. 진단 중에는 하나의 명확한 DNS 경로를 임시로 사용해 비교한 뒤 브라우저의 원래 설정을 복구할지 결정하세요.

DNS 조회 경로의 순환 의존 방지

암호화 DNS를 사용할 때는 DNS 서버의 도메인을 먼저 조회하고 연결을 수립한 뒤에야 질의를 보낼 수 있습니다. DNS 서버에 접속하려면 프록시가 필요한데 프록시 서버 도메인은 다시 해당 DNS 서버에 의존한다면 시작 단계에서 순환 의존이 발생합니다. 프록시를 만들기 전에도 필요한 조회를 완료할 수 있도록 노드 도메인의 초기 조회 경로를 명확히 설정하세요. 코어마다 설정 이름과 구조가 다르므로 필드를 서로 섞어 사용하지 마세요.

클라이언트의 로컬 DNS, 원격 DNS, 라우팅 설정이 서로 맞는지 확인하세요. 직접 연결할 대상에 접근할 수 없는 DNS 서버를 사용하거나, 프록시 대상에 현재 네트워크와 맞지 않는 시스템 응답을 사용하면 문제가 생길 수 있습니다. 변경 후 연결을 다시 설정해 테스트하여 이전 캐시가 판단에 영향을 주지 않도록 하세요. 브라우저 캐시만 지워서는 모든 계층의 DNS 결과가 초기화되지 않습니다. 필요하다면 클라이언트와 관련 앱도 다시 시작하세요.

TUN 처리와 로컬 네트워크 이름 이해

TUN은 더 많은 트래픽을 처리할 수 있지만 모든 DNS 요청에 자동으로 같은 정책이 적용되는 것은 아닙니다. DNS 가로채기, 가상 네트워크 어댑터, 앱 제외, 라우팅 규칙이 실제로 적용되는지 확인하세요. 앱이 별도의 암호화 DNS 경로를 사용한다면 일반적인 DNS 가로채기로 처리되지 않을 수 있습니다. TUN 스위치 상태만 보지 말고 로그에서 요청이 코어에 들어왔는지, 어떤 DNS 서버를 사용했는지 확인하세요.

프린터, 파일 서버, 사내 네트워크는 로컬 DNS나 특정 검색 도메인에 의존할 수 있습니다. 모든 DNS 질의를 외부 서버로 보내면 이러한 이름이 조회되지 않을 수 있습니다. 로컬 네트워크와 조직 내부 도메인의 조회 경로를 유지하고 네트워크 관리자의 설정을 따르세요. 사설 IP 주소에 직접 연결 규칙을 설정하는 것만으로는 부족합니다. 내부 도메인이 DNS 조회 단계에서 실패하면 요청이 이후 주소 라우팅 단계에 도달하지 못합니다.

DNS 응답의 정확성과 개인정보 경계를 따로 확인

웹페이지에 정상적으로 접속되는지와 DNS 요청이 예상한 경로를 따르는지는 별개의 점검 항목입니다. 온라인 테스트 페이지는 해당 페이지에서 발생시킨 일부 요청만 보여 줄 뿐 기기의 모든 앱을 대변하지 않습니다. DNS 서버 운영자의 위치도 실제 네트워크 출구와 다를 수 있습니다. 브라우저 설정, 코어 로그, 앱 동작을 함께 확인하세요. 테스트 페이지의 지역 표시 하나만으로 DNS 유출이나 해결 여부를 판단하지 마세요.

수정 후에는 일반 도메인, 기존 오류 도메인, 로컬 네트워크에서 유지해야 하는 이름을 각각 테스트하고 IPv4와 IPv6 결과가 다른지도 확인하세요. 다음에 네트워크를 바꿔도 재현할 수 있도록 변경 전후의 DNS 서버와 출구를 기록합니다. 자세한 점검 단계는 DNS 유출 테스트와 설정 가이드에서 확인할 수 있습니다. 안내된 옵션은 현재 코어와 실제 화면에 맞춰 사용하세요.

시스템 프록시가 작동하지 않을 때: 브라우저와 터미널을 따로 점검

시스템 프록시는 앱이 읽어 사용하는 네트워크 설정이지 모든 트래픽을 강제로 전달하는 기능이 아닙니다. 앱은 시스템 프록시를 따르거나 별도의 프록시를 사용하거나 직접 인터넷에 연결할 수 있습니다. 따라서 브라우저는 되는데 터미널은 안 되는 상황도 발생할 수 있습니다. 먼저 문제가 있는 앱이 어떤 프록시 방식을 사용하는지 확인한 뒤 진입 주소와 포트를 점검하세요. 앱 요청이 실제로 클라이언트에 들어온 후에야 라우팅과 노드 설정이 해당 요청에 영향을 줍니다.

세 가지 시스템 프록시 모드 확인

‘시스템 프록시 자동 설정’은 클라이언트 설정에 따라 시스템 프록시를 지정합니다. ‘시스템 프록시 해제’는 관련 프록시 설정을 제거합니다. ‘시스템 프록시 변경 안 함’은 현재 상태를 클라이언트가 바꾸지 않는다는 뜻이지 프록시를 해제한다는 뜻은 아닙니다. 다른 프로그램이 이미 프록시를 설정했다면 변경 안 함을 선택해도 설정이 남아 있을 수 있습니다. 확인할 때는 클라이언트 메뉴만 보지 말고 운영체제의 네트워크 설정에서 실제 값을 확인하세요.

설정한 뒤 테스트할 앱을 다시 열어 보세요. 일부 프로그램은 시작할 때만 프록시 설정을 읽습니다. 화면에는 전환된 것으로 표시되는데 시스템 값이 바뀌지 않았다면 권한, 조직 정책, 다른 프록시 프로그램의 덮어쓰기를 확인하세요. 관리되는 기기는 조직의 규칙을 따라야 하며 정책을 강제로 수정해서는 안 됩니다. 두 클라이언트가 시스템 프록시를 계속 쓰도록 두면 설정이 예측할 수 없이 바뀌거나 연결이 끊길 수 있습니다.

브라우저 자체 설정과 확장 프로그램 확인

브라우저에서 프록시를 가로채는 확장 프로그램을 끄고 브라우저 자체 네트워크 설정을 확인하세요. 일부 브라우저는 시스템 프록시를 사용하거나 별도의 프록시를 수동으로 지정할 수 있습니다. 오래된 PAC 주소, 수동 프록시, 우회 목록이 트래픽 경로를 바꿀 수 있습니다. 시크릿 창에서는 일부 확장 프로그램과 정책이 계속 적용될 수 있으므로 새 브라우저 프로필을 사용해 비교하는 편이 더 확실합니다.

‘로컬 주소는 프록시 사용 안 함’ 같은 우회 규칙도 확인하세요. 특정 대상이 직접 연결될 수 있습니다. 로컬 네트워크에 접속할 때는 정상적인 동작일 수 있으므로 로그가 없다고 시스템 프록시가 작동하지 않는다고 단정하지 마세요. 프록시 진입점을 테스트하려면 우회 목록에 없는 대상을 선택하세요. 같은 프록시 설정에서도 DNS 결과가 달라질 수 있으므로 브라우저의 별도 DNS 설정도 함께 기록해야 합니다.

터미널에서 프로토콜을 명시해 사용

명령줄 도구마다 시스템 프록시 지원 방식이 다르므로 프록시 매개변수를 지정해 한 번 테스트할 수 있습니다. 아래 예시는 로컬 HTTP 수신 주소가 실제로 127.0.0.1:10809라고 가정합니다. 실행 전에 클라이언트에 표시된 실제 HTTP 또는 혼합 수신 포트로 바꾸세요. 이는 테스트 예시일 뿐 기본 포트를 정하는 규칙이 아닙니다. Windows PowerShell에서 curl.exe를 사용하면 해당 프로그램을 명확히 호출할 수 있습니다.

curl --proxy http://127.0.0.1:10809 --head https://example.com

SOCKS 진입점을 사용한다면 도구에서 지원하는 SOCKS 프록시 매개변수를 선택하세요. socks5h는 보통 도메인 조회를 프록시 측에 맡긴다는 뜻이며, socks5의 로컬 조회 방식은 도구 문서에서 확인해야 합니다. HTTP 프록시 주소를 SOCKS만 허용하는 옵션에 입력하면 안 됩니다. http_proxy, https_proxy, ALL_PROXY, NO_PROXY에 이전 값이 남아 있는지도 확인하세요.

TUN과 로컬 네트워크 공유의 범위 확인

프록시 설정을 읽지 않는 앱은 영향 범위를 이해한 뒤 TUN을 테스트할 수 있습니다. 데스크톱에서는 보통 관리자 권한이나 별도 승인이 필요하며 가상 네트워크 어댑터와 기본 경로도 확인해야 합니다. 라우팅 충돌을 막기 위해 다른 VPN이나 프록시 처리 기능을 먼저 끄세요. 단, 조직에서 유지하도록 요구한 연결은 임의로 끄면 안 됩니다. TUN은 잘못된 노드 매개변수를 수정하지 않으며 시스템 프록시가 실패했을 때 항상 효과적인 대안인 것도 아닙니다.

휴대폰에서 PC의 프록시를 공유해 사용할 때 휴대폰 자체의 루프백 주소를 입력하면 안 됩니다. PC에서 로컬 네트워크 연결을 허용하고 휴대폰에는 PC의 내부 네트워크 주소와 올바른 포트를 입력하세요. 방화벽은 신뢰할 수 있는 필요한 네트워크에만 허용해야 합니다. 자세한 방법은 로컬 네트워크 프록시 공유 가이드를 참고하세요. 브라우저와 터미널을 함께 점검하는 방법은 시스템 프록시 미작동 집중 점검에서 확인할 수 있습니다. 해결한 뒤 테스트용으로 설정한 영구 환경 변수는 제거하세요.

클라이언트 충돌: 인터페이스 종료와 코어 중단 구분

창이 사라진 경우, 프로세스가 종료된 경우, 코어가 중단된 경우는 서로 다른 문제입니다. 먼저 작업 표시줄 알림 영역과 시스템 프로세스 목록을 확인하세요. 창을 닫아도 알림 영역에 숨겨져 있을 수 있습니다. 인터페이스는 열려 있는데 프록시가 멈췄다면 코어 시작 실패일 수 있습니다. 시작, 설정 가져오기, 노드 전환, 절전 모드 복귀 중 언제 문제가 생겼는지 기록하세요. ‘갑자기 꺼짐’이라는 표현보다 문제가 발생한 동작이 실행 환경, 설정 내용, 권한 중 무엇을 확인할지 판단하는 데 더 도움이 됩니다.

데이터를 먼저 저장하고 별도 환경에서 테스트

인터페이스를 열 수 있다면 클라이언트의 내보내기 또는 백업 기능으로 구독 그룹과 필요한 설정을 안전하게 저장하세요. 열리지 않는다면 처리에 앞서 기존 사용자 데이터부터 복사하고 전체 폴더를 바로 삭제하지 마세요. 설정에 인증 정보가 포함될 수 있으므로 백업은 안전한 위치에 보관해야 합니다. 이전하거나 테스트할 때 쓰는 중인 데이터 폴더를 여러 인스턴스에서 동시에 사용하지 마세요. 파일이 잠기거나 내용이 충돌할 수 있습니다.

설치 파일 페이지에서 운영체제와 프로세서 아키텍처에 맞는 패키지를 선택하세요. Windows 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하며 WPF 버전은 기존 인터페이스를 유지합니다. 두 버전은 인터페이스 호환성을 비교하는 데 사용할 수 있지만 노드 매개변수도 바뀌었다고 단정할 수는 없습니다. 별도 테스트 환경을 만들 때는 이전 설정을 모두 가져오지 말고, 작동이 확인된 설정 하나만 추가해 기본 실행이 정상인지 확인한 다음 다른 항목을 하나씩 복원하세요.

시스템 실행 조건과 파일 권한 확인

시작 전에 디스크 공간이 충분하고 사용자 디렉터리에 쓸 수 있는지 확인하세요. 시스템에서 필요한 실행 구성 요소를 안내하면 설치를 완료합니다. 설치 폴더를 읽을 수 있어도 로그, 캐시, 사용자 설정 폴더에 쓸 수 있는 것은 아닙니다. 로그에 권한 거부가 표시되면 해당 경로를 찾아 해결하세요. 디스크 전체의 권한을 완화하지 마세요. 보안 프로그램이 파일을 격리했다면 경고 원인과 파일 출처를 먼저 확인하고 모든 보호 기능을 끄는 방식으로 장기 해결하려 하지 마세요.

Linux 데스크톱에서 실행에 실패하면 터미널에서 설치된 시작 명령을 실행해 누락된 라이브러리, 그래픽 세션, 권한 관련 메시지를 확인할 수 있습니다. 실제 명령은 해당 기기의 설치 경로에 따라 다르므로 바이너리 경로를 추측하지 마세요. macOS의 실행 경고는 시스템의 정상적인 앱 승인 절차를 따라 처리하고 시스템 보호 기능 전체를 끄지 마세요. 플랫폼 설치 방법은 Linux 설치 및 자동 시작 안내에서 확인할 수 있습니다. 자동 시작을 설정하기 전에 수동 실행부터 해결하세요.

첫 오류부터 코어 문제 확인

인터페이스는 열리지만 코어가 바로 종료된다면 설정 파싱 오류부터 확인하세요. 오류에는 필드 이름이나 문제가 발생한 위치가 포함될 수 있으며, 호환되지 않는 매개변수, 불완전하게 가져온 내용, 잘못된 사용자 설정이 원인일 수 있습니다. 최근에 변경한 항목을 하나씩 원래대로 돌린 뒤 코어를 다시 시작하세요. Project V, V2Fly, Xray는 관련 생태계에 속하지만 설정 구조와 확장 기능은 완전히 같지 않습니다. 임의의 설정 조각을 모든 코어에서 그대로 사용할 수 있다고 가정하지 마세요.

포트 충돌, 리소스 파일 읽기 실패, 권한 부족도 코어 종료의 원인이 될 수 있습니다. 포트 충돌이 발생하면 중복 실행을 종료하거나 수신 포트를 변경하세요. 리소스 파일 오류가 나타나면 앱 설치가 완료됐는지, 경로를 읽을 수 있는지, 내장 업데이트가 정상적으로 끝났는지 확인합니다. 출처가 불분명한 파일을 조합해 코어를 구성하지 마세요. TUN 오류는 우선 TUN을 끄고 일반 프록시가 실행되는지 확인한 뒤 권한과 가상 네트워크 어댑터를 별도로 점검하세요.

순서대로 복원해 문제 재발 방지

별도 환경이 정상 작동하면 구독, 라우팅, 사용자 지정 DNS, TUN을 차례로 복원하세요. 각 단계를 마친 뒤 재시작하고 테스트합니다. 특정 설정 그룹을 가져온 뒤 문제가 재발하면 재설치를 반복하지 말고 해당 설정과 기본 환경의 차이를 비교하세요. 데이터베이스 사용 중 또는 설정 손상 메시지가 표시되면 원본 백업을 보존하고 앱이 지원하는 복구 방법을 우선 사용하세요. 구조를 모른 채 데이터 파일을 직접 수정하지 마세요.

문제가 시작 시 자동 실행할 때만 발생한다면 네트워크 준비 전 실행되는지, 작업 디렉터리가 다른지, 권한 환경이 다른지 확인하세요. 절전 모드에서 돌아온 뒤에만 발생한다면 네트워크가 복구될 때까지 기다린 다음 코어를 재시작합니다. 문제를 문의할 때는 시스템 아키텍처, 패키지 종류, 재현 단계, 민감 정보를 가린 오류 일부를 제공하세요. 설정 전체를 공개할 필요는 없습니다. 사용이 복구된 뒤 시스템 프록시가 유효한 수신 주소를 가리키는지 확인하세요. 인터페이스는 종료됐는데 앱이 존재하지 않는 로컬 진입점에 계속 접속하는 상황을 방지할 수 있습니다.

Android 문제 해결: 권한·앱 분할·백그라운드 연결 끊김

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 선택하고, V2Fly 코어를 사용하는 v2flyNG는 대안으로 사용할 수 있습니다. 두 앱의 인터페이스와 매개변수 지원은 다를 수 있으므로 앱을 바꾼다고 설정 문제가 자동으로 해결되지는 않습니다. 기기 운영체제, 클라이언트 이름, 연결 방식, 문제가 발생하는 상황을 먼저 기록한 뒤 처음부터 연결되지 않는지, 특정 앱만 실패하는지, 화면이 꺼진 뒤 연결이 끊기는지 구분하세요. 증상에 따라 확인할 경로가 다릅니다.

시스템 권한과 단일 네트워크 처리 앱 확인

처음 연결할 때 시스템 안내에 따라 VPN 연결 권한을 허용하세요. 권한 요청 창이 나타나지 않거나 거부했다면 시스템의 관련 설정으로 돌아가 확인한 뒤 다시 연결을 시도합니다. Android에서는 일반 앱 여러 개가 같은 사용자 환경에서 이 연결을 동시에 각각 차지할 수 없는 경우가 많으므로 다른 네트워크 처리 도구가 실행 중인지 확인하세요. 업무 프로필과 기기 관리 정책에 따라 사용할 수 있는 범위가 달라질 수 있으므로 관리 규칙을 따르세요.

시스템에 연결 표시가 나타나도 해당 네트워크 서비스가 설정됐다는 뜻일 뿐, 원격 노드가 작동한다는 보장은 없습니다. 클라이언트 로그를 열고 명확한 대상에 접속해 요청이 기록되는지, 원격 핸드셰이크가 성공하는지 확인하세요. 모든 앱이 실패하면 로컬 네트워크와 활성 설정부터 테스트합니다. 특정 앱만 실패한다면 모든 데이터를 바로 초기화하지 말고 앱 분할, 별도 DNS, 앱 자체 프록시 설정을 먼저 확인하세요.

화면 꺼짐·백그라운드·네트워크 전환 문제 해결

화면이 켜져 있을 때는 연결되지만 화면을 끈 뒤 끊긴다면 시스템의 배터리 최적화, 백그라운드 실행 제한, 기기 제조사의 앱 관리 규칙을 확인하세요. 계속 연결해야 하는 클라이언트는 시스템에서 제공하는 방법으로 필요한 백그라운드 실행을 허용한 뒤 알림과 프로세스가 종료되는지 관찰합니다. 기기마다 메뉴 이름이 다르므로 특정 경로를 그대로 따라 하지 마세요. 백그라운드 제한을 완화하면 배터리가 더 빨리 소모될 수 있으므로 지속적인 연결이 필요한 앱에만 적용하세요.

무선 네트워크에서 모바일 네트워크로 전환하면 기존 연결을 다시 설정해야 할 수 있습니다. 먼저 새 네트워크에서 IP 주소를 받을 때까지 기다린 뒤 클라이언트 연결을 중지했다가 다시 시작하세요. 한 종류의 네트워크에서만 실패한다면 바로 프로토콜을 바꾸지 말고 DNS, 주소 체계, 네트워크 인증을 비교합니다. ‘항상 켜기’를 사용하거나 VPN 미사용 트래픽을 차단하면 노드를 사용할 수 없을 때 기기 전체가 오프라인처럼 보일 수 있습니다. 진단 중 설정을 바꾸기 전에 해당 정책의 작동 방식을 이해하세요.

앱 분할과 DNS 조회 범위 확인

앱 분할에는 선택한 앱만 프록시를 사용하도록 하는 방식과 선택한 앱을 우회하도록 하는 방식이 있습니다. 앱 목록이 같아도 모드가 반대면 결과가 완전히 달라집니다. 현재 모드를 확인한 뒤 대상 앱이 선택됐는지 살펴보고 필요하다면 연결을 다시 설정하세요. 앱 업데이트, 업무 프로필의 복제 앱, 다른 출처에서 설치한 앱은 서로 다른 앱 식별자를 사용할 수 있습니다. 아이콘이 같다는 이유만으로 규칙이 적용됐다고 판단하지 마세요.

웹페이지는 정상인데 특정 앱이 계속 실패한다면 해당 앱이 UDP에 의존하는지, 별도의 암호화 DNS를 사용하는지, 대상 서비스 제한을 받는지 확인하세요. Android의 비공개 DNS와 클라이언트 DNS 설정이 함께 조회에 영향을 줄 수 있으므로 한 번에 하나씩 바꿔 비교합니다. 로컬 네트워크 기기 검색이 안 되면 사설 네트워크 직접 연결 규칙과 로컬 이름 조회도 확인하세요. 트래픽을 프록시에서 우회한다고 모든 브로드캐스트 기기 검색 기능이 자동으로 복구되는 것은 아닙니다.

설치 파일·구독·복구 확인

Android 설치 파일 페이지에서 기기 아키텍처에 맞는 패키지를 선택하세요. 비교적 최신 기기는 대체로 arm64를 사용하지만 실제 기기 아키텍처를 확인하는 것이 가장 정확합니다. 확인하기 어렵다면 시스템 정보를 살펴보거나 페이지에서 제공하는 범용 버전을 사용하세요. 설치 실패 원인은 운영체제 호환성, 저장 공간 부족, 앱 서명 차이, 다운그레이드 제한일 수도 있습니다. 같은 파일을 반복해서 다운로드하는 것만으로 해결되지 않습니다. 기존 앱을 교체하기 전에 설정을 백업해 구독과 앱 분할 규칙이 삭제되지 않도록 하세요.

구독 업데이트가 실패하면 이 페이지의 주소·요청·파싱 세 단계 점검을 따르세요. 클립보드 권한 문제와 서버 응답 오류를 혼동하지 마세요. 복구한 뒤에는 앱 사용 중, 화면 꺼짐 후 다시 켠 경우, 무선·모바일 네트워크 전환을 각각 테스트하고 프록시가 필요한 앱과 직접 연결해야 하는 앱이 모두 예상대로 동작하는지 확인합니다. 효과가 있었던 설정만 기록하고 테스트용 임시 규칙은 되돌리세요. 이후 기본 사용 방법은 빠른 시작 가이드에서, 개념 관련 질문은 자주 묻는 질문에서 확인할 수 있습니다.