V2Ray 문제 해결

인터넷에 연결되지 않음

“클라이언트가 실행 중”이라는 것은 그래픽 인터페이스가 열려 있다는 뜻일 뿐, 코어와 서버 연결, 앱 프록시가 모두 작동한다는 의미는 아닙니다. 먼저 문제 범위를 세 가지로 나누세요. 프록시를 꺼도 인터넷이 안 되는 경우, 프록시를 켰을 때만 인터넷이 안 되는 경우, 특정 앱이나 웹사이트만 문제가 있는 경우입니다. 각각 점검할 지점이 다릅니다. 프로토콜을 바꾸거나 앱을 반복해서 재설치해도 원인을 좁히기 어렵고, 정상 작동하던 설정을 덮어쓸 수 있습니다.

기본 네트워크와 문제 범위부터 확인

v2rayN 트레이 메뉴에서 시스템 프록시를 해제하고 클라이언트를 종료한 뒤, 브라우저에서 평소 직접 접속할 수 있는 웹사이트를 여세요. Wi-Fi 연결과 게이트웨이 접근 상태를 확인하고, 공용 네트워크라면 로그인 인증을 마쳤는지도 점검하세요. 이 상태에서도 인터넷에 연결되지 않으면 먼저 시스템 네트워크, 라우터 또는 상위 네트워크 문제를 해결해야 합니다. Android에서는 VPN을 먼저 중지하고 Wi-Fi와 모바일 데이터를 테스트하세요. 기본 네트워크 연결 문제를 구독 오류로 오해하지 마세요.

기본 네트워크가 정상이라면 클라이언트를 다시 시작하고 현재 유효한 서버 하나만 선택해 테스트하세요. 프록시 클라이언트를 두 개 동시에 실행하거나, 데스크톱 시스템 프록시와 다른 도구의 가상 네트워크 어댑터 연결을 함께 사용하지 마세요. 연결 경로가 여러 개면 요청이 서로 다른 경로로 들어가 브라우저만 열리고 다른 앱은 시간 초과가 발생하거나, 프로그램 하나를 종료한 뒤 시스템 전체가 갑자기 정상으로 돌아올 수 있습니다.

코어, 로컬 리스닝 및 앱 연결 확인

클라이언트 로그에서 코어가 정상적으로 시작했는지 먼저 확인한 다음, 접속을 시도할 때 새 로그가 남는지 살펴보세요. 설정 파싱 실패, 주소 바인딩 실패 또는 포트 사용 중 오류가 있으면 로컬 실행 문제부터 해결해야 합니다. 이 상태에서는 원격 서버를 테스트해도 의미가 없습니다. 코어는 정상인데 웹페이지를 열어도 관련 로그가 전혀 없다면 앱이 시스템 프록시를 사용하는지, 별도의 프록시가 설정되어 있는지, 현재 리스닝 포트가 일치하는지 확인하세요.

아래 Windows 예시는 로컬 HTTP 프록시를 직접 지정해 브라우저 설정을 테스트에서 제외합니다. 예시 포트는 10808입니다. 실행 전에 매개변수 설정에서 실제로 활성화된 HTTP 또는 혼합 리스닝 포트를 확인하세요. 해당 포트가 SOCKS만 지원한다면 알맞은 프로토콜로 바꿔야 합니다. 대상 주소는 표준 예시 도메인일 뿐이며 모든 네트워크에서 접속할 수 있다는 뜻은 아닙니다.

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

로컬 주소에 연결할 수 없다는 메시지가 나오면 리스닝이 활성화되어 있는지 확인하세요. 로컬 프록시에 연결된 뒤 원격 연결 시간 초과가 발생하면 서버 시간 초과 문제 해결 항목으로 이동하세요. 대상 사이트의 HTTP 응답을 받았다면 접근 거부나 허용되지 않는 요청 방식이라도 해당 요청이 응답 측에 도달했다는 뜻입니다. 다만 모든 웹사이트나 프로토콜이 정상이라는 뜻은 아닙니다. 명령 종료 코드만으로 전체 연결 경로를 판단하지 마세요.

라우팅 문제와 연결 문제를 구분

로컬 프록시 테스트에서는 응답을 받지만 브라우저에서 접속할 수 없다면 브라우저 프록시 확장 프로그램, 시스템 프록시, 보안 소프트웨어의 네트워크 필터를 확인하세요. 일부 도메인만 문제가 있다면 해당 도메인이 직접 연결 규칙과 프록시 규칙 중 어디에 해당하는지 확인한 뒤 DNS를 점검하세요. 비교를 위해 프록시 라우팅을 명시적으로 선택해 테스트하고, 끝나면 기존 규칙으로 되돌리세요. DNS, 라우팅, 서버를 한꺼번에 변경하면 어떤 변경이 효과가 있었는지 확인할 수 없습니다.

마지막으로 전체 경로를 다시 테스트하세요. 직접 연결은 정상인지, 로컬 프록시가 응답하는지, 브라우저가 예상대로 연결되는지, 대상 도메인이 올바른 출구를 사용하는지 확인합니다. 어느 단계에서 실패하는지 기록한 다음 해당 항목으로 이동하세요. 특정 웹사이트에서 계정 제한, 지역 제한 또는 서비스 오류가 발생한다면 사이트의 응답 내용을 기준으로 처리해야 합니다. 클라이언트가 인터넷에 전혀 연결되지 않는 문제와는 다르므로, 실제 원인을 감추려고 설정을 계속 바꾸지 마세요.

서버 연결 시간 초과

시간 초과는 특정 단계가 제한 시간 안에 완료되지 않았다는 뜻이지, 서버가 반드시 오프라인이라는 의미는 아닙니다. 클라이언트는 도메인 조회, TCP 연결, 보안 핸드셰이크 또는 테스트 대상의 응답을 기다리는 중일 수 있습니다. 먼저 같은 시간대의 로그를 저장하고 가장 먼저 나타난 오류를 찾은 뒤, 이어지는 오류를 확인하세요. 마지막에 표시되는 일반적인 시간 초과는 결과일 뿐인 경우가 많습니다. 앞서 발생한 조회 실패나 핸드셰이크 오류가 원인을 찾는 단서입니다.

