1. 클라이언트가 실행 중인데 인터넷에 연결되지 않음
먼저 모든 웹사이트가 열리지 않는지, 일부만 열리지 않는지 구분하세요. 전자라면 프록시 진입점과 서버 연결을 먼저 확인하고, 후자라면 라우팅 규칙과 DNS를 확인하세요. 브라우저에 연결 오류가 표시된다고 해서 서버 문제라고 단정할 수는 없습니다. 요청이 클라이언트에 도달하지 않았거나, 클라이언트에 도달한 뒤 적절하지 않은 경로로 전달됐을 수 있습니다. 아래 순서대로 확인하고 단계마다 결과를 기록하세요.
선택한 서버와 실행 상태 확인
v2rayN 서버 목록에서 현재 선택된 서버가 있는지 확인하세요. 구독만 가져오고 항목을 선택하지 않았거나 구독 업데이트 중 기존 항목이 교체되면 이후 점검 대상이 불분명해질 수 있습니다. 클라이언트 로그를 열어 시작 시 설정 읽기 오류, 코어 실행 실패, 포트 충돌 또는 연결 실패가 있는지 먼저 확인하세요. 시작 단계에서 오류가 발생했다면 로그에 나온 첫 번째 명확한 오류부터 해결하고 DNS는 바로 변경하지 마세요.
일시적으로 정상 작동이 확인된 다른 서버를 선택해 다시 테스트하세요. 한 서버만 실패하면 해당 항목의 주소, 포트, 전송 설정을 먼저 확인하고, 모두 실패하면 로컬 프록시 진입점과 네트워크 환경을 살펴보세요. 서버 정보는 구독 제공자나 직접 관리하는 서버의 설정을 기준으로 해야 합니다. 사용자 ID, PublicKey, ShortId를 기억에 의존해 입력하지 마세요. 수정 전 항목을 복사해 두면 비교하거나 되돌리기 쉽습니다.
시스템 프록시와 적용 범위 확인
v2rayN의 시스템 프록시 메뉴에서 현재 상태를 확인하세요. 브라우저가 시스템 프록시를 사용하는 경우 클라이언트가 실행 중이어도 운영체제가 브라우저 트래픽을 클라이언트로 보내지 않을 수 있습니다. 시스템 프록시를 필요한 모드로 전환한 다음 브라우저 창을 닫았다가 다시 열어 테스트하세요. 브라우저에 별도 프록시나 확장 프로그램이 설정되어 시스템 프록시를 덮어쓰는지도 확인하세요. 다른 앱이 시스템 프록시를 따르는지는 앱 구현 방식에 따라 다릅니다.
프록시 연결 경로만 확인하려면 잠시 글로벌 프록시로 전환해 같은 대상을 테스트할 수 있습니다. 글로벌 모드에서는 접속되고 기존 라우팅 모드에서는 접속되지 않는다면 프록시 진입점과 서버는 대체로 정상이며, 라우팅 규칙을 확인해야 합니다. 클라이언트를 반복해서 재설치할 필요는 없습니다. 테스트가 끝나면 원래 모드로 복원해 진단을 위해 바꾼 설정이 일상 설정에 남지 않도록 하세요. TUN은 더 많은 트래픽을 처리할 수 있지만, 원인을 확인하지 않은 시스템 프록시 문제를 가리는 용도로 사용하면 안 됩니다.
로그에서 요청이 멈춘 단계 찾기
클라이언트의 로그 화면을 열고 테스트 페이지 하나만 방문해 해당 연결 기록이 나타나는지 확인하세요. 기록이 전혀 없다면 시스템 프록시, 앱 자체 프록시 또는 TUN 진입점을 먼저 점검하세요. 요청 기록은 있지만 대상 주소를 확인하지 못했다면 이 페이지의 DNS 섹션으로 이동하세요. 원격 연결 시간 초과가 나타나면 서버 시간 초과 섹션을 확인하세요. 로그에 규칙이 직접 연결 또는 차단 경로와 일치했다고 표시되면 라우팅 설정을 점검해야 합니다.
테스트할 때는 같은 브라우저, 같은 대상, 같은 서버를 사용해 여러 탭의 요청이 섞이지 않도록 하세요. 로그에 “클라이언트가 시작됨”이라고 표시되어도 대상 웹사이트가 프록시를 통해 연결됐다는 뜻은 아닙니다. 프로그램이 실행 상태에 들어갔다는 것만 확인해 줍니다. 필요하면 일반적으로 직접 연결되는 사이트와 현재 프록시 규칙을 적용해야 하는 사이트를 각각 테스트하고, 두 요청의 규칙 일치 결과를 비교하세요.
로컬 네트워크와 남아 있는 프록시 설정 확인
클라이언트의 시스템 프록시 설정을 잠시 끄고 현재 네트워크에서 원래 직접 연결할 수 있는 페이지에 접속되는지 확인하세요. 직접 연결도 되지 않는다면 Wi-Fi, 유선 연결, 게이트웨이 또는 운영체제 네트워크 설정부터 해결해야 합니다. 프록시 클라이언트는 기본 네트워크 연결이 끊긴 문제를 해결할 수 없습니다. 다른 프록시 앱이 같은 수신 포트를 사용 중인지, 시스템에 오래된 프록시 주소가 남아 있는지도 확인하세요. 노드 전환을 반복하기 전에 로그에 표시된 포트 충돌부터 해결하는 편이 낫습니다.
점검을 마치면 시스템 프록시와 라우팅 모드를 원래 사용하려던 상태로 복원하고 처음 실패했던 작업을 다시 테스트하세요. 특정 앱에서만 문제가 발생한다면 그 앱의 프록시 옵션과 네트워크 권한을 먼저 확인하세요. 한 앱의 동작을 기기 전체의 문제로 확대 해석하지 마세요. “연결은 됐지만 웹페이지가 열리지 않음” 같은 간단한 질문은 도움말에서 확인할 수 있습니다. 기본 설정을 처음부터 다시 구성하려면 가이드를 참고하세요.
2. 서버 시간 초과 또는 연결이 반복적으로 끊김
서버 시간 초과는 정해진 시간 안에 연결이 완료되지 않았다는 뜻이며, 원인이 하나로 정해져 있는 것은 아닙니다. 서버 주소의 DNS 조회, 대상 포트, 전송 프로토콜, 전송 계층 보안, 현재 네트워크가 모두 영향을 줄 수 있습니다. 먼저 시간 초과가 특정 서버에서만 발생하는지 확인한 다음 설정을 점검하세요. 같은 구독의 모든 서버가 시간 초과라면 공통으로 사용하는 네트워크 진입점, 구독 내용, 클라이언트 상태부터 확인해야 합니다.
문제 범위를 비교하고 지연 시간 측정만으로 판단하지 않기
같은 네트워크에서 현재 서버와 정상 작동이 확인된 다른 서버를 각각 테스트하고, “단일 서버 실패”, “같은 그룹의 서버 실패”, “전체 서버 실패” 중 어디에 해당하는지 기록하세요. 클라이언트의 지연 시간 테스트는 특정 연결 경로만 확인하므로 실제 웹사이트나 앱 접속을 대신하지 못합니다. 지연 시간 테스트는 통과했지만 웹페이지가 열리지 않는다면 라우팅, DNS, 앱 프록시를 추가로 확인하세요. 지연 시간 테스트는 실패했지만 일부 서비스가 작동하더라도 측정값 하나만으로 서버를 삭제하지 마세요.
현재 Wi-Fi에서 모바일 네트워크로 전환하는 등 정상 작동하는 다른 네트워크에서도 비교 테스트하세요. 같은 설정이 한 네트워크에서만 실패하면 해당 네트워크의 DNS와 게이트웨이, 필요한 연결 방식이 허용되는지 확인하세요. 네트워크를 바꿔도 실패하고 다른 서버는 정상이라면 해당 서버의 상태와 설정 필드 일치 여부에 집중하세요. 테스트 시각과 로그의 오류 유형을 기록해 두세요. 설정 제공자에게 문의할 때 “서버가 안 돼요”라고만 말하는 것보다 도움이 됩니다.
서버 설정 필드를 하나씩 확인
“서버 편집”에서 주소(address), 포트(port), 사용자 ID(id), 전송 프로토콜(network), 전송 계층 보안(TLS)을 차례대로 확인하세요. 이 값은 서버 측과 일치해야 하며, 프로토콜 이름이 같다고 서로 바꿔 쓸 수 있는 것은 아닙니다. VLESS와 REALITY를 사용하는 경우 SNI, Fingerprint, PublicKey, ShortId와 서버에서 요구하는 흐름 제어(flow)도 확인해야 합니다. 일부 필드는 비워 둘 수 있지만, 실제 서버 설정에 따라 결정해야 합니다.
수정할 때는 근거가 있는 필드 하나만 바꾸고 변경 전 값을 기록하세요. 서버 주소가 도메인이라면 현재 네트워크에서 해당 도메인을 조회할 수 있는지 먼저 확인하세요. IP 주소라면 DNS는 이 연결 진입점의 첫 번째 의심 대상이 아닙니다. WebSocket 같은 전송 방식을 사용하는 경우 해당 경로와 호스트 이름 설정도 확인하세요. 구독을 가져올 때 생성된 필드와 수동 편집한 항목을 비교하면 전송 매개변수가 누락됐는지 찾을 수 있습니다.
로그에서 시간 초과가 발생한 위치 확인
로그에 서버 도메인 조회 실패가 표시되면 로컬 DNS나 구독에 사용된 도메인을 먼저 확인하세요. 원격 연결 시간 초과라면 주소, 포트, 기본 네트워크, 서버 실행 상태를 확인해야 합니다. 연결이 설정된 뒤 보안 핸드셰이크 오류가 발생하면 SNI, 인증서 관련 설정 또는 REALITY 매개변수를 중점적으로 확인하세요. 오류가 발생한 단계마다 해결 방법이 다르므로 “timeout”을 봤다는 이유만으로 코어를 바로 바꾸지 마세요.
Windows에서는 운영체제에 기본 제공되는 이름 조회 명령으로 도메인 조회 여부를 확인할 수 있습니다. 아래 도메인은 명령어 형식을 보여 주는 예시일 뿐입니다. 실제 점검 시에는 확인 권한이 있는 서버 도메인으로 바꾸세요. 조회 결과에 주소가 나와도 DNS 단계가 끝났다는 뜻일 뿐, 원격 포트에 접속할 수 있거나 프로토콜 핸드셰이크가 성공한다는 뜻은 아닙니다.
nslookup v2raypeizhi.com연결 끊김 후 자동 복구와 안정성
처음에는 연결이 정상인데 사용 중 끊긴다면 끊기는 시점에 기기가 절전 상태였는지, 유선에서 무선으로 네트워크가 바뀌었는지, 대기 상태에서 복귀했는지 기록하세요. 모바일 네트워크 전환이나 컴퓨터 절전으로 기존 연결이 끊길 수 있습니다. 먼저 요청을 다시 보내 새 연결을 맺을 수 있는지 확인하세요. 새 연결도 계속 실패할 때만 서버 문제로 보고 추가 점검하세요. 앱이 유지하던 기존 연결의 오류와 새 연결을 맺을 수 있는지를 혼동하지 마세요.
클라이언트가 여러 개 동시에 실행 중인지, 로컬 보안 프로그램이 코어 프로세스나 수신 포트를 차단하는지도 확인하세요. 특정 서버만 계속 불안정하다면 원래 설정을 보존하고 같은 그룹의 다른 항목과 비교하세요. 모든 서버 설정을 한꺼번에 덮어쓰지 마세요. Xray와 V2Fly의 기능 차이는 코어 선택 가이드에서 확인할 수 있습니다. 코어 변경은 프로토콜 호환성을 확인한 뒤 진행해야 합니다.
3. 구독 업데이트 실패 또는 서버 목록이 비어 있음
구독 업데이트는 “구독 내용 가져오기”와 “내용을 해석해 그룹에 저장하기”의 두 단계로 진행됩니다. 오류가 나면 내용을 가져오지 못한 것인지, 가져온 뒤 클라이언트가 인식하지 못한 것인지 구분하세요. 목록이 비어 있는 것은 현재 필터가 서버를 숨긴 결과일 수도 있습니다. 기존 구독을 반복해서 수정하기 전에 주소, 그룹, 필터 조건을 포함한 현재 설정을 저장하고 항목별로 확인하세요.
구독 주소와 현재 네트워크 확인
v2rayN의 구독 그룹 설정에서 주소에 불필요한 공백이나 줄바꿈이 들어갔거나 일부가 잘리지 않았는지 확인하고, 해당 그룹이 활성화되어 있는지도 확인하세요. 구독 주소에는 접근 정보가 포함되는 경우가 많으므로 비공개로 다뤄야 합니다. 전체 주소가 보이도록 공개 스크린샷이나 게시물에 올리지 마세요. 제공자에게 문의할 때는 오류 유형, 발생 시각, 클라이언트만 설명하고 전체 링크는 공개하지 마세요.
업데이트에 실패하면 먼저 기기에서 일반 웹페이지에 접속할 수 있는지 확인한 뒤, 구독 그룹의 업데이트 방식에 따라 요청에 기존 프록시가 필요한지 점검하세요. 사용 가능한 서버가 없는 첫 가져오기 단계에서 구독 요청을 현재 프록시에만 의존하도록 설정하면 “업데이트하려면 먼저 서버가 있어야 하는” 순환 문제가 생길 수 있습니다. 기존 서버는 작동하지만 구독 요청만 실패한다면 직접 연결과 프록시를 통한 업데이트를 각각 테스트하고, 구독 주소에 실제로 접속할 수 있는 방식을 선택하세요.
네트워크 오류와 내용 오류 구분
로그에 도메인 조회 실패나 연결 시간 초과가 표시되면 주소의 도메인, 네트워크 연결 상태, 가져오기 경로를 먼저 확인하세요. 접근 거부나 구독 형식이 아닌 내용이 반환됐다는 오류가 표시되면 구독 제공자에게 권한과 내용 유형을 확인하세요. 클라이언트가 웹페이지를 내려받았다고 해서 가져올 수 있는 서버 목록이라는 뜻은 아닙니다. 주소를 브라우저에서 열었을 때 로그인 페이지, 안내 페이지, 오류 페이지가 표시된다면 업데이트를 반복해도 유효한 서버가 생성되지 않습니다.
로그에 내용 해석 실패가 표시되더라도 반환된 내용을 서버 편집 창에 직접 붙여넣지 마세요. 구독에는 여러 설정이 포함될 수 있으며, 단일 서버 필드만으로는 그룹, 필터, 업데이트 규칙을 모두 표현할 수 없습니다. 확인된 주소만 입력한 임시 구독 그룹을 새로 만들어 테스트할 수 있습니다. 임시 그룹이 정상적으로 업데이트된다면 원래 그룹의 업데이트 방식이나 필터 설정을 더 자세히 확인해야 합니다. 원인을 찾은 뒤에는 임시 그룹을 삭제해 서버가 중복으로 남지 않도록 하세요.
서버를 가져왔지만 목록에 표시되지 않음
현재 선택한 구독 그룹, 목록 검색창, 키워드 필터 조건을 확인하세요. 그룹을 바꾸면 목록에 해당 그룹의 서버만 표시될 수 있고, 필터 단어가 모든 항목을 숨길 수도 있습니다. 먼저 검색 조건을 지우고 전체 서버를 표시한 다음, 로그나 업데이트 결과에 항목이 실제로 저장됐는지 확인하세요. 특히 키워드 규칙을 방금 변경했다면 목록이 비어 있다고 구독 제공처가 작동하지 않는다고 단정하지 마세요.
가져오기는 성공했지만 서버 수가 예상과 다르면 구독 제공자가 내용을 변경했는지 확인한 뒤 중복 제거, 필터링, 그룹 소속을 살펴보세요. 여러 구독의 서버 이름이 비슷할 수 있으므로 이름만으로 설정이 완전히 같다고 판단하면 안 됩니다. 여러 출처를 관리하는 방법은 v2rayN 다중 구독 그룹 관리에서 확인할 수 있습니다. 문제를 진단하는 동안에는 필터 조건을 최소화하고 서버가 다시 표시된 뒤 하나씩 추가하세요.
업데이트 결과를 재현 가능하게 기록
빠르게 여러 번 누르지 말고 “수동 업데이트 1회”의 정확한 결과를 기록하세요. 요청이 끝나기 전에 업데이트를 다시 실행하면 로그가 뒤섞여 어느 요청이 실패했는지 파악하기 어렵습니다. 업데이트 전후의 그룹 이름과 서버 목록, 마지막으로 확인된 오류를 살펴보세요. 구독이 여러 개라면 그룹별로 업데이트해 특정 출처만 실패하는지 전체 출처가 실패하는지 확인하세요. 전체 출처가 실패한다면 기기 네트워크와 요청 방식부터 점검하는 편이 좋습니다.
기존 서버가 계속 작동한다면 네트워크 확인을 위해 그대로 보존하고 구독 문제를 해결한다는 이유로 서버 그룹 전체를 삭제하지 마세요. 기존 서버도 동시에 작동하지 않는다면 네트워크가 바뀌었거나 시스템 프록시 상태가 변했는지 확인한 다음 인터넷 연결 문제 섹션으로 돌아가 진입점을 점검하세요. 구독 업데이트와 서버 연결은 서로 다른 경로입니다. 업데이트에 실패해도 저장된 서버가 바로 사용할 수 없게 되는 것은 아니며, 서버가 작동한다고 해서 구독 주소에 접속할 수 있다는 뜻도 아닙니다.
4. 연결은 되지만 페이지를 열거나 다운로드하는 속도가 느림
속도 문제를 “처음 열 때 느림”, “전송 중 계속 느림”, “특정 앱에서만 느림”으로 나눠 보세요. 처음 열 때는 DNS, 연결 설정, 보안 핸드셰이크가 영향을 주는 경우가 많습니다. 전송 속도는 서버 부하, 회선, 로컬 네트워크에도 좌우됩니다. 클라이언트 지연 시간 순위만 보고 실제 전송 속도를 단정하지 말고, 서버 변경, DNS 변경, TUN 활성화를 동시에 한 뒤 개선 원인을 한 가지로 돌리지 마세요.
비교할 테스트 조건 맞추기
같은 기기와 네트워크에서 비슷한 시간대에 기존 서버와 정상 작동이 확인된 다른 서버로 같은 종류의 페이지에 접속해 보세요. 먼저 진행 중인 대용량 파일 전송을 중지하고 첫 화면이 뜨기까지 오래 걸리는지, 페이지 리소스가 계속 느리게 로드되는지 확인하세요. 서버 하나만 느리다면 해당 서버와 원격 상태를 먼저 점검하세요. 모든 서버가 느리다면 프록시를 사용하지 않을 때의 기본 네트워크도 테스트하세요. 기본 네트워크 자체가 혼잡하면 클라이언트 설정을 바꿔도 근본 원인이 해결되지 않습니다.
브라우저는 리소스를 캐시하므로 같은 페이지를 다시 열었을 때 캐시가 결과에 영향을 줄 수 있습니다. 비교할 때는 자주 이용하는 페이지를 여러 개 선택하고, 한 번의 테스트에서 정확한 속도를 얻으려 하기보다 같은 현상이 널리 나타나는지 확인하세요. 클라이언트 로그에서 반복적인 재시도, 핸드셰이크 실패, 연결 초기화가 발생하는지도 살펴보세요. 이런 현상은 지연 시간 수치 하나보다 네트워크 전송의 불안정성을 잘 보여 줍니다. 실제 경로가 바뀌지 않도록 테스트 중에는 기존 라우팅 모드를 유지하세요.
라우팅 우회 여부 확인
원래 직접 연결되어야 하는 서비스까지 느려졌다면 v2rayN 라우팅 설정의 규칙 순서, 일치 조건, 출구를 확인하세요. 규칙은 일반적으로 순서대로 적용되므로 앞쪽의 범위가 넓은 규칙이 요청을 먼저 가져가 뒤쪽의 구체적인 규칙이 적용되지 않을 수 있습니다. 로그를 열고 느린 대상 하나가 어떤 규칙과 일치했는지 확인한 뒤 조정 여부를 결정하세요. 규칙 묶음을 임의로 옮기며 결과를 기대하지 마세요.
짧게 글로벌 프록시로 전환해 비교하면 분할 라우팅 문제를 파악하는 데 도움이 되지만, 그 결과만으로 특정 규칙이 잘못됐다고 단정할 수는 없습니다. 글로벌 모드는 원래 직접 연결되어야 하는 트래픽도 다른 경로로 보낼 수 있습니다. “일부 사이트는 느리고 다른 곳은 정상”이라면 도메인, DNS 조회 결과, 라우팅 출구를 각각 기록하세요. 규칙을 변경한 뒤에는 기존에 느리던 대상과 정상적이던 대상을 모두 다시 테스트해 한쪽을 해결하면서 다른 요청 경로가 잘못되지 않도록 하세요.
DNS 지연과 연결 재시도 확인
페이지가 한동안 빈 화면으로 있다가 갑자기 모두 표시된다면 브라우저 네트워크 정보와 클라이언트 로그가 DNS 조회나 최초 연결 단계에서 멈췄는지 확인하세요. DNS 문제는 연결이 완전히 실패하는 형태로만 나타나지 않습니다. 접속할 수 없는 주소로 조회되거나, 상위 DNS 응답이 느리거나, DNS와 라우팅 경로가 맞지 않아도 대기 시간이 길어질 수 있습니다. 관련 점검은 DNS 섹션으로 이동하세요. 분할 DNS와 라우팅의 연동을 이해하려면 DNS 분할 설정 가이드를 참고하세요.
로그에 같은 원격 서버로 계속 재연결하는 내용이 표시되면 서버 시간 초과 섹션을 참고해 전송 설정과 네트워크 안정성을 확인하세요. 재시도로 인한 대기 시간을 DNS 문제로 바로 단정하지 마세요. TUN을 사용 중이라면 TUN을 끄고 시스템 프록시만 사용할 때의 상태도 비교하세요. TUN을 사용할 때만 문제가 생기면 모든 구독을 바꾸기 전에 TUN의 트래픽 처리 범위와 로컬 네트워크 도구 간 충돌을 확인하세요.
앱·기기·네트워크 범위 확인
앱 하나에서만 느리다면 해당 앱에 자체 프록시가 설정되어 있는지, 기존 연결을 재사용하는지, 별도의 DNS 또는 네트워크 가속 설정이 있는지 확인하세요. 브라우저는 정상인데 다운로드 도구만 느리다면 두 앱의 트래픽이 서로 다른 진입점을 사용하는 경우가 많습니다. 노드 성능을 따지기 전에 먼저 트래픽 경로를 확인하세요. 컴퓨터가 절전 모드에서 복귀한 뒤 잠시 느려졌다면 연결을 새로 맺고 네트워크가 안정된 상태에서 다시 테스트하세요.
같은 네트워크에서 여러 기기의 속도가 모두 느리다면 라우터 부하, Wi-Fi 신호, 인터넷 서비스 제공자 상태를 확인하세요. 같은 기기가 다른 네트워크에서 바로 정상화되면 원래 네트워크를 더 중점적으로 점검해야 합니다. 필요하면 “네트워크, 클라이언트, 서버, 대상 앱, 라우팅 모드, TUN 사용 여부”를 간단한 표로 기록하세요. 어느 변수가 바뀌었는지 확인하기 쉽고, 이후 원래 설정으로 되돌리기도 편합니다.
5. DNS 조회 오류·오염 또는 DNS와 라우팅 불일치
DNS는 도메인 이름을 연결에 사용할 주소로 변환하고, 라우팅은 요청이 어느 출구로 나갈지 결정합니다. 두 기능은 같은 설정이 아닙니다. 브라우저에서 서버를 찾을 수 없거나, 특정 도메인이 간헐적으로만 열리거나, 도메인으로는 실패하지만 확인된 주소로는 연결되는 경우 DNS 경로를 점검해야 합니다. 상위 DNS를 바꾸거나 FakeDNS를 사용하기 전에 “무엇이 언제 도메인을 조회하고, 조회 결과를 어느 출구에 전달하는지”부터 확인하세요.
서버 도메인과 대상 사이트 도메인 중 무엇을 확인해야 할까?
서버에 연결하기 전에 클라이언트가 서버 주소를 조회할 수 있고, 프록시 연결이 설정된 뒤 대상 사이트에 접근하면서 또 다른 조회가 발생할 수 있습니다. 로그에 표시된 실패 도메인이 어느 단계에 속하는지가 중요합니다. 서버 도메인 조회에 실패하면 해당 서버에 처음부터 연결할 수 없고, 대상 사이트 도메인 조회에 실패하면 일부 사이트만 열리지 않을 수 있습니다. 로그에 표시된 도메인 유형을 기록해 두고 두 문제를 막연히 “DNS 문제” 하나로 묶지 마세요.
운영체제에 기본 제공되는 조회 명령을 사용해 기기에서 도메인 레코드를 가져올 수 있는지 확인할 수 있습니다. 예시에는 이 사이트의 도메인이 사용되며 명령어 형식만 보여 줍니다. 조회 결과는 네트워크와 시간에 따라 달라지므로 고정 설정값처럼 복사하지 마세요. 명령이 성공해도 클라이언트가 같은 DNS를 사용한다는 뜻은 아닙니다. 브라우저, 운영체제, 클라이언트, TUN 환경마다 조회 경로가 다를 수 있습니다. 결과를 비교할 때는 어느 진입점에서 조회했는지 함께 기록하세요.
nslookup v2raypeizhi.com도메인과 출구를 기준으로 DNS 설정 확인
v2rayN의 DNS 및 라우팅 설정을 확인해 대상 도메인이 최종적으로 직접 연결되는지 프록시를 통하는지 파악하고, 해당 경로에서 어떤 DNS 방식을 사용하는지 살펴보세요. 직접 연결 트래픽에서 다른 네트워크에서만 접속 가능한 주소를 받거나, 프록시 트래픽이 로컬에서 부적절한 주소로 미리 조회되면 “규칙은 맞는 것 같은데 연결되지 않는” 문제가 생길 수 있습니다. 변경하기 전에 현재 DNS 설정을 백업하고, 한 번에 상위 DNS 서버 하나 또는 도메인 규칙 한 종류만 바꾸세요.
사용자 지정 DNS를 설정했다면 규칙의 적용 순서와 기본 상위 DNS를 확인하세요. 세부 도메인 규칙에 일치하지 않는 요청은 기본 경로를 따릅니다. 필요에 따라 DoH, 기존 DNS, 시스템 DNS를 함께 사용할 수 있지만 추가한 DNS 서버에도 연결 가능한 네트워크 경로가 필요합니다. 상위 DNS의 도메인 이름을 먼저 조회해야 한다면 초기 조회 경로도 고려하세요. 설정 예시와 점검 순서는 V2Ray DNS 분할 설정 자세히 보기에서 확인할 수 있습니다.
FakeDNS를 확인해야 하는 경우
FakeDNS는 도메인에 가상 주소를 할당한 다음 트래픽 스니핑을 통해 이후 연결을 도메인과 연결합니다. 기기 트래픽을 처리하면서 라우팅에 사용할 도메인 정보를 유지해야 하는 경우에 쓰이곤 하지만, DNS 오류를 모두 해결하는 만능 버튼은 아닙니다. 스니핑이 실제 트래픽을 처리하지 못하거나 앱이 조회된 실제 주소에 직접 의존하면 FakeDNS를 켠 뒤 새로운 호환성 문제가 생길 수도 있습니다.
점검할 때는 기존 설정에서 실패하는 대상을 기록한 뒤 FakeDNS 관련 설정만 따로 변경하고 같은 앱에서 다시 테스트하세요. 이 설정을 켜거나 끌 때 결과가 일관되게 바뀌는 경우에만 스니핑, 가상 주소 매핑, 라우팅 규칙을 추가로 점검하세요. 사용 원리와 적용 범위는 FakeDNS 작동 원리에서 확인할 수 있습니다. 할당된 가상 주소를 원격 서버의 실제 주소로 간주하거나 서버 항목의 address 값을 그에 맞게 변경하지 마세요.
캐시와 간헐적인 조회 차이 처리
DNS를 변경한 뒤에도 브라우저, 운영체제 또는 앱이 기존에 저장된 조회 결과를 계속 사용할 수 있습니다. 테스트 앱을 종료했다가 다시 열고 같은 네트워크에서 재확인하세요. 필요한 경우 운영체제의 DNS 캐시 삭제 기능을 사용하세요. 캐시 삭제는 오래된 응답을 지울 뿐 잘못된 상위 DNS 선택이나 라우팅 출구를 고치지는 않습니다. 잠시 뒤 문제가 다시 발생한다면 캐시 삭제를 반복하기보다 실제 요청 경로를 비교하세요.
도메인 하나만 문제가 있다면 도메인, 발생 시간, 사용한 네트워크, 라우팅 규칙 일치 결과, DNS 단계의 로그를 기록하세요. 모든 도메인이 문제라면 로컬 네트워크와 상위 DNS 서버에 접속할 수 있는지 먼저 확인하세요. 비교 중에 새로운 DoH, FakeDNS, TUN을 한꺼번에 활성화하지 마세요. 각 단계마다 “무엇을 변경했는지, 결과가 어땠는지, 설정을 되돌렸는지” 기록해야 어느 단계가 문제를 해결했는지 알 수 있습니다.
6. 시스템 프록시가 켜져 있지만 앱이 프록시를 사용하지 않음
시스템 프록시는 앱이 참고할 수 있도록 운영체제가 제공하는 프록시 설정입니다. 모든 네트워크 트래픽을 강제로 처리하는 전역 스위치는 아닙니다. v2rayN은 시스템 프록시를 설정할 수 있고 TUN으로 더 많은 트래픽을 처리할 수도 있지만, 두 방식의 적용 범위는 다릅니다. 먼저 앱이 시스템 프록시를 읽는지 확인하고, 다음으로 프록시 주소와 클라이언트의 실제 수신 주소가 일치하는지 확인한 뒤 TUN이 필요한지 판단하세요.
설정이 운영체제에 반영됐는지 확인
v2rayN에서 현재 “시스템 프록시” 설정을 확인하고 꺼져 있지 않은지 살펴보세요. 설정을 전환한 뒤 테스트할 앱을 다시 시작해 오래된 프록시 설정이나 기존 연결을 계속 사용하지 않도록 하세요. Windows의 시스템 프록시 화면에서 현재 설정이 반영됐는지 교차 확인할 수 있습니다. 이전 주소나 포트가 표시된다면 시스템 프록시를 변경하는 다른 도구가 동시에 실행 중인지 확인한 다음 v2rayN에서 다시 설정하세요.
일부 앱에는 별도의 프록시 옵션이 있어 앱 내부 설정을 우선 사용하거나 “프록시 사용 안 함”을 명시적으로 선택할 수 있습니다. 앱 설정에서 “시스템 프록시 사용”, “자동 감지”, “수동 프록시”와 같은 항목을 먼저 확인하세요. 앱이 운영체제 설정을 따른다고 단정하지 마세요. 브라우저는 작동하지만 명령줄 도구는 작동하지 않는 것은 진입점이 다른 흔한 사례입니다. 시스템 프록시 스위치만 보고 판단하지 말고 해당 도구의 프록시 설정 방식에 맞춰 점검하세요.
시스템 프록시·라우팅·TUN 구분
시스템 프록시는 시스템 설정을 따르는 앱의 트래픽을 클라이언트로 보낼지 결정하고, 라우팅은 클라이언트에 들어온 요청이 어느 출구로 나갈지 결정합니다. 로그에 대상 앱의 요청이 전혀 없다면 라우팅 규칙을 바꿔도 도움이 되지 않습니다. 먼저 “요청이 들어오는지” 해결한 다음 “들어온 요청이 어디로 가는지” 확인하세요. 반대로 로그에 요청이 나타나고 잘못된 출구와 일치했다면 시스템 프록시를 반복해서 껐다 켜지 말고 라우팅을 점검하세요.
일반 시스템 프록시를 따르지 않는 트래픽을 처리해야 할 때 TUN을 사용할 수 있지만, 실행 과정에서 시스템 권한, 가상 네트워크 인터페이스, 다른 네트워크 소프트웨어와의 호환성 문제가 발생할 수 있습니다. 먼저 시스템 프록시만 켠 상태에서 반복 가능한 테스트를 진행한 다음 TUN을 켜고 결과를 비교하세요. TUN을 켜자마자 인터넷이 끊기면 바로 끄고 클라이언트 로그, 권한, 다른 가상 네트워크 어댑터를 확인하세요. 같은 라우팅 경로를 동시에 처리하는 도구를 여러 개 실행하지 마세요.
플랫폼별 프록시 진입점 이해
데스크톱에서는 주로 v2rayN을 사용하지만 운영체제와 앱마다 시스템 프록시를 따르는 방식은 다릅니다. 점검할 때는 같은 앱에서 설정을 켜기 전후로 비교하고 클라이언트 로그에 해당 앱의 요청이 표시되는지 확인하세요. 아래 표는 점검 방향을 정하기 위한 것으로, 모든 앱이 같은 방식으로 프록시를 사용한다고 보장하지 않습니다. 실제 동작은 앱 설정과 로그를 기준으로 판단해야 합니다.
| 환경 | 먼저 확인할 항목 | 추가 확인 방법 |
|---|---|---|
| Windows · v2rayN | 시스템 프록시 상태, 앱 자체 프록시 설정 | 클라이언트 로그에 앱 요청이 표시되는지 |
| macOS · v2rayN | 현재 네트워크 연결의 프록시 설정 | 네트워크를 전환한 뒤 설정 다시 확인 |
| Linux · v2rayN | 데스크톱 환경과 앱별 프록시 옵션 | 앱이 해당 설정을 읽는지 비교 |
| Android · v2rayNG / v2flyNG | 연결 상태, VPN 권한 | 앱을 전면에 두고 요청이 복구되는지 테스트 |
기존 설정을 정리한 뒤 다시 테스트
클라이언트가 비정상 종료된 뒤에도 운영체제에 로컬 프록시 포트 설정이 남을 수 있습니다. 클라이언트가 더 이상 수신하지 않는데 앱이 해당 주소로 트래픽을 보내면 클라이언트를 종료한 뒤 웹페이지도 열리지 않을 수 있습니다. v2rayN을 다시 시작하고 시스템 프록시를 정상적으로 끄거나 운영체제 네트워크 설정에서 기존 프록시를 확인해 삭제하세요. 그런 다음 직접 연결이 복구됐는지 확인하세요. 알 수 없는 프록시 주소가 활성화된 상태에서 설정 디렉터리를 바로 삭제하지 마세요.
네트워크 전환, 절전 모드 해제, 다른 네트워크 도구 실행 후 문제가 다시 발생한다면 어떤 동작이 시스템 프록시 설정을 변경했는지 기록하세요. 마지막으로 직접 연결, 시스템 프록시, 대상 앱을 각각 테스트하세요. 직접 연결은 정상인지, 클라이언트가 요청을 받는지, 라우팅 출구가 예상과 일치하는지 확인하면 됩니다. 이 순서대로 얻은 세 가지 결과가 “프록시를 켰는데 작동하지 않는다”는 설명보다 다음 점검 단계를 정확히 찾는 데 도움이 됩니다.
7. 클라이언트가 시작되지 않거나 충돌함, 코어 실행 실패
인터페이스가 열리지 않는 문제와 인터페이스는 열리지만 코어가 시작되지 않는 문제는 서로 다릅니다. 먼저 실패 단계가 어디인지 확인하세요. 아이콘을 두 번 눌러도 창이 나타나지 않는지, 창이 열렸다가 바로 닫히는지, 설정을 가져온 뒤 종료되는지, 연결을 눌렀을 때 코어 오류가 발생하는지 살펴보세요. 로그와 현재 설정을 보존한 다음 설치 환경과 설정 오류를 점검하세요. 모든 사용자 데이터를 삭제하고 다시 설치하는 것부터 시작하지 마세요.
설치 파일과 실행 환경 확인
운영체제와 프로세서 아키텍처에 맞는 클라이언트를 설치했는지 확인하세요. 데스크톱에서는 v2rayN을 우선 사용하세요. Windows 사용자는 다운로드 센터의 Windows 섹션에서 데스크톱 버전과 클래식 WPF 버전을 구분할 수 있습니다. macOS와 Linux 사용자는 각 플랫폼에 맞는 파일을 선택해야 합니다. 정상적인 읽기·쓰기 권한이 있는 위치에 앱을 두고 권한이 제한되거나 읽기 전용인 위치에서 실행하지 마세요. 다운로드가 완료되기 전에 파일을 열어서도 안 됩니다.
업데이트 후에 시작 문제가 발생했다면 업데이트 전후에 한 작업, 설치 방식, 오류 내용을 먼저 기록하고 기존 프로세스가 실행 중인지 확인하세요. 여러 인스턴스를 반복 실행하면 수신 포트가 충돌할 수 있습니다. 시스템 작업 관리 도구에서 응답하지 않는 기존 인스턴스를 종료한 뒤 한 번만 실행해 보세요. 재설치 전에 구독 그룹과 직접 편집한 설정을 저장해 프로그램 시작 문제가 설정 손실로 이어지지 않도록 하세요.
인터페이스는 정상적으로 열리지만 코어에서 오류가 발생함
v2rayN 로그를 열고 설정 해석, 포트 수신, 코어 시작 관련 첫 번째 명확한 오류를 확인하세요. 포트가 사용 중이라면 다른 클라이언트 인스턴스나 로컬 소프트웨어가 해당 진입점을 사용 중인지 찾으세요. 설정 해석 오류라면 최근 수정한 서버 필드, 라우팅, DNS 설정을 확인하세요. 로그 맨 끝의 “시작 실패”만 복사하지 마세요. 대개 앞서 발생한 구체적인 오류의 결과일 뿐입니다.
수동으로 수정하지 않은 다른 서버를 임시로 선택하고 최근 추가한 사용자 지정 규칙을 비활성화한 뒤 다시 테스트할 수 있습니다. 정상적으로 시작되면 원래 설정을 하나씩 복원해 어느 항목에서 오류가 발생하는지 찾으세요. 다른 코어를 사용할 때는 선택한 프로토콜과 매개변수가 해당 코어에서 지원되는지도 확인해야 합니다. Xray와 V2Fly의 모든 기능이 서로 대응되는 것은 아닙니다. 차이점은 Xray와 V2Fly 코어 차이에서 확인할 수 있습니다.
권한·보안 소프트웨어·설정 손상 점검
로그에 파일 읽기나 쓰기 실패가 표시되면 프로그램 및 설정 디렉터리의 권한과 디스크 여유 공간을 확인하세요. 보안 소프트웨어가 차단 알림을 표시하면 실제 파일, 작업, 시각을 확인해 이번 시작 오류와 관련이 있는지 판단하세요. 문제를 찾겠다고 시스템 보호 기능을 계속 꺼 두지 마세요. 설치 위치를 바꿔야 한다면 먼저 구독 정보와 사용자 지정 설정을 백업한 다음 올바른 플랫폼용 설치 파일로 다시 설치하세요.
기존 설정을 불러올 때만 프로그램이 종료된다면 전체 백업을 보존한 상태에서 깨끗한 설정으로 인터페이스가 열리는지 테스트하세요. 깨끗한 설정에서는 시작된다면 기존 설정이나 참조 파일이 원인일 가능성이 큽니다. 그래도 시작되지 않는다면 설치 환경과 시스템 로그를 더 자세히 확인해야 합니다. 구독 주소가 포함된 전체 설정 파일을 공개하지 마세요. 도움을 요청할 때는 민감한 필드를 가린 오류 정보만 제공할 수 있습니다.
재현 가능한 복구 순서 만들기
먼저 인터페이스가 안정적으로 열리는지 확인하고, 다음으로 코어가 시작되는지 확인하세요. 그 후 근거가 있는 서버 설정 하나를 가져오고 마지막으로 구독, 라우팅, 사용자 지정 DNS 설정을 복원하세요. 각 단계를 복원할 때마다 시작해 로그를 확인하면 어느 단계에서 문제가 다시 발생하는지 찾을 수 있습니다. 기존 설정을 한꺼번에 가져온 뒤 문제가 재현되면 원인이 무엇인지 알기 어렵습니다. 복구 순서 자체가 진단 과정입니다.
문제를 해결한 뒤 시스템 프록시가 현재 실행 중인 클라이언트를 가리키는지, 프로그램을 종료한 뒤 시스템 프록시도 정상적으로 꺼지는지 확인하세요. 충돌과 프록시 설정 잔류는 연이어 나타날 수 있지만 각각 따로 해결해야 합니다. 전자는 프로그램과 설정을, 후자는 운영체제의 프록시 상태를 확인하세요. 일반적인 설치 질문은 도움말에서 확인할 수 있습니다. 처음부터 설정해야 한다면 가이드의 순서대로 진행하세요.
8. Android 연결·백그라운드 실행·앱별 라우팅
Android에서는 먼저 v2rayNG를 확인하세요. V2Fly 코어에 대응하는 클라이언트가 필요한 경우 v2flyNG를 사용할 수 있습니다. 두 클라이언트 모두 다운로드 센터의 Android 섹션에서 기기 아키텍처에 맞는 설치 파일을 선택해야 합니다. 데스크톱의 “시스템 프록시 설정” 점검 방법을 휴대전화에 그대로 적용할 수는 없습니다. Android 클라이언트는 주로 시스템 VPN 권한을 통해 기기의 트래픽 진입점을 만들며, 백그라운드 제한과 앱별 라우팅 설정에도 영향을 받습니다.
연결 버튼을 눌렀다면 먼저 VPN 권한 확인
클라이언트에서 서버를 선택한 뒤 연결을 시작하고 시스템에 VPN 연결 요청이 표시되는지 확인하세요. 처음 사용하거나 재설치했거나 권한이 변경된 경우 권한을 다시 확인해야 할 수 있습니다. 클라이언트에 연결 중이라고 표시되지만 시스템 VPN 상태가 안정적으로 유지되지 않는다면 권한 요청 절차가 완료됐는지, 다른 VPN 서비스가 이미 진입점을 사용 중인지 확인하세요. 같은 종류의 서비스를 빠르게 번갈아 전환하지 말고 하나를 먼저 중지한 뒤 테스트하세요.
연결 상태로 표시되지만 모든 앱에 접속할 수 없다면 클라이언트 로그에서 서버 주소, 포트, 전송 계층 설정을 확인한 뒤 정상 작동이 확인된 다른 서버와 비교하세요. Wi-Fi에서 모바일 네트워크로 바꾸면 기존 연결이 끊길 수 있으므로 요청을 다시 보내 복구되는지 확인하세요. 같은 설정이 한 네트워크에서만 실패한다면 휴대전화의 모든 서버를 먼저 삭제하지 말고 해당 네트워크 조건을 기록하세요.
특정 앱만 연결되지 않음
클라이언트의 앱별 프록시 또는 우회 설정에서 문제가 있는 앱이 제외되어 있는지 확인하세요. 다음으로 앱이 백그라운드에서만 접속되지 않는지, 전면에 표시해도 접속되지 않는지 살펴보세요. 전면에서도 실패한다면 앱별 라우팅과 앱 자체 네트워크 설정을 확인하는 것이 좋습니다. 백그라운드에서만 실패한다면 시스템의 백그라운드 활동 제한도 살펴봐야 합니다. 일부 앱은 프록시 전환 전에 맺은 연결을 계속 사용할 수 있으므로 완전히 종료한 뒤 다시 열어 비교하세요.
브라우저는 접속되지만 특정 앱은 안 된다고 해서 서버가 고장 났다고 단정하지 마세요. 같은 서버와 네트워크를 유지한 채 두 앱을 각각 테스트하고 클라이언트 로그에 요청이 들어오는지 확인하세요. 요청 기록이 없다면 앱별 라우팅, VPN 트래픽 처리, 시스템 권한을 점검하세요. 요청은 있지만 다른 출구 규칙과 일치한다면 라우팅 설정을 확인하세요. 앱마다 DNS 조회 방식이 다를 수도 있으므로 필요한 경우 이 페이지의 DNS 섹션과 함께 비교하세요.
화면을 잠그거나 백그라운드로 전환한 뒤 연결이 끊김
휴대전화 시스템은 백그라운드 활동이나 절전 상태의 네트워크 연결을 제한할 수 있습니다. 먼저 클라이언트를 전면에 둔 상태에서 안정적인지 테스트한 뒤 일정 시간 화면을 잠가 다시 확인하세요. 백그라운드에서만 문제가 발생한다면 해당 클라이언트의 배터리 관리, 백그라운드 실행, 알림 권한을 확인하세요. 기기마다 메뉴 이름이 다를 수 있으므로 다른 브랜드의 설정 경로를 그대로 따라 하지 말고 현재 시스템 화면에서 해당 설정을 찾으세요.
백그라운드 실행을 허용해도 Wi-Fi와 모바일 데이터 간 전환 시 연결을 다시 맺어야 할 수 있습니다. 끊긴 시점에 네트워크 전환이 있었는지, 절전 모드가 켜져 있었는지, 클라이언트가 계속 실행 중으로 표시됐는지 기록하세요. 시스템 설정은 하나씩만 바꾸고 다시 테스트해 백그라운드 연결을 유지하려고 관련 없는 제한을 여러 개 한꺼번에 끄지 않도록 하세요. 복구된 뒤에는 일상적인 사용에서 배터리 소모가 감당할 만한지도 확인하세요.
구독 및 두 클라이언트의 설정 차이
Android에서 구독 업데이트가 실패해도 먼저 가져오기 실패, 내용 해석 실패, 목록 필터링을 구분하세요. 구독 주소를 복사할 때 공백이나 줄바꿈이 포함되지 않도록 하고 공개 스크린샷에 전체 주소가 보이지 않게 하세요. v2rayNG에서 특정 코어 기능에 의존하는 설정을 사용 중이라면 v2flyNG로 가져왔을 때 동작이 완전히 같다고 가정하지 마세요. 실제 프로토콜 매개변수와 클라이언트 로그를 바탕으로 호환성을 판단해야 합니다.
점검을 마칠 때 선택한 서버, VPN 상태, 앱별 라우팅, 백그라운드 권한, 현재 네트워크를 확인하고 최종 적용된 설정을 항목별로 기록하세요. 데스크톱과 휴대전화에서 같은 구독을 사용하는데 결과가 다르면 구독을 바로 수정하지 말고 각 기기의 네트워크와 코어 기능을 먼저 비교하세요. 세 클라이언트의 지원 플랫폼과 용도는 클라이언트 비교에서 확인할 수 있습니다. 기본 가져오기 절차는 가이드부터 시작하세요.