테스트 종류와 실패 단계 구분

Tcping은 보통 서버 주소와 포트의 TCP 연결 여부만 테스트하며 인증 정보, 전송 계층 설정 또는 대상 웹사이트 접속까지 검증하지는 않습니다. 실제 연결 지연 시간은 프록시 경로를 거쳐 테스트 주소에 요청하므로 테스트 대상의 상태에도 영향을 받습니다. 따라서 Tcping 결과가 있어도 웹페이지가 열리지 않을 수 있습니다. 반대로 서버가 일반 ICMP 요청에 응답하지 않는다는 이유만으로 프록시를 사용할 수 없다고 판단해서는 안 됩니다.

서버 항목이 오래전에 복사한 독립 항목이 아니라 현재 구독에서 가져온 것인지 먼저 확인하세요. 주소, 포트, 프로토콜이 올바르게 입력되었는지 확인하고, 이름이 같은 다른 그룹의 항목을 잘못 선택하지 않았는지도 살펴보세요. 최근 서버 매개변수가 변경되었다면 구독을 다시 업데이트하거나 전체 매개변수로 항목을 새로 구성하세요. 주소만 바꾸고 기존 전송 설정을 그대로 사용하지 마세요. 테스트의 한계에 대한 자세한 설명은 지연 시간 테스트 원리를 참고하세요.

로그 유형에 따라 매개변수 확인

TLS를 사용할 때 서버 주소와 핸드셰이크에 사용하는 서비스 이름은 서로 다를 수 있습니다. 화면의 주소 필드를 모든 이름 필드에 그대로 복사하지 마세요. 시스템 날짜, 시간, 시간대를 확인하세요. 시간 차이가 있으면 인증서 유효성을 잘못 판단할 수 있습니다. 인증서 오류가 발생하면 설정 출처와 서버 인증서를 확인하고, 검증 건너뛰기를 바로 활성화하지 마세요. 연결이 복구된 것처럼 보여도 잘못된 인증 설정이 남을 수 있습니다.

REALITY를 사용할 때는 서버에서 요구하는 공개 키, 짧은 ID, 서버 이름 및 관련 흐름 제어 설정을 한꺼번에 확인하세요. 공백, 불완전한 복사 또는 다른 서버의 매개변수 사용으로 인해 하위 포트에는 연결되지만 핸드셰이크가 실패할 수 있습니다. 필수 항목은 서버 설정에 따라 다르므로 다른 항목을 보고 임의로 값을 추가하지 마세요. 기본 개념은 REALITY 용어 설명을 참고하세요.

통제된 비교 테스트로 네트워크 범위 좁히기

같은 항목이 Wi-Fi에서는 실패하고 모바일 데이터에서는 정상이라면 클라이언트를 바로 재설치하기보다 네트워크 경로, 조회 결과, 게이트웨이 정책을 먼저 비교해야 합니다. 테스트마다 서버, 프로토콜, 대상 주소를 동일하게 유지하세요. 네트워크를 바꾼 뒤에는 다시 연결해 이전 경로를 사용하는 기존 연결을 피하세요. 모든 항목이 동시에 작동하지 않는다면 로컬 방화벽의 앱 규칙이 최근 변경되었는지도 확인하세요.

같은 그룹의 다른 서버는 정상인데 서버 하나만 계속 실패한다면 단일 항목 설정이나 서버 측 문제일 가능성이 큽니다. 구독을 업데이트한 뒤 오류 발생 시각, 실패 단계, 민감 정보를 가린 로그를 설정 제공자에게 전달하세요. 구독 주소 전체를 보내거나 인증 정보를 공개하지 마세요. 코어 호환성을 비교해야 한다면 먼저 코어 선택 가이드를 읽으세요. 코어 교체를 모든 시간 초과 문제의 만능 해결책으로 여기면 안 됩니다.

시간 제한을 늘리면 응답이 느린지 확인할 수는 있지만, 잘못된 주소, 리스닝하지 않는 포트, 핸드셰이크 매개변수 불일치를 해결하지는 못합니다. 설정을 변경할 때마다 같은 테스트 대상으로 다시 확인하고 이전 결과도 남겨 두세요. 로그에 프록시 연결은 완료됐지만 테스트 사이트가 응답하지 않는다고 표시되면, 명확히 사용 가능한 다른 테스트 대상으로 교차 확인하세요. 테스트 서비스 장애를 서버 전체의 문제로 오해하지 않도록 주의해야 합니다.

구독 업데이트 실패

구독 업데이트는 콘텐츠 다운로드, 형식 파싱, 그룹에 항목 저장의 세 단계로 이루어집니다. 업데이트 실패는 주소에 접근할 수 없는 경우일 수도 있고, 콘텐츠를 다운로드했지만 로그인 페이지, 오류 페이지 또는 호환되지 않는 설정 형식이 반환된 경우일 수도 있습니다. 먼저 기존 항목을 보존하고 그룹 전체를 바로 삭제하지 마세요. 기존 서버를 계속 사용할 수 있다면 삭제 후 다시 만드는 과정에서 이후 문제 해결에 필요한 연결 경로를 잃을 수 있습니다.

주소 및 그룹 설정 확인

구독 그룹 설정을 열어 주소가 설명 문구, 따옴표, 줄바꿈, 뒤쪽 공백 없이 한 줄로 완전하게 입력되었는지 확인하세요. 구독 주소에는 개인 접근 정보가 포함되는 경우가 많으므로 비밀번호처럼 취급해야 합니다. 공개 스크린샷이나 온라인 변환 사이트에 입력하지 마세요. 확인할 때는 주소 형식만 살펴보고, 다른 사람에게 판단을 부탁하려고 원문을 그대로 보내지 마세요. 도움이 필요하면 응답 상태와 오류 유형만 설명하면 됩니다.

업데이트하는 그룹이 현재 확인 중인 그룹과 같은지 점검하세요. 이름이 같은 그룹이 여러 개면 업데이트 후에도 바뀐 것이 없다고 착각하기 쉽습니다. 용도를 구분할 수 있도록 이름을 바꾼 다음 하나씩 업데이트해 보세요. 클라이언트에 활성화 스위치, 업데이트 주소 또는 필터 옵션이 있다면 그룹이 비활성화되지 않았는지, 필터 조건이 모든 항목을 제외하지 않는지도 확인하세요. 그룹이 비어 있다고 해서 네트워크 요청이 실패한 것은 아닙니다.

직접 연결과 프록시 연결로 각각 업데이트

일부 구독 주소는 현재 기본 네트워크에서 직접 접속할 수 있지만 기존 프록시 연결이 필요한 주소도 있습니다. 클라이언트에서 제공하는 업데이트 방법을 각각 테스트하고, 두 테스트에서 요청 경로만 바꾸세요. 프록시를 통한 업데이트를 선택하려면 먼저 작동하는 서버가 있어야 합니다. 기존 프록시가 이미 작동하지 않는데 그 프록시로 구독을 업데이트하려 하면 스스로 복구할 수 없는 순환 문제가 생깁니다.

브라우저에서는 주소가 열리는데 클라이언트에서 실패한다고 해서 클라이언트 오류라고 단정하지 마세요. 브라우저에 로그인 쿠키가 저장되어 있거나 독립 프록시를 사용하거나 인증 페이지로 자동 이동했을 수 있습니다. 클라이언트 요청은 보통 이런 상태를 이어받지 않습니다. 해당 주소가 서비스 제공자가 클라이언트용 구독 주소로 안내한 것인지 확인하세요. 로그인 상호작용이 필요한 웹페이지는 클라이언트가 읽을 수 있는 구독 응답과 다릅니다.

응답 상태를 확인할 수 있다면 인증 실패 시 유효한 주소를 다시 받아야 하는 경우가 많습니다. 요청이 너무 잦다는 메시지가 나오면 연속 새로고침을 중지하고 서비스 제공자의 안내에 따라 잠시 후 다시 시도하세요. 서버 오류는 같은 시간대의 다른 접속 결과와 함께 판단해야 합니다. 모든 상태를 클라이언트 버전이 오래된 탓으로 돌리거나 브라우저 확장 프로그램으로 계속 재시도하지 마세요. 서버 접근 제한이 더 심해질 수 있습니다.

형식 및 저장 결과 확인

일반적인 구독 콘텐츠에는 줄 단위 공유 링크, 인코딩된 링크 모음, 특정 코어용 네이티브 JSON이 있습니다. 파일 확장자나 URL 접미사만으로 형식이 올바른지 판단할 수 없으며 구독 API가 요청에 따라 다른 콘텐츠를 반환할 수도 있습니다. 네이티브 설정을 받았다면 클라이언트에 맞는 설정 가져오기 기능을 사용하세요. 모든 JSON을 일반 구독 그룹으로 업데이트할 수 있다고 가정하면 안 됩니다. 자세한 내용은 구독 형식 및 변환 안내를 참고하세요.

업데이트 성공 메시지가 나왔는데 서버가 보이지 않는다면 먼저 “전체”로 전환하거나 목록 검색 조건을 지운 뒤 구독 필터 표현식, 항목의 프로토콜 지원 여부, 로그의 파싱 메시지를 확인하세요. 단일 서버 공유 링크와 반복 업데이트할 수 있는 구독 주소는 서로 다른 리소스입니다. 링크처럼 보인다는 이유만으로 구독 주소 입력란에 넣지 마세요. 단일 공유 링크는 개별 설정을 가져올 때 사용합니다. 자세한 차이는 공유 링크와 구독 주소를 참고하세요.

주소가 만료되었거나 서비스 제공자가 교체한 것이 확인되면 기존 그룹에서 주소를 업데이트하고 다시 업데이트해 항목이 바뀌는지 살펴보세요. 비교를 위해 새 그룹을 만들더라도 새 항목의 연결을 확인할 때까지 기존 그룹을 유지하세요. 두 그룹이 동시에 자동 업데이트되면 혼란이 생길 수 있습니다. 문제가 해결되면 임시 필터와 중복 그룹을 정리하고 적절한 업데이트 주기로 되돌린 뒤, 최근 정상 설정을 안전하게 백업해 두세요.

연결은 되지만 속도가 느림

속도 저하를 진단하기 전에 느린 상황이 무엇인지 구체적으로 파악하세요. 웹페이지 첫 로딩이 느린지, 파일 다운로드가 계속 느린지, 동영상이 간헐적으로 멈추는지, 특정 앱만 반응이 느린지 구분해야 합니다. 첫 로딩에는 조회, 연결, 핸드셰이크가 영향을 주고, 지속 전송에는 대역폭, 패킷 손실, 혼잡, 서버 부하가 더 큰 영향을 줍니다. 이런 현상을 한데 묶으면 지연 시간이 낮으면 다운로드도 빠르다는 잘못된 결론을 내리기 쉽고, 웹사이트 자체의 속도 제한을 클라이언트 탓으로 돌릴 수도 있습니다.

재현 가능한 비교 조건 마련

테스트할 때 기기, 네트워크, 서버, 대상 사이트를 동일하게 유지하고 시스템 업데이트, 클라우드 동기화, 기타 대용량 작업을 일시 중지하세요. Wi-Fi 신호가 약하거나 같은 대역이 혼잡하다면 라우터 가까이에서 테스트하거나 유선 연결과 비교하세요. 직접 연결에서도 비슷한 리소스가 느리다면 로컬 네트워크부터 점검하세요. 프록시를 통할 때만 눈에 띄게 느려진다면 프록시 경로를 확인하면 됩니다. 날짜와 리소스가 다른 결과는 같은 조건의 비교 자료가 아닙니다.

모든 서버에서 다운로드 속도 테스트를 동시에 실행하지 마세요. 병렬 테스트는 로컬 대역폭을 나눠 쓰고 서버 부하를 높이며, 원래 안정적인 연결도 불안정해 보이게 할 수 있습니다. 후보를 몇 개만 선택해 같은 순서로 하나씩 테스트하고, 테스트 사이에는 회복 시간을 두세요. 시작 시각, 네트워크 종류, 리소스 출처만 기록해도 충분합니다. 순간적으로 나온 최고 속도를 장기적으로 사용할 수 있는 성능으로 여기지 마세요.

연결 수립과 지속 전송을 따로 확인

모든 웹페이지의 첫 로딩만 느리고 이후 이미지와 파일은 정상적으로 불러온다면 DNS, 핸드셰이크, 연결 재사용, 라우팅 규칙을 중점적으로 살펴보세요. 시작은 빠르지만 다운로드 속도가 점점 떨어진다면 Wi-Fi 안정성, 장시간 연결 품질, 원격 속도 제한을 비교해야 합니다. 브라우저 개발자 도구의 대기 단계가 판단에 도움이 될 수 있지만 캐시, 사이트 스크립트, 외부 리소스가 결과에 영향을 줍니다. 먼저 구성이 단순한 페이지로 비교하세요.

Tcping은 비교적 초기 단계의 연결 특성을 측정하고, 실제 연결 지연 시간에는 더 많은 프록시 과정이 포함되며, 다운로드 테스트는 지속적인 트래픽을 발생시킵니다. 이 세 가지는 서로 대체할 수 없습니다. 지연 시간이 긴 서버라도 지속 처리량은 더 안정적일 수 있고, 연결 수립이 빠른 서버라도 혼잡 시간대에는 전송이 제한될 수 있습니다. 서버를 선택할 때는 숫자 하나로 정렬하기보다 실제 앱 사용 환경을 기준으로 판단하세요.

분할 라우팅, 중복 연결 및 전송 설정 확인

일부 리소스만 느리다면 메인 페이지와 이미지·동영상 리소스가 서로 다른 라우팅 규칙을 적용받는지 확인하세요. 웹페이지는 여러 도메인에 동시에 접속할 수 있으며 일부는 프록시를, 나머지는 직접 연결을 사용할 수 있습니다. 인터페이스에 연결됨으로 표시되어도 페이지 전체가 같은 출구를 사용한다는 뜻은 아닙니다. 임시로 통일된 라우팅을 적용해 비교하면 원인을 찾는 데 도움이 됩니다. 확인 후 규칙 순서를 바로잡고, 모든 트래픽을 덮어쓰는 임시 규칙에 계속 의존하지 마세요.

시스템 프록시와 가상 네트워크 어댑터 연결을 동시에 사용하는 경우 코어 자체의 아웃바운드가 다시 프록시로 들어가지 않는지 확인하세요. 중복 연결, 잘못된 상위 프록시 또는 체인 설정은 왕복 횟수를 늘리거나 심하면 루프를 만들 수 있습니다. 속도 테스트를 위해 모든 모드를 동시에 켜지 마세요. 일반적인 브라우저 테스트에는 명확한 단일 연결 경로를 사용하세요. 시스템 프록시를 따르지 않는 앱이 꼭 필요할 때만 가상 네트워크 어댑터 모드를 따로 검증하세요.

전송 계층 매개변수는 서버 설정과 맞아야 합니다. 다중 경로를 임의로 활성화하거나 전송 프로토콜을 바꾸고 다른 사람의 연결 매개변수를 적용해도 대역폭이 자동으로 늘지 않습니다. 오히려 호환성 문제가 생길 수 있습니다. 경로의 패킷 크기에 문제가 있다고 의심된다면 구체적인 증상과 네트워크 환경에 맞춰 단계별로 테스트하고 기존 값을 기록한 뒤 한 번에 하나만 변경하세요. 근거 없이 시스템 네트워크 최적화 설정을 통째로 복사하지 마세요.

마지막으로 조정 가능한 항목과 외부 제한을 구분하세요. 클라이언트는 잘못된 라우팅, 조회, 연결 방식을 바로잡을 수 있지만 서버 부하, 대상 사이트 정책, 상위 네트워크 상태가 항상 같도록 보장할 수는 없습니다. 조건을 통제해 여러 번 테스트한 결과가 계속 같은 원격 경로를 가리킨다면 시간대와 증상을 설정 제공자에게 전달하세요. 모든 임시 테스트 설정을 복구한 뒤 속도 테스트를 계속 실행하는 대신 평소 사용하는 앱으로 안정성을 확인하세요.

DNS 및 도메인 조회

DNS 문제는 도메인이 열리지 않거나 같은 서비스가 되다 안 되다 하거나, 연결 전에 이름 조회 실패 로그가 남는 형태로 나타날 수 있습니다. 서버 도메인 조회와 대상 웹사이트 도메인 조회는 구분해야 합니다. 전자는 클라이언트가 프록시 서버를 찾는 데 필요하고, 후자는 요청이 대상 사이트에 도달하는 방식을 결정합니다. 두 조회는 서로 다른 리졸버와 라우팅을 사용할 수 있으므로 시스템 DNS 하나만 바꾸고 모든 단계가 달라졌다고 생각하면 안 됩니다.

어느 단계에서 조회되는지 먼저 확인

서버 주소에 도메인을 입력했다면 연결이 시작되기 전에 사용할 수 있는 IP 주소를 얻어야 합니다. 이 단계의 조회 경로 자체가 프록시 연결을 요구한다면 시작 단계에서 순환 의존성이 생길 수 있습니다. 먼저 기본 네트워크에서 서버 도메인을 조회할 수 있는지 확인한 다음 클라이언트 DNS 설정의 초기 조회 경로를 살펴보세요. 서버 도메인을 임의로 검색한 IP 주소로 바꾸지 마세요. 서버가 동적 주소를 사용하거나 올바른 핸드셰이크 이름을 필요로 할 수 있습니다.

대상 도메인은 앱, 로컬 시스템 또는 프록시 코어에서 조회될 수 있으며 앱의 프록시 프로토콜과 클라이언트 설정에 따라 달라집니다. SOCKS 요청도 로컬에서 조회할지 프록시에 조회를 맡길지 선택할 수 있으므로 브라우저가 열린다고 해서 명령줄도 같은 방식을 사용한다고 볼 수는 없습니다. 문제를 진단할 때 HTTP 프록시, SOCKS 프록시, 가상 네트워크 어댑터 중 무엇을 사용하는지 기록하고 로그에서 어느 단계에서 이름이 주소로 변환되는지 확인하세요.

시스템 명령으로 기본 조회가 결과를 반환하는지 확인할 수 있지만, 이는 시스템 조회 경로만 검증하며 코어 DNS의 최종 결과를 보여주지는 않습니다. 아래 명령에는 예시 도메인이 사용되었습니다. 실제 문제를 테스트할 때는 오류가 발생한 공개 도메인으로 바꾸고, 계정이나 접근 정보가 포함된 전체 링크를 명령에 붙여 넣지 마세요. 결과에서 IPv4와 IPv6 주소가 함께 반환되는지도 확인해야 합니다.

nslookup example.com

암호화 DNS, 주소 계열 및 캐시 확인

브라우저의 보안 DNS 설정은 시스템 리졸버를 우회할 수 있으며 클라이언트가 별도의 암호화 DNS를 설정했을 수도 있습니다. 비교 가능한 테스트 경로를 만들려면 브라우저가 일시적으로 시스템 설정을 따르도록 하고 문제가 달라지는지 확인하세요. 테스트가 끝나면 실제 필요에 맞게 설정을 복구합니다. DNS 서버에 연결할 수 있는지와 반환된 주소를 사용할 수 있는지는 별개의 문제입니다. 서버가 응답하지 않을 때 조회 주소를 계속 바꿔도 라우팅 문제는 해결되지 않을 수 있습니다.

일부 도메인은 IPv4와 IPv6 주소를 함께 반환하지만 현재 네트워크에서는 두 주소 계열의 접근성이 다를 수 있습니다. 로그에서 연결할 수 없는 주소 계열을 계속 시도한다면 시스템 네트워크 상태와 클라이언트의 도메인 조회 정책을 비교하세요. 주소 계열을 일시적으로 제한하면 원인을 찾는 데 도움이 될 수 있지만, 모든 기기에서 한 프로토콜을 영구적으로 끄는 일반적인 해결책으로 사용하지 마세요. 최종 설정은 실제 네트워크와 서버의 지원 여부에 맞춰야 합니다.

조회 설정을 바꾼 뒤에도 브라우저, 시스템, 코어에 이전 결과가 캐시되어 있을 수 있습니다. 기존 탭을 닫거나 관련 앱을 다시 시작하고, 필요하면 클라이언트를 재시작한 뒤 같은 도메인을 테스트하세요. Windows에서는 아래 명령으로 시스템 조회 캐시를 비울 수 있지만 모든 앱의 캐시가 삭제되는 것은 아니며 잘못된 상위 리졸버도 해결되지 않습니다. 잘못된 경로를 확인하는 대신 캐시를 반복해서 비우지 마세요.

ipconfig /flushdns

DNS 경로와 라우팅을 일치시키기

직접 연결 트래픽과 프록시 트래픽은 서로 다른 조회 경로가 더 적합할 수 있습니다. 직접 요청이 다른 네트워크 출구에서만 사용할 수 있는 주소를 받으면 연결이 실패하거나 느려집니다. 원격 조회 요청이 접근할 수 없는 출구로 잘못 전송되어도 시간 초과가 발생할 수 있습니다. 반환된 주소만 보지 말고 DNS 요청 자체가 어떤 경로로 나가는지와 도메인 매칭 규칙을 먼저 확인하세요.

가상 네트워크 어댑터 모드에서는 시스템 DNS가 클라이언트가 의도한 경로로 연결되는지, 다른 VPN이 같은 설정을 바꾸지 않는지도 확인하세요. 가상 주소 매핑과 같은 기능을 사용한다면 조회와 후속 연결이 함께 구성된 규칙으로 처리되어야 합니다. 한 항목만 따로 복사하지 마세요. 일반 구독 가져오기 사용자는 자동 생성된 실행 설정을 직접 수정하기보다 클라이언트 그래픽 설정부터 확인하세요.

수정한 뒤에는 서버 도메인 조회, 대상 도메인 응답, 실제 접속이 예상한 라우팅을 따르는지 최소 세 가지를 검증하세요. 도메인 하나만 계속 문제가 있다면 권한 있는 DNS 레코드 변경, 사이트 상태, 네트워크별 결과를 비교한 뒤 별도 규칙이 필요한지 판단하세요. DNS는 모든 연결 오류를 해결하는 단일 스위치가 아닙니다. 조회가 성공해도 포트, 핸드셰이크, 대상 서비스에 문제가 남아 있을 수 있습니다.

시스템 프록시가 작동하지 않음

시스템 프록시는 앱이 읽어 사용할 수 있도록 운영체제가 제공하는 프록시 설정이며 모든 트래픽을 강제로 전달하지는 않습니다. 브라우저는 대개 이 설정을 따르지만 일부 터미널 도구, 게임, 자체 네트워크 모듈이 있는 앱은 자동으로 사용하지 않습니다. 따라서 브라우저는 정상인데 특정 앱만 연결되지 않는다면 앱의 연결 경로부터 확인하세요. 라우팅은 이미 클라이언트로 들어온 요청만 처리하므로 전역으로 바꾼 뒤 기다려도 해결되지 않습니다.

리스닝 포트와 시스템 설정 확인

v2rayN 매개변수 설정에서 로컬 리스닝 주소, 포트, 지원하는 프록시 프로토콜을 확인한 다음 시스템 프록시 설정과 비교하세요. 설정에 따라 포트가 다를 수 있으므로 가이드의 예시 값을 현재 기기의 고정값으로 여기면 안 됩니다. 로컬 앱은 일반적으로 루프백 주소로 연결합니다. 다른 기기의 주소나 원격 서버 포트를 입력하면 시스템 설정이 활성화된 것처럼 보여도 로컬 연결에는 실패합니다.

아래 Windows PowerShell 명령으로 예시 포트에서 TCP 연결을 수신하는지 확인할 수 있습니다. 출력이 없다면 클라이언트 코어가 실행 중인지, 포트가 실제 설정과 일치하는지 먼저 확인하세요. 출력이 있으면 해당 프로세스도 살펴볼 수 있습니다. 리스닝이 확인되어도 프로그램이 해당 포트를 사용 중이라는 뜻일 뿐, 기대한 프록시인지 원격 서버가 정상인지까지 증명하지는 않습니다.

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

다른 프로그램이 포트를 사용 중이라면 용도를 확인한 뒤 충돌하는 프로그램을 종료하거나 클라이언트 리스닝 포트를 변경하고 앱의 프록시 설정도 함께 업데이트하세요. 클라이언트만 바꾸고 시스템에는 이전 포트를 남겨 두지 마세요. 또한 로컬 접속을 위해 리스닝 주소를 모든 네트워크 어댑터로 확대하지 마세요. LAN 연결을 허용하는 것은 별도의 접근 범위를 열어 주는 일이며 로컬 시스템 프록시 문제를 해결하는 것과는 다릅니다.

수동 프록시, 자동 구성 및 앱 자체 설정 구분

수동 프록시와 자동 구성 스크립트는 서로 다른 방식이며 시스템 화면에 관련 항목이 함께 남아 있을 수 있습니다. 클라이언트 모드 이름도 운영체제의 특정 스위치 하나와 그대로 대응하지 않습니다. 실제로 입력된 주소, 포트, 스크립트 주소를 기준으로 확인하세요. 모드를 바꾼 뒤 테스트 앱을 종료했다가 다시 열어 기존 프로세스가 직접 연결을 재사용해 설정이 적용되지 않은 것처럼 보이는 상황을 피하세요.

브라우저 확장 프로그램, 기업 정책, 앱 자체 프록시 옵션이 시스템 설정을 덮어쓸 수 있습니다. 먼저 프록시 확장 프로그램을 비활성화해 비교한 뒤 앱에서 ‘프록시 사용 안 함’이나 다른 고정 주소가 선택되어 있는지 확인하세요. 일부 명령줄 프로그램은 환경 변수를 읽고 데스크톱 시스템 프록시는 읽지 않으며, 일부 Windows 구성 요소는 별도의 프록시 설정을 사용합니다. 트레이 메뉴의 스위치 하나가 모든 환경 설정을 바꾸리라고 기대하면 안 됩니다.

종료 후 남은 설정과 가상 네트워크 연결 확인

클라이언트가 비정상 종료되면 시스템 프록시가 더 이상 리스닝하지 않는 로컬 주소를 계속 가리킬 수 있습니다. 클라이언트를 종료한 뒤 모든 웹페이지가 열리지 않는다면 이런 상태일 수 있습니다. 시스템 설정에서 남아 있는 프록시를 일시적으로 끄고 직접 연결이 복구되는지 확인한 다음 클라이언트를 시작해 다시 설정하세요. 네트워크 어댑터를 삭제하거나 시스템 네트워크 전체를 초기화하지 마세요. 단순히 프록시 주소가 남은 문제를 파괴적인 방법으로 해결할 필요는 없습니다.

시스템 프록시를 사용하지 않는 앱을 연결해야 한다면 클라이언트 설명서를 참고해 가상 네트워크 어댑터 모드를 검토하세요. 이 모드는 권한, 라우팅, DNS 연결을 다룰 수 있으므로 먼저 일반 로컬 프록시 경로가 정상인지 확인한 뒤 따로 테스트하세요. 권한 상승을 모든 시스템 프록시 문제의 해결책으로 여기지 마세요. 권한 오류가 명확하거나 해당 연결 기능이 필요한 경우에만 관련 권한을 부여하면 됩니다.

최종 확인은 설정 단계와 트래픽 단계 모두에서 진행해야 합니다. 시스템 화면의 주소가 올바른지, 클라이언트 포트가 실제로 리스닝하는지, 앱 요청이 로그에 기록되는지, 대상 사이트에 예상대로 접속되는지 확인하세요. 트레이 메뉴에 체크 표시가 있는 것만으로 이 네 가지가 모두 정상이라고 볼 수는 없습니다. 완료 후 클라이언트를 종료하고 시스템 설정이 예상대로 복구되는지 확인해 다음 실행 전 남은 설정으로 같은 문제가 반복되지 않도록 하세요.

클라이언트 충돌 및 시작 실패

시작 문제는 그래픽 인터페이스가 열리지 않는 경우, 인터페이스는 열리지만 코어가 종료되는 경우, 실행 중 프로그램 전체가 닫히는 경우로 나눠야 합니다. 각각 그래픽 실행 환경, 생성된 설정 또는 코어 네트워크 프로세스, 시스템 리소스와 백그라운드 소프트웨어가 관련될 수 있습니다. 시작 직후 종료, 구독 업데이트 후 종료, 가상 네트워크 어댑터를 켠 뒤 종료처럼 문제가 발생한 동작을 기록하고 해당 시각의 로그를 찾으세요. “작동하지 않는다”라고만 설명하지 마세요.

패키지 종류, 권한 및 실행 환경부터 확인

클라이언트 다운로드 페이지에서 운영체제와 프로세서에 맞는 패키지를 선택하세요. Windows 데스크톱판과 클래식 WPF판은 서로 다른 UI 기술을 사용하므로 필요한 실행 환경은 실제 패키지의 안내를 따라야 합니다. 특정 실행 환경이 모든 패키지에 공통으로 필요하다고 가정하지 마세요. macOS에서는 Apple Silicon과 Intel을 구분하고, Linux에서는 프로세서 아키텍처와 배포판 패키지 형식을 모두 확인하세요. 아키텍처가 맞지 않는 문제를 설정 손상으로 오해하지 않도록 주의하세요.

압축을 풀어야 하는 파일이라면 쓰기 권한이 있는 위치에 전체 압축을 푼 다음 실행하세요. 압축 파일 미리보기 창에서 바로 실행하지 마세요. 종속 파일과 기본 프로그램이 올바른 폴더에 있는지, 정리 도구가 작업 경로를 이동하지 않았는지 확인하세요. 설치나 첫 실행이 시스템 보안 기능에 의해 차단되면 시스템에 표시된 구체적인 사유를 확인하고 운영체제가 제공하는 앱 허용 절차를 이용하세요. 기기 전체의 보안 기능을 바로 끄지 마세요.

실행 환경 누락 메시지가 명확하다면 시스템 아키텍처와 필요한 구성 요소를 안내에 따라 확인하세요. 파일 접근 실패가 발생한다면 폴더 권한, 저장 공간, 설정 파일을 다른 프로그램이 사용 중인지 점검하세요. 프로그램 폴더를 클라우드 동기화 위치에 두면 파일 잠금이나 동기화 충돌이 생길 수 있습니다. 진단을 위해 로컬의 일반 폴더에 복사해 테스트하되 원본 폴더를 보존하고, 같은 설정을 수정하는 인스턴스 두 개를 동시에 실행하지 마세요.

인터페이스 문제와 코어 설정 오류 구분

그래픽 인터페이스는 계속 열려 있는데 코어만 반복해서 종료된다면 로그에서 지원되지 않는 필드, 잘못된 프로토콜 조합, 포트 충돌, 규칙 파일 누락이 있는지 확인하세요. 최근 사용자 지정 설정, 라우팅, DNS를 활성화했다면 해당 변경부터 되돌리세요. 일반 구독 사용자는 자동 생성된 실행 설정을 직접 편집하지 않는 것이 좋습니다. 다음에 앱 설정을 적용할 때 변경 내용이 덮어써질 수 있고 그래픽 인터페이스 상태와 실제 설정이 달라질 수 있습니다.

네이티브 JSON 문법을 확인하는 중이라면 아래는 객체, 배열, 쉼표, 불리언 값의 표기법을 보여주는 유효한 최소 JSON 예시입니다. 프록시 연결을 설정하는 완전한 코어 설정이 아니므로 그대로 사용할 수 없습니다. 확인할 때는 끝의 불필요한 쉼표, 중국어 구두점, 문자열 따옴표에 특히 주의하세요. 문법이 올바르더라도 프로토콜 필드가 현재 코어의 요구 사항에 맞는다는 뜻은 아닙니다.

{
  "log": {
    "loglevel": "warning"
  }
}

코어 호환성을 확인할 때는 먼저 항목에 필요한 프로토콜 기능을 파악한 다음 클라이언트가 실제로 사용하는 코어와 비교하세요. v2rayNG와 v2flyNG는 서로 다른 코어 계열을 사용하므로 앱 이름만 바꾸면 매개변수가 호환된다고 볼 수 없습니다. 배경 설명은 Xray와 V2Fly 코어의 차이를 참고하세요. 출처가 불분명한 코어 파일을 클라이언트 폴더에 바로 덮어쓰지 마세요.

설정을 분리해 손상 여부 확인

사용자 설정이 손상된 것으로 의심되면 모든 인스턴스를 종료하고 설정, 구독 그룹, 사용자 지정 규칙을 백업한 다음 클라이언트가 지원하는 방법으로 새 사용자 설정 폴더를 만들어 테스트하세요. 기존 폴더를 바로 삭제하지 마세요. 새 설정으로 실행된다면 문제는 이전 설정이나 확장 설정에 가까울 수 있습니다. 구독, 라우팅, 기타 설정을 나눠 복원하면서 어느 단계에서 문제가 다시 발생하는지 확인하세요. 이전 내용을 한꺼번에 덮어쓰지 마세요.

깨끗한 설정에서도 종료가 반복된다면 시스템 이벤트 기록, 남은 저장 공간, 메모리 사용량, 보안 소프트웨어의 차단 기록을 확인하세요. Linux 데스크톱은 그래픽 세션과 패키지 종속성을, macOS는 시스템 권한 안내를 살펴보세요. 문제가 발생하는 조건에 맞춰 증거를 수집한 뒤 업데이트나 재설치를 결정하세요. 기존 사용자 설정은 덮어쓰기 설치로 제거되지 않을 수 있으므로 재설치 후에도 실패한다고 해서 곧바로 소프트웨어 자체 문제라고 단정할 수는 없습니다.

실행이 복구되면 정상적으로 작동하는 설정 하나로 기본 프록시부터 확인한 뒤 복잡한 기능을 하나씩 되돌리세요. 여러 설치 패키지를 연속해서 시도하기보다 재현 절차, 오류 원문, 이미 확인한 항목을 남기는 편이 문제 해결에 도움이 됩니다. 첫 설치 절차는 데스크톱 첫 설치 및 초기 설정을 참고하세요. 이 장에서는 비정상 상태를 다루며 일반 설치 절차를 대신하지 않습니다.

Android 연결 및 백그라운드 실행

Android에서는 일반적인 연결 문제를 먼저 v2rayNG로 확인하고, V2Fly 코어 기능이 필요할 때 v2flyNG를 검토하세요. 두 앱 모두 서버 설정과 시스템 VPN 연결을 구분해야 합니다. 상태 표시줄에 VPN 아이콘이 나타나도 시스템 연결이 수립되었다는 뜻일 뿐 서버 핸드셰이크가 성공했다는 의미는 아닙니다. 아이콘은 정상인데 접속할 수 없다면 로컬 연결, 서버 연결, 라우팅, DNS 순서로 점검하세요.

VPN 권한 및 네트워크 상태 확인

처음 연결할 때 시스템에서 VPN 권한을 확인하는 메시지가 표시됩니다. 실수로 거부했다면 다시 연결을 시도하고 시스템 안내에 따라 권한을 허용하세요. 업무 프로필이나 기기 관리 정책이 적용된 기기는 해당 관리 기준을 따라야 합니다. 권한 문제를 해결하려고 앱 데이터를 반복해서 지우지 마세요. 구독과 사용자 지정 설정도 함께 삭제됩니다. 다른 VPN 앱을 중지하고 현재 설정이 다른 VPN 연결로 대체되지 않았는지 먼저 확인하세요.

공용 Wi-Fi는 먼저 로그인 인증 페이지를 거쳐야 할 수 있습니다. VPN에 연결하기 전에 프록시를 중지하고 네트워크 로그인을 마친 뒤 다시 연결하세요. Wi-Fi에서 모바일 데이터로 전환하면 이전 연결이 시간 초과를 기다리는 경우가 있습니다. 연결을 중지했다가 다시 시작하고 로그에서 새 네트워크를 사용하는지 확인하세요. 한 종류의 네트워크에서만 실패한다면 같은 서버와 설정을 유지해 비교하세요. 네트워크와 서버를 동시에 바꾸면 원인을 파악하기 어렵습니다.

시스템의 상시 VPN 설정과 VPN을 통하지 않는 연결 차단은 앱 화면과 별개로 작동합니다. 우회 연결 차단이 켜져 있으면 VPN이 연결되지 않은 동안 일부 트래픽이 시스템 정책에 따라 막힐 수 있습니다. 따라서 클라이언트를 중지한 뒤에도 인터넷이 안 된다고 해서 기본 네트워크가 손상되었다고 단정할 수는 없습니다. 시스템 VPN 정책을 먼저 확인하고 실제 필요에 따라 복구하세요. 휴대전화를 재부팅하는 것만으로 원인을 피하지 마세요.

앱별 프록시 및 DNS를 함께 확인

앱별 프록시를 켰다면 선택한 앱만 프록시를 사용할지, 선택한 앱을 우회할지 확인하세요. 두 목록은 의미가 반대입니다. 테스트할 브라우저가 의도한 목록에 포함되지 않았다면 클라이언트를 전혀 거치지 않을 수 있습니다. 목록을 변경한 뒤 VPN을 다시 연결하고 테스트 앱도 완전히 종료했다가 다시 여세요. 목록에서 앱 아이콘에 체크 표시가 있다는 이유만으로 프록시를 사용한다고 판단하지 마세요.

특정 앱만 실패한다면 다른 구성 요소가 요청을 보내는지, 자체 프록시나 보안 DNS 설정이 있는지 확인하세요. 기본 앱과 관련 구성 요소가 서로 다른 네트워크 경로를 사용해 로그인은 되지만 리소스 로딩은 실패할 수 있습니다. 먼저 프록시 범위에 포함된 것이 확인된 브라우저로 기준을 잡고 다른 앱을 하나씩 추가하세요. Android 설정의 기본 흐름은 v2rayNG 사용 가이드를 참고하세요.

로컬 DNS나 트래픽 스니핑을 활성화해도 모든 앱 문제가 자동으로 해결되지는 않습니다. 스니핑은 라우팅에서 도메인을 식별하는 데 도움이 될 수 있지만 앱 콘텐츠를 복호화하는 기능도, 올바른 DNS와 프로토콜 설정을 대신하는 기능도 아닙니다. 도메인 관련 오류가 발생하면 DNS 항목을 참고해 조회가 이루어지는 위치를 확인하고 한 번에 하나만 변경하세요. 서버 매개변수는 여전히 전체 설정을 기준으로 확인해야 합니다. 데스크톱 스크린샷을 보고 임의로 필드를 추가하지 마세요.

백그라운드 연결 끊김은 배터리 및 프로세스 제한부터 확인

화면을 잠근 뒤 연결이 끊기고 앱으로 돌아오면 복구되는 경우 배터리 최적화, 백그라운드 활동 제한, 데이터 절약, 제조사의 자동 실행 관리가 주요 점검 항목입니다. 시스템 앱 설정에서 필요한 백그라운드 실행을 허용하고 클라이언트가 요구하는 포그라운드 서비스 알림은 유지하세요. 기기마다 설정 메뉴 이름이 다르므로 실제 시스템 화면에서 찾으면 됩니다. 특정 앱 하나 때문에 모든 앱의 배터리 관리를 끌 필요는 없습니다.

백그라운드 실행을 허용한 뒤에도 연결이 끊긴다면 네트워크 전환, 장시간 유휴 상태, 시스템 메모리 정리 중 언제 발생하는지 기록하세요. 화면을 켜 둔 상태와 비교해 네트워크의 유휴 연결 정리와 프로세스 종료를 구분하세요. 로그 기록 중단, VPN 아이콘 사라짐, 서버 재연결 실패는 서로 다른 단서이므로 각각 기록해야 합니다. 재연결 빈도만 높이면 배터리 소모가 늘어날 수 있지만 시스템이 프로세스를 계속 종료하는 문제는 해결되지 않습니다.

재설치가 필요하다면 먼저 구독과 사용자 지정 규칙을 백업한 뒤 Android 다운로드 페이지에서 프로세서에 맞는 패키지를 선택하세요. 설치 패키지를 바꾸면서 프로토콜 설정까지 함께 변경하지 마세요. 최종 테스트에는 앱을 전면에서 사용할 때, 화면을 잠근 뒤 다시 연결할 때, Wi-Fi와 모바일 데이터를 전환할 때를 포함하세요. 여전히 문제가 있으면 기기 운영체제, 앱 이름, 재현 절차, 민감 정보를 가린 로그를 정리한 뒤 해당 문제 해결 항목으로 돌아가 원인을 좁히세요.