V2Ray 문제 해결
연결·구독·시스템 프록시

인터넷에 연결되지 않을 때: 어느 구간에서 끊기는지 확인

모든 웹페이지가 열리지 않아도 설정을 바로 삭제하지 마세요. 일반적인 연결은 앱, 트래픽 처리 진입점, 로컬 코어, 원격 서버, 대상 사이트를 거칩니다. 실행 중 표시만으로는 클라이언트가 작동 상태에 들어갔다는 사실만 알 수 있으며, 모든 구간의 연결이 정상이라는 뜻은 아닙니다. 다른 프록시 도구를 종료하고 TUN을 잠시 끈 다음 시스템 프록시를 ‘프록시 사용 안 함’으로 설정하세요. 평소 직접 접속되는 사이트를 열어 기본 네트워크, 무선 인증, 기본 게이트웨이가 정상인지 확인하세요.

먼저 직접 연결을 확인한 다음 로컬 포트를 점검하세요

프록시를 해제해도 접속되지 않는다면 네트워크 로그인 필요 여부, 시스템 시각, 같은 네트워크에 연결된 다른 기기의 상태를 확인하세요. 이 단계에서 서버를 계속 바꾸는 것은 대개 도움이 되지 않습니다. 직접 연결이 복구되면 v2rayN을 실행해 기존 서버를 선택하고 ‘서비스 다시 시작’을 누른 뒤 로그에서 코어 종료, 설정 파싱 실패, 포트 수신 대기 실패 여부를 확인하세요. 시스템 트레이 아이콘만 보지 마세요. 창은 열려 있어도 코어가 종료되면 브라우저는 존재하지 않는 로컬 서비스에 연결을 시도하게 됩니다.

‘설정’에서 ‘매개변수 설정’을 열고 ‘로컬 혼합 포트’를 기록하세요. 아래 명령은 포트가 10808로 설정된 경우를 예로 듭니다. 다른 포트를 사용한다면 먼저 명령을 수정하세요. 수신 대기 중인지 확인하고 프로세스와 대조하세요. 해당 포트를 점유한 프로그램을 모두 정상 코어로 간주하면 안 됩니다. 수신 대기가 확인되어도 로컬 진입점이 만들어졌다는 뜻일 뿐이므로, 다음 단계에서 원격 연결을 확인해야 합니다.

# Windows PowerShell: 수신 대기 주소, 포트 및 프로세스 확인
Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# 로컬 HTTP 프록시로 명시적인 요청 보내기
curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:10808 https://example.com/

명령에 표시된 대상은 요청 형식을 보여 주기 위한 예시이며 현재 네트워크에서 접속 가능하다는 보장은 없습니다. 실제 점검에는 접속 가능 여부를 알고 있고 사용이 허용된 대상을 선택해 전후 테스트에서 동일하게 사용하세요. 대상 서버에서 HTTP 응답을 받았다면 거부 또는 리디렉션 응답이라도 연결 시간 초과와는 다릅니다. 요청이 어떤 HTTP 서비스까지 도달했다는 뜻입니다. 인증서 오류가 발생하면 시스템 시각, 대상 이름, 인증서 체인을 확인하세요. 인증서 검증을 끄는 방식으로 오류를 숨기지 마세요.

추측 대신 테스트 결과에 따라 다음 단계를 결정하세요

명시적 프록시 요청이 성공하면 ‘시스템 프록시 자동 설정’을 선택하고 브라우저를 완전히 종료했다가 다시 열어 테스트하세요. 그래도 실패하면 프록시 확장 프로그램이 없는 다른 브라우저로 비교하세요. 한 앱에서만 문제가 발생한다면 해당 앱의 프록시, 캐시, 네트워크 권한을 확인하세요. 모든 앱에서 문제가 발생하면 시스템의 트래픽 처리 설정을 점검하세요. 시크릿 창에서도 모든 확장 프로그램이 비활성화되는 것은 아니므로 확장 프로그램의 영향을 완전히 배제할 수는 없습니다.

일부 사이트만 접속되지 않으면 실패한 도메인, 오류 유형, 발생 시각을 기록하고 직접 연결 규칙이 적용됐는지 확인하세요. 라우팅을 잠시 바꾸는 것은 비교 테스트로만 사용하고, 문제를 감추려고 모든 트래픽을 계속 같은 경로로 보내지 마세요. 기존 규칙을 복구한 뒤 대상 도메인 일치 여부, DNS 응답, 규칙 순서를 확인하세요. 라우팅을 바꾼 뒤에는 새 연결을 만들어야 합니다. 기존 연결은 이전 출구 경로를 계속 사용할 수 있으므로 바로 새로고침해도 변경 결과가 반영되지 않을 수 있습니다.

이번 점검을 마칠 때 ‘직접 연결 정상 여부, 로컬 수신 대기 여부, 명시적 프록시 성공 여부, 앱의 프록시 사용 여부’를 기록하세요. ‘인터넷이 안 된다’는 한마디보다 문제를 이어서 찾는 데 도움이 됩니다. 개별 질문은 문제 해결 FAQ에서 확인하세요. 수신 포트를 만들 수 없다면 로컬 포트 점유 문제 해결을 참고하고 클라이언트를 반복해서 재설치하지 마세요.

서버 시간 초과: 전송 연결과 프로토콜 핸드셰이크 구분

서버 테스트에서 시간 초과가 표시되어도 서버가 중지됐다고 단정할 수 없습니다. DNS 조회, 연결 수립, 암호화 핸드셰이크, 테스트 대상의 응답 대기 중 어느 단계에서든 멈출 수 있습니다. 먼저 테스트 대상과 방식을 확인하세요. 특정 테스트 사이트에 접속할 수 없다는 이유만으로 모든 요청이 실패한다고 판단하지 마세요. 현재 서버 설정은 유지하고 같은 구독에 있는 다른 정상 서버와 비교하세요. 구독 새로고침, 코어 변경, 전송 매개변수 수정을 한꺼번에 하지 마세요. 무엇이 결과를 바꿨는지 알 수 없게 됩니다.

로그를 순서대로 확인해 최초 오류를 찾으세요

서버 주소와 포트가 빠짐없이 입력됐는지 먼저 확인하세요. 복사 과정에서 공백이나 줄바꿈이 들어가거나 포트 번호가 잘리지 않았는지 특히 살펴보세요. 도메인 이름 확인에 실패했다면 먼저 DNS를 점검하세요. 연결이 거부되면 해당 주소에 서비스가 없거나 중간 장비가 연결을 거부했을 수 있습니다. 연결 시간 초과는 정해진 시간 안에 연결이 완료되지 않았다는 뜻일 뿐, 원인이 발생한 위치를 알려 주지는 않습니다. 관련된 첫 오류를 기록하세요. 뒤이어 나타나는 연결 취소 메시지는 첫 실패에 따른 연쇄 오류일 수 있습니다.

Windows에서는 일반 TCP 연결로 원격 포트에 연결할 수 있는지 확인할 수 있습니다. 아래 예시는 PowerShell에서 기존 설정의 주소와 포트를 입력받으므로 실제 정보를 명령 기록에 남기지 않습니다. 테스트 성공은 TCP 계층에 도달할 수 있다는 뜻일 뿐, 인증 정보·전송 경로·TLS 매개변수가 올바르다는 보장은 아닙니다. 실패해도 서버가 손상됐다는 뜻은 아닙니다. UDP만 사용하는 연결에는 이 방법을 적용할 수 없습니다. 테스트 결과는 확인한 프로토콜 범위에서만 해석하세요.

$server = Read-Host "기존 설정에 있는 서버 주소 입력"
$port = [int](Read-Host "기존 설정에 있는 서버 포트 입력")
Test-NetConnection -ComputerName $server -Port $port -InformationLevel Detailed

일반 연결은 성공하지만 클라이언트에서 핸드셰이크 실패가 표시되면 프로토콜과 전송 계층 매개변수를 확인하세요. VMess, VLESS, Trojan의 인증 항목은 서로 바꿔 쓸 수 없습니다. WebSocket의 경로와 Host, gRPC 서비스 이름은 서버 설정과 일치해야 합니다. TLS를 사용한다면 연결 주소와 서버 이름이 다를 수 있으므로 주소에 IP를 입력했다는 이유만으로 서버 이름을 지우지 마세요. REALITY 설정의 공개 키, 짧은 ID 및 관련 매개변수도 올바른 설정에서 가져와야 합니다. 다른 서버 설정을 참고해 값을 조합하지 마세요.

시각, 네트워크, 코어를 각각 확인하세요

인증서가 아직 유효하지 않거나 만료됐다는 오류, 인증 시간이 관련된 오류가 표시되면 시스템 날짜와 시간대, 자동 시간 동기화 상태를 먼저 확인하세요. 시간이 잘못되면 인증서와 일부 인증 절차에 영향을 줄 수 있지만, 시각 변경이 모든 시간 초과 문제를 해결하는 것은 아닙니다. 인증서 이름이 일치하지 않으면 서버 이름과 설정 출처를 확인하세요. 인증서 검증을 건너뛰는 설정을 장기적인 해결책으로 사용하지 마세요. 회사 네트워크에 인증이 필요하거나 관리되는 보안 소프트웨어가 있다면 보안을 끄기 전에 연결 정책을 확인하세요.

다른 네트워크에서 재시험할 때는 클라이언트, 서버, 대상을 그대로 유지하세요. 사용이 허용된 모바일 핫스팟에서 같은 요청을 한 뒤 원래 네트워크에서도 테스트할 수 있습니다. 특정 네트워크에서만 실패한다면 네트워크 인증, 외부 연결 제한, IP 주소 계열의 연결 가능성을 중점적으로 확인하세요. 모든 네트워크에서 실패하지만 다른 서버는 정상이라면 해당 서버의 상태와 매개변수를 점검하세요. 듀얼 스택 네트워크에서는 DNS가 연결 경로가 없는 IPv6 주소를 반환할 수 있지만, 이를 이유로 기기 전체의 IPv6를 영구적으로 끄지는 마세요.

Xray 또는 다른 지원 코어로 바꾸기 전에 해당 코어에서 서버 프로토콜과 전송 방식이 지원되는지 확인하세요. 그래픽 인터페이스에서 항목을 저장할 수 있어도 모든 코어가 같은 의미로 처리한다는 뜻은 아닙니다. 구독과 클라이언트에 원래 맞춰진 조합을 우선 사용하고, 기존 설정을 보관한 뒤 하나씩 테스트하세요. 새 설정을 가져온 뒤 문제가 발생했다면 이전에 작동했던 설정과 비교할 수 있습니다. 다만 취소되거나 만료된 인증 정보는 신뢰할 수 있는 기준으로 사용하지 마세요.

설정 제공자에게 결과를 전달할 때는 발생 시각, 네트워크 종류, 프로토콜, TCP 연결 가능 여부, 민감한 정보를 삭제한 최초 오류 메시지를 함께 알려 주세요. 구독 전체나 인증 정보가 포함된 화면을 보내지 마세요. 일부 대상에만 연결되는 서버라면 출구 라우팅과 DNS도 확인해야 합니다. 모든 대상이 같은 단계에서 실패하는 것을 확인한 뒤에야 서버 자체 문제로 판단할 수 있습니다. 연결이 복구되면 임시 로그 수준을 해제하고 테스트용 라우팅을 원래대로 돌리세요.

구독 실패: 가져오기·파싱·적용 단계별 점검

구독 업데이트 실패는 주소에서 내용을 가져오지 못한 경우, 내용은 가져왔지만 형식을 인식하지 못한 경우, 목록은 갱신됐지만 선택된 서버가 작동하지 않는 경우로 나뉩니다. 로그가 어느 단계에서 멈췄는지 확인한 다음 ‘구독 그룹 설정’에서 대상 그룹을 점검하세요. 같은 이름의 그룹을 계속 만들거나 오류를 정리하려고 마지막으로 남은 정상 설정을 삭제하지 마세요. 업데이트 전에 그룹 이름, 서버 수의 변화, 현재 선택 항목을 기록하세요. 그래야 업데이트 후 선택이 바뀐 것을 구독 전체가 작동하지 않는 것으로 오해하지 않습니다.

주소가 유효하고 설정 내용을 가져오는지 확인하세요

주소가 완전한지 먼저 확인하세요. 쿼리 매개변수, 대소문자, 마지막 문자가 요청에 영향을 줄 수 있습니다. 구독 주소는 접근 권한이 포함된 경우가 많으므로 계정 정보처럼 안전하게 보관하고 공개 문의, 스크린샷, 온라인 변환 도구에 입력하지 마세요. 웹페이지의 버튼에서 주소를 가져온 경우 계정 페이지나 QR 코드 이미지 주소, 브라우저 리디렉션 주소가 아니라 구독 링크를 복사했는지 확인하세요. 브라우저에서 응답 내용을 확인하는 것은 참고 자료일 뿐입니다. 브라우저 접속 성공이 클라이언트에서도 같은 응답을 받는다는 뜻은 아닙니다.

인증되지 않음, 접근 거부, 리소스를 찾을 수 없음과 같은 응답이 오면 구독 만료 여부, 토큰 초기화 여부, 주소 변경 여부를 확인하세요. 이 경우 DNS를 여러 번 바꿔도 권한 문제가 해결되지는 않습니다. 응답이 로그인 페이지, CAPTCHA 페이지, 점검 안내라면 상태 코드상 요청이 성공했더라도 서버 설정 내용은 아닙니다. 설정 제공자에게 올바른 주소를 요청하세요. 웹페이지 내용을 수동으로 인코딩해 클라이언트에 가져오지 마세요.

요청 시간 초과가 발생하면 업데이트 경로를 구분하세요. 기존 연결이 정상이라면 프록시를 통해 업데이트할 수 있습니다. 사용 가능한 서버가 없다면 메뉴의 ‘프록시를 사용하지 않고 구독 업데이트’에 해당하는 경로를 시도하세요. 두 경로를 무조건 모두 켜는 것이 아니라 구독 서버에 접근할 수 있는 경로를 선택해야 합니다. 업데이트 요청에 사용되는 경로는 브라우저와 다를 수 있습니다. 브라우저 확장 프로그램, 시스템 프록시, TUN 조합 때문에 비교 결과가 잘못 해석될 수도 있습니다.

형식과 업데이트 후 선택 항목을 확인하세요

클라이언트마다 지원하는 구독 형식과 확장 매개변수가 다릅니다. 전용 규칙이 많이 포함된 전체 설정 파일을 서버 구독으로 바로 가져올 수 있는 것은 아닙니다. 가져오기에 성공해도 모든 확장 항목이 유지된다는 보장은 없습니다. v2rayN 또는 Android 클라이언트용이라고 명시된 형식을 우선 요청하세요. 변환이 필요하면 어떤 항목이 변환되는지 확인하고 신뢰할 수 있는 환경에서 처리하세요. 특히 전송 계층, TLS, REALITY 매개변수가 누락되지 않았는지 확인하세요.

업데이트 후 서버가 사라졌다면 구독 내용이 비어 있다고 단정하기 전에 그룹 필터와 검색창을 확인하세요. 공백이나 대소문자가 다른 필터 키워드가 사용 가능한 항목을 모두 숨길 수 있습니다. 임시 검색어를 지우고 예상한 그룹이 실제로 업데이트됐는지 확인하세요. 구독이 기존 서버를 대체했다면 이전 선택 항목이 없어졌을 수 있습니다. 목록에서 서버 하나를 다시 선택하고 서비스를 재시작한 뒤, 그룹 업데이트 메시지만 확인하지 말고 명시적 프록시 요청으로 검증하세요.

자동 업데이트 간격을 설정하기 전에 수동 업데이트를 한 번 완료하고 경로가 안정적인지 확인하세요. 간격이 너무 짧으면 요청이 반복되고 서버 측 제한이 적용될 수 있습니다. 기기가 절전 상태이거나 네트워크가 끊겼거나 백그라운드 작업이 중지되면 타이머가 실제 시각에 맞춰 작동하지 않을 수 있습니다. 예약 업데이트를 한 번 놓쳤다고 여러 새로고침 작업을 동시에 켜지 마세요. 특정 그룹에서 자주 실패한다면 수동 업데이트로 잠시 되돌리고 실패 시각과 응답을 기록한 뒤 네트워크와 권한을 점검하세요.

수동 업데이트는 성공하지만 자동 업데이트는 실패한다면 기기에서 깨어난 시각, 네트워크 전환, 업데이트 시점의 프록시 상태를 비교하세요. 모든 클라이언트가 같은 시각에 실패한다면 주소와 서버 상태를 확인하세요. 문제 기록에는 오류 유형만 남기고 전체 구독 URL은 저장하지 마세요. 그룹 업데이트 방식과 간격은 구독 업데이트 실패 및 자동 새로고침 설정에서 확인할 수 있습니다. 주소 업데이트가 성공했는데도 시간 초과가 발생한다면 운에 맡기고 반복 새로고침하지 말고 연결 단계로 돌아가세요.

속도 저하: 지연 시간·전송 속도·패킷 손실 구분

웹페이지 첫 화면이 늦게 뜨는 현상, 파일 다운로드가 느린 현상, 동영상이 간헐적으로 멈추는 현상은 서로 다른 문제입니다. 첫 요청이 오래 걸리는 이유는 DNS 조회, 연결 수립, 핸드셰이크일 수 있습니다. 지속적인 다운로드 속도 저하는 원격 출구, 대상 사이트, 무선 네트워크, 기기 부하의 영향을 함께 받을 수 있습니다. ‘처음 열 때만 느리고 새로고침하면 정상’ 또는 ‘큰 파일은 모두 느림’처럼 반복해서 확인할 수 있는 증상을 먼저 정리하세요. 한 번의 지연 시간 테스트 결과로 서버 순위를 정해 원인을 단정하지 마세요. 왕복 시간이 짧다고 전송 속도가 빠른 것은 아닙니다.

테스트 조건을 고정하고 경로를 비교하세요

같은 시간대에 같은 대상과 파일을 선택해 비교하고 클라우드 동기화, 시스템 다운로드, 네트워크를 사용하는 다른 작업은 일시 중지하세요. 직접 연결 대상과 프록시 연결 대상이 다르면 경로 차이만 비교할 수 없습니다. 콘텐츠 전송 서버가 달라져 결과가 달라질 수도 있습니다. 먼저 한 서버에서 두세 번 반복한 뒤 다른 서버로 바꾸세요. 여러 속도 테스트를 동시에 실행하지 마세요. 테스트 자체가 대역폭을 점유해 정상 연결도 느린 것처럼 보일 수 있습니다.

아래 명령은 응답 내용을 버리고 요청 단계별 소요 시간과 평균 다운로드 속도만 출력하므로 소규모 반복 테스트에 적합합니다. 대상과 포트는 실제 환경에 맞게 조정하세요. HTTP 프록시를 거치면 이름 확인 및 연결 지표의 의미가 프록시 프로토콜에 따라 달라집니다. 각 항목을 원격 DNS 또는 원격 서버의 독립적인 소요 시간으로 해석하면 안 됩니다. 작은 페이지의 평균 다운로드 속도는 핸드셰이크 비중의 영향을 크게 받으므로 대용량 파일의 최대 속도를 추정하는 데도 적합하지 않습니다.

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --output NUL --silent --show-error --write-out "connect=%{time_connect} start=%{time_starttransfer} total=%{time_total} speed=%{speed_download}\n" https://example.com/

연결 자체는 매번 빠르지만 첫 바이트를 받기까지 오래 걸린다면 대상 서비스의 응답과 원격 출구를 확인하세요. 첫 바이트는 정상인데 전송 중 반복해서 멈춘다면 무선 신호, 패킷 손실, 시스템 리소스를 살펴보세요. 일반 ping 요청이 거부되어도 실제 서비스 연결이 실패한 것은 아닙니다. ping이 계속 성공해도 암호화된 연결에 문제가 없다는 뜻은 아닙니다. 실제 사용 중인 프로토콜로 요청을 먼저 테스트하고, 네트워크 진단 도구는 참고 자료로만 활용하세요. 단일 수치로 전체 사용 결과를 대신하지 마세요.

로컬 리소스와 트래픽 처리 방식의 영향 확인

작업 관리자 또는 시스템 모니터에서 코어 프로세스의 CPU와 메모리 사용량, 디스크 활동을 확인하세요. 오래된 기기, 절전 모드, 발열 제한은 암호화와 트래픽 전달 성능에 영향을 줄 수 있습니다. 로그 상세 수준을 높게 유지하면 디스크 쓰기가 늘어날 수도 있습니다. 일반 로그 수준으로 되돌리고 불필요한 백그라운드 작업을 종료한 뒤 다시 테스트하세요. 리소스를 아끼려고 보안 소프트웨어를 함부로 끄지 마세요. 높은 사용량을 모두 클라이언트 탓으로 돌리지 말고 당시 실제 트래픽도 함께 확인하세요.

명시적 프록시, 시스템 프록시, TUN을 각각 테스트하되 매번 한 가지 경로만 활성화하세요. TUN에서만 느리다면 가상 네트워크 어댑터, 라우팅 충돌, 다른 네트워크 필터 프로그램을 확인하세요. 대용량 파일이나 특정 연결에서만 멈춘다면 기본값을 유지한 채 MTU 호환성을 점검할 수 있습니다. 온라인에서 찾은 값을 그대로 장기간 사용하지 마세요. MTU 변경 후에는 연결을 새로 만들고 여러 대상으로 확인해야 합니다. 작은 페이지가 정상이라고 문제가 해결된 것은 아닙니다.

동영상 끊김은 대상 사이트의 속도 제한, 콘텐츠 전송 위치, 앱 자체의 버퍼링 방식 때문일 수도 있습니다. 한 서버에서 특정 사이트만 느리고 다른 사이트는 정상이라면 바로 재설치하지 말고 대상별 라우팅과 출구를 확인하세요. 브라우저의 보안 DNS, 확장 프로그램, 캐시 때문에 브라우저와 명령줄 도구의 경로가 다를 수 있습니다. 앱이 UDP를 사용한다면 일반 웹페이지의 TCP 테스트만으로 실제 동작을 확인할 수 없습니다. 비교할 때 앱, 대상, 전송 유형을 함께 기록하세요.

저녁에만 느리고 낮에는 정상이며 기기 리소스와 무선 연결이 안정적이라면 시간대별 혼잡을 원인 후보로 두고 검증하세요. 다른 네트워크에서 정상으로 돌아오면 로컬 접속 경로를 더 자세히 비교하세요. 설정을 바꾸자마자 한 번 빨라졌다고 개선 원인을 단정하지 말고 기존 설정으로 되돌려 반대 방향 테스트를 한 번 이상 수행하세요. 개선이 반복해서 확인된 뒤 필요한 변경만 유지하세요. 규칙이 복잡할수록 빨라지는 것은 아닙니다. 프록시 중복과 불필요한 필터를 줄이는 편이 여러 ‘속도 향상’ 설정을 덧붙이는 것보다 안정적인 결과를 얻기 쉽습니다.

DNS 문제: 대상 도메인을 어느 곳에서 조회하는지 확인

먼저 DNS 응답을 확인한 다음 캐시를 처리하세요

먼저 DNS 조회 결과를 확인한 뒤 캐시를 정리하세요

Windows에서는 아래 명령으로 시스템 DNS 응답을 조회하고 각 네트워크 인터페이스의 DNS 설정도 확인할 수 있습니다. 유선, 무선, 가상 어댑터가 동시에 존재할 수 있으며 실제 시스템에서 선택한 경로가 현재 확인 중인 어댑터와 다를 수도 있습니다. 주소가 여러 개 반환되는 것 자체는 오류가 아닙니다. 콘텐츠 전송 네트워크와 듀얼 스택 서비스는 여러 레코드를 제공할 수 있습니다. 조회 실패 여부, 예상하지 못한 사설 IP 주소가 있는지, 현재 네트워크에서 해당 주소에 연결할 수 있는지를 확인하세요.

# Windows PowerShell: 시스템 DNS 조회 및 인터페이스 DNS 확인
Resolve-DnsName example.com
Get-DnsClientServerAddress

# DNS 설정을 수정한 뒤 필요한 경우 시스템 캐시 삭제
Clear-DnsClientCache

캐시는 설정을 수정한 다음에 지우세요. 상위 DNS에 문제가 남아 있으면 캐시를 삭제해도 같은 오류 응답을 다시 가져올 뿐입니다. 브라우저, 클라이언트 코어, 앱에 별도 캐시가 있을 수 있어 시스템 명령만으로 모두 삭제할 수는 없습니다. 필요한 경우 관련 앱을 완전히 종료하고 코어를 재시작한 뒤 다시 테스트하세요. 매번 기기 전체를 재부팅할 필요는 없습니다. 절전 모드에서 깨어나거나 네트워크를 바꾼 뒤에만 문제가 발생한다면 이전 인터페이스의 DNS 설정이 남아 있는지 먼저 살펴보세요.

SOCKS를 사용할 때 대상 도메인은 로컬에서 조회하거나 프록시가 처리하도록 할 수 있습니다. 아래 두 명령의 핵심 차이는 DNS 조회 위치이며, 어느 한쪽이 더 안전하다는 뜻은 아닙니다. 로컬 혼합 포트가 해당 서비스를 실제로 제공할 때만 테스트하세요. 원격 DNS 조회에서만 성공한다면 로컬 DNS와 라우팅을 점검하세요. 두 방식 모두 실패하면 연결 로그까지 확인해야 합니다. DNS 주소만 바꾸면 해결되는 것은 아닙니다.

# 로컬에서 대상 도메인을 먼저 조회
curl.exe --socks5 127.0.0.1:10808 -I --connect-timeout 10 --max-time 20 https://example.com/

# 대상 도메인 조회를 SOCKS 프록시에 맡기기
curl.exe --socks5-hostname 127.0.0.1:10808 -I --connect-timeout 10 --max-time 20 https://example.com/

도메인 정책과 분할 라우팅 규칙을 함께 확인하세요

v2rayN의 라우팅 설정에서 도메인 정책은 IP 규칙 적용을 위해 언제 DNS를 조회할지에 영향을 줍니다. Xray의 의미를 예로 들면 AsIs는 라우팅을 위해 대상 도메인을 능동적으로 조회하지 않습니다. IPIfNonMatch는 도메인 규칙이 일치하지 않을 때 조회된 IP로 다시 매칭을 시도합니다. IPOnDemand는 IP 규칙을 처리하는 과정에서 DNS 조회를 시작할 수 있습니다. 선택 항목과 실제 동작은 현재 사용하는 코어에 따라 다르므로 한 코어의 설명을 다른 코어에 그대로 적용하지 마세요.

아래 예시는 라우팅 규칙의 의미를 설명하기 위한 것으로, 클라이언트가 생성한 전체 설정을 그대로 덮어쓸 수 있는 파일이 아닙니다. 도메인 정책과 규칙의 관계를 보여 줄 뿐 일반적으로 사용할 DNS 주소를 제공하거나 클라이언트 인터페이스 설정을 대체하지 않습니다. 설정 변경은 다음 서비스 재시작 시 자동 생성된 설정에 덮어쓰이지 않도록 우선 인터페이스에서 진행하세요. 규칙을 위에서 아래로 확인하고, 먼저 일치한 직접 연결 규칙 때문에 뒤의 프록시 규칙이 실행되지 않을 수 있다는 점에 유의하세요.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

암호화 DNS를 사용하더라도 DNS 서버에 연결할 경로가 필요합니다. DNS 서버의 도메인 조회, 연결 출구, 프록시 시작 순서가 서로 의존하면 순환 문제가 생길 수 있습니다. DNS가 없으면 프록시에 연결할 수 없고, 프록시가 없으면 DNS에 접속할 수 없는 상황입니다. 먼저 작동하는 기본 DNS를 복구한 다음 고급 설정을 하나씩 활성화하세요. 시스템, 브라우저, 코어를 한꺼번에 같은 새 DNS 서버로 바꾸면 실제로 어느 계층에서 적용됐는지 확인하기 어렵습니다.

회사 내부망, 가정 내 기기 이름, 공용 도메인은 서로 다른 DNS 범위를 사용해야 할 수 있습니다. 모든 요청을 공용 DNS 서비스로 보내면 내부 이름을 확인하지 못할 수 있고, 내부 주소를 강제로 원격 경로로 보내면 로컬 접속이 끊길 수도 있습니다. 복구 후 공용 사이트, 로컬 네트워크 서비스, 절전 모드에서 깨어난 뒤의 상황을 각각 테스트하세요. IPv6와 관련된 문제는 기본 경로와 주소의 연결 가능성을 확인한 다음 개별 앱의 주소 선택을 조정하세요. 전체 기능을 끄는 방식으로 경로 문제를 대신 해결하지 마세요.

시스템 프록시가 작동하지 않을 때: 앱을 먼저 확인한 뒤 TUN 점검

‘시스템 프록시 자동 설정’을 선택해도 일부 앱이 직접 연결한다면 해당 앱이 시스템 프록시를 읽는지 확인하세요. 시스템 프록시는 앱이 사용할 프록시 설정을 제공할 뿐 모든 네트워크 요청을 강제로 가로채지는 않습니다. 앱마다 자체 설정을 사용하거나 명령줄 도구처럼 환경 변수만 읽는 경우도 있습니다. TUN은 가상 네트워크 인터페이스와 라우팅으로 트래픽을 처리하므로 점검 범위가 더 넓습니다. 두 방식의 목적은 서로 다르므로 시스템 프록시가 작동하지 않는다고 모든 트래픽 처리 방식을 동시에 켜지 마세요.

시스템 프록시의 세 가지 옵션이 적용되는 범위

‘시스템 프록시 자동 설정’은 일반적으로 시스템의 프록시 진입점을 클라이언트의 로컬 포트로 지정합니다. ‘시스템 프록시 해제’는 해당 프록시 설정을 제거합니다. ‘시스템 프록시 변경 안 함’은 클라이언트가 기존 설정을 직접 바꾸지 않는다는 뜻이지, 반드시 직접 연결한다는 뜻은 아닙니다. 옵션을 바꾼 뒤 운영체제의 네트워크 설정에서 주소와 포트를 확인하세요. 수동 프록시와 자동 설정 스크립트가 함께 적용되어 있지 않은지도 살펴보세요. 다른 프로그램이 시스템 설정을 다시 바꿀 수 있으므로 인터페이스에 성공으로 표시돼도 이후까지 유지된다고 단정할 수 없습니다.

브라우저 프록시 확장 프로그램, 관리 정책, 앱 내부 설정이 시스템 프록시 설정을 덮어쓸 수 있습니다. 관련 확장 프로그램을 잠시 비활성화하고 앱을 완전히 종료한 뒤 다시 여세요. 조직에서 관리하는 브라우저라면 정책을 임의로 변경하지 마세요. Windows에서는 네트워크 구성 요소마다 사용하는 프록시 설정이 다를 수 있습니다. 일부 시스템 서비스는 현재 사용자 계정의 브라우저 설정을 공유하지 않습니다. 따라서 브라우저가 작동해도 업데이트 서비스, 터미널, 백그라운드 프로그램이 같은 경로를 사용하는 것은 아닙니다.

명령줄에서는 먼저 명시적 프록시 매개변수로 테스트한 뒤 환경 변수를 확인하세요. 장기간 변경하고 복구를 잊는 일을 막을 수 있습니다. 아래 예시는 현재 PowerShell 세션에만 적용되며 해당 변수를 지원하는 도구에서 사용할 수 있습니다. 프로그램마다 읽는 변수 이름과 우선순위는 다를 수 있습니다. NO_PROXY는 지정한 대상을 프록시에서 제외할 수 있습니다. 여기에 너무 광범위한 도메인 접미사가 포함되면 일부 사이트가 계속 직접 연결될 수 있습니다.

# 현재 PowerShell 세션에만 적용; 포트는 클라이언트 설정에 맞게 조정
$env:HTTP_PROXY = "http://127.0.0.1:10808"
$env:HTTPS_PROXY = "http://127.0.0.1:10808"
$env:NO_PROXY = "localhost,127.0.0.1,::1"

# 테스트가 끝나면 이번 설정을 제거
Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:NO_PROXY -ErrorAction SilentlyContinue

최소 설정으로 TUN을 따로 검증하세요

프록시 설정을 읽지 않는 앱의 트래픽을 처리해야 하는 경우에만 ‘Tun 모드 사용’을 확인하세요. 먼저 다른 가상 네트워크 도구와 중복 프록시를 끄고 코어가 정상인지, 일반 프록시 요청이 성공하는지 확인한 다음 클라이언트 안내에 따라 권한을 설정하세요. 권한 부족, 가상 인터페이스 생성 실패, 라우팅 설정 실패는 로그에서 원인을 찾으세요. 스위치를 반복해서 누르지 마세요. 권한을 높이기 전에 실행 파일이 예상한 클라이언트인지 확인하고, 점검을 위해 다운로드 폴더 전체의 권한을 장기간 완화하지 마세요.

TUN을 켠 뒤 전체 네트워크가 끊기면 기본 경로가 순환하는지, 원격 서버로 향하는 클라이언트 트래픽이 다시 가상 인터페이스로 들어가는지 먼저 확인하세요. 여러 가상 네트워크 도구가 라우팅을 동시에 변경하면 화면에 보이는 우선순위와 실제 트래픽 경로가 다를 수 있습니다. 하나씩 종료한 뒤 클라이언트 하나만 실행해 테스트하세요. 경로를 확인할 때 Windows에서는 route print, Linux에서는 ip route를 사용할 수 있습니다. 먼저 결과를 기록하고, 출처를 모르는 명령으로 기본 경로를 바로 삭제하지 마세요.

TUN에서만 로컬 네트워크에 연결되지 않으면 사설 IP 규칙, 인터페이스 선택, DNS를 확인하세요. ‘LAN 연결 허용’을 켜는 것으로 해결하려 하지 마세요. 이 설정은 다른 기기가 로컬 프록시 포트에 접속할 수 있는지를 제어하며, 이 기기에서 로컬 네트워크에 접속할 수 있는지와는 별개의 문제입니다. 수신 대기를 허용하려면 방화벽과 신뢰할 수 있는 네트워크 범위도 고려해야 합니다. 모든 로컬 네트워크 문제의 해결책으로 사용하지 마세요. 이 기기 자체를 점검하는 경우와 다른 기기에 프록시를 제공하는 경우를 구분하세요.

클라이언트를 종료한 뒤 네트워크가 끊기면 시스템 프록시를 해제하고 가상 인터페이스와 라우팅이 제거됐는지 확인하세요. 필요한 경우 정상적인 인터페이스에서 물리 네트워크를 다시 연결하되 전체 네트워크 초기화는 피하세요. 고정 IP, 기업 네트워크, 다른 가상 어댑터에 영향을 줄 수 있습니다. 복구 후 정상 종료와 절전 모드에서 깨어나는 상황을 각각 테스트하세요. 브라우저와 터미널별 점검은 시스템 프록시 문제 해결에서 확인해 앱 간 차이를 서버 오류로 오해하지 않도록 하세요.

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

두 번 눌러도 창이 열리지 않는 경우, 창이 바로 닫히는 경우, 연결 중 코어가 종료되는 경우를 구분해 점검하세요. 작업 관리자나 시스템 모니터에서 이미 프로세스가 실행 중이며 트레이에 남아 있는지 확인하세요. 중복 실행으로 포트 충돌이 발생할 수 있습니다. 창은 열려 있지만 로그에서 서비스 종료가 확인된다면 보통 인터페이스 충돌은 아닙니다. 창이 완전히 사라진다면 앱 로그와 시스템 이벤트를 확인하세요. 시작, 업데이트, 설정 가져오기, TUN 활성화 중 어느 시점에 발생했는지 기록하세요. 반복해서 재시작하는 것보다 발생 시점이 원인을 좁히는 데 도움이 됩니다.

설치 방식과 실행 디렉터리 확인

클라이언트 다운로드 페이지에서 운영체제와 CPU 아키텍처에 맞는 설치 파일을 선택하세요. Windows 데스크톱 버전과 클래식 WPF 버전은 서로 다른 인터페이스 기술을 사용하므로 한 버전의 실행 환경 요구 사항을 다른 버전에 그대로 적용할 수 없습니다. macOS에서는 Apple Silicon과 Intel을 구분하세요. Linux에서는 배포판의 패키지 형식과 CPU 아키텍처를 확인하세요. 아키텍처가 맞지 않으면 명확한 오류 메시지 없이 실행되지 않을 수도 있습니다. 파일 확장자만 바꿔 설치 방식을 우회하지 마세요.

압축 파일 형태로 사용한다면 먼저 파일 전체를 압축 해제한 뒤 고정된 폴더에서 실행하세요. 압축 파일 미리보기 창에서 실행하거나 함께 제공된 리소스를 제외하고 실행 파일 하나만 복사하지 마세요. 설치 버전은 운영체제에서 제공하는 방법으로 복구하거나 재설치하세요. 사용자 데이터 디렉터리에 쓰기 권한이 있는지, 디스크 공간이 충분한지, 클라우드 동기화가 설정 파일을 잠그고 있지 않은지 확인하세요. 자주 권한을 높여야 쓰기가 가능한 임시 위치에 클라이언트를 두고 상시 관리자 권한으로 실행해 디렉터리 문제를 감추지 마세요.

보안 소프트웨어가 차단했다면 이벤트 기록에서 대상 파일과 사유를 확인하고 출처와 설치 과정을 검증한 다음 조직 또는 기기 관리 지침에 따라 처리하세요. 처음부터 보호 기능을 전체 해제하거나 디스크 전체를 예외로 등록하지 마세요. 시스템에서 실행 구성 요소가 필요하다고 표시되면 선택한 클라이언트 빌드의 요구 사항을 확인하세요. 출처가 불분명한 동적 라이브러리 하나를 내려받아 추가하지 마세요. 리소스 누락, 권한 거부, 아키텍처 불일치는 서로 다른 문제이며 구성 요소를 더 설치한다고 해결되는 것은 아닙니다.

백업한 뒤 새 설정으로 비교하세요

설정을 가져오거나 업데이트한 뒤 충돌이 시작됐다면 프로세스를 정상 종료하고 현재 사용자 데이터를 백업한 다음 클라이언트에서 지원하는 방법으로 별도 테스트 환경을 만드세요. 데이터 디렉터리 위치를 모르는 상태에서 파일을 한꺼번에 삭제하지 마세요. 테스트 환경에서는 자동 시작, TUN, 자동 업데이트를 끄고 인터페이스만 실행한 뒤 필요한 최소 설정을 추가하세요. 새 환경이 정상이라면 그룹, 규칙, 기타 설정을 하나씩 복구하세요. 같은 문제가 계속되면 서버를 계속 삭제하지 말고 시스템 환경과 설치 리소스를 먼저 점검하세요.

Windows에서는 이벤트 뷰어의 애플리케이션 기록에서 발생 시각을 기준으로 오류 모듈을 찾을 수 있습니다. macOS에서는 시스템 충돌 보고서를 확인하세요. Linux에서는 터미널에서 그래픽 프로그램을 실행해 표준 오류를 확인하고 현재 사용자 시스템 로그를 조회할 수 있습니다. 배포판과 실행 방식에 따라 로그 위치가 다르므로 모든 시스템에서 같은 파일을 찾을 수 있다고 가정하지 마세요. 아래 명령은 최근 사용자 로그 일부만 표시하지만 개인 경로나 다른 프로그램 정보가 포함될 수 있으므로 공유 전에 필요한 내용만 남기세요.

# Linux: 현재 사용자의 최근 10분 로그 확인
journalctl --user --since "10 minutes ago" --no-pager

로그에 로컬 포트 점유가 명확히 표시되면 프로세스가 무엇인지 먼저 확인하세요. 네트워크 프로세스를 임의로 모두 종료하지 마세요. Windows에서는 포트 수신 대기 조회에서 확인한 프로세스 ID를 Get-Process -Id에 전달해 이름을 확인한 뒤 해당 프로그램을 정상 종료할 수 있습니다. ‘로컬 혼합 포트’를 바꿔야 한다면 새 값을 기록하고 수동 설정한 브라우저, 터미널, 다른 앱에도 적용하세요. 클라이언트에서 포트를 바꿔도 시스템 프록시가 다시 적용되지는 않으며 기존 환경 변수도 자동으로 갱신되지 않습니다.

Linux 데스크톱 바로가기가 응답하지 않지만 터미널에서 실행되는 경우 실행 파일 경로, 작업 디렉터리, 환경 변수를 확인하세요. 부팅 시 자동 시작이 실패한 이유가 네트워크 준비 지연이나 권한 안내를 표시할 수 없는 상황일 수도 있습니다. 프로그램 자체를 실행할 수 없다는 뜻은 아닙니다. 관련 설치 및 실행 범위는 Linux 데스크톱 설치 및 자동 시작에서 확인하세요. 수정 후 수동 실행을 먼저 확인하고 자동 시작을 복구한 다음 재부팅과 정상 종료를 테스트하세요.

코어를 바꾼 뒤에만 문제가 발생하면 이전 조합으로 되돌리고 해당 설정을 새 코어가 인식하는지 확인하세요. 충돌을 보고할 때는 시스템 아키텍처, 설치 방식, 문제를 일으킨 작업, 민감한 내용을 삭제한 오류 부분을 제공하세요. 버전의 문제를 추측하거나 ‘업데이트 후 작동 안 함’이라고만 적지 마세요. 안정적으로 재현되는 최소 작업 절차가 전체 화면 녹화보다 분석에 유용합니다. 수정이 확인된 뒤 자동 작업을 복구해 테스트 중 업데이트나 구독 새로고침으로 조건이 바뀌지 않게 하세요.

Android 문제 해결: VPN 권한·백그라운드·앱 범위 점검

Android 클라이언트에 연결됨으로 표시되지만 앱에서 트래픽이 없다면 VPN 서비스가 시작됐는지와 원격 연결이 성공했는지를 구분하세요. v2rayNG에서 연결 버튼을 눌러 실행 상태가 된 것은 로컬 서비스가 시작됐다는 뜻일 뿐입니다. 실제 요청과 로그를 확인해야 합니다. V2Fly 코어의 대안인 v2flyNG도 지원되는 설정과 메뉴에 따라 점검하세요. 두 클라이언트 사이에서 설정을 가져오기만 했다고 같은 서버라고 단정하지 마세요. 확장 항목과 코어 기능 차이가 실제 연결에 영향을 줄 수 있습니다.

시스템 권한과 VPN 점유 여부부터 확인하세요

처음 연결할 때 시스템 VPN 권한 요청을 완료했는지 확인하세요. 권한 거부, 기기 관리 정책 제한, 백그라운드 중단으로 서비스가 시작되지 않을 수 있습니다. 일반적으로 Android에서는 두 개의 VPN 서비스가 동시에 트래픽을 처리할 수 없습니다. 회사 VPN, 네트워크 필터, 다른 프록시 앱이 사용 중인지 확인하고 정상 종료한 뒤 테스트할 클라이언트를 실행하세요. 연결 버튼을 반복해서 누르지 마세요. 서비스를 계속 켜고 끄면 로그의 상태를 확인하기 어려워집니다.

시스템의 ‘항상 켜기 VPN’ 또는 ‘VPN 없이 연결 차단’이 활성화되면 클라이언트 중지 후 직접 연결도 차단될 수 있습니다. 이런 현상은 프록시 설정이 남아서 발생한 문제가 아닐 수 있습니다. 시스템 VPN 설정에서 기존 상태를 기록하고, 변경이 허용된 기기에서 필요한 만큼 조정한 뒤 테스트하세요. 관리형 기기에서는 조직 정책을 따라야 하며 관리 구성 요소를 삭제해 문제를 해결해서는 안 됩니다. 테스트 후 필요한 보호 설정을 다시 켜고 연결이 정상적으로 끊기는지 확인하세요.

클라이언트 로그를 열고 연결 상태를 알고 있는 대상에 한 번 요청한 뒤 관련 기록이 있는지 확인하세요. 요청 기록이 없다면 앱 범위와 트래픽 처리 진입점을 확인하세요. DNS 오류가 있으면 DNS 항목으로, 핸드셰이크 오류가 있으면 서버 시간 초과 항목으로 돌아가세요. 연결 시간이나 아이콘 색상만 보지 마세요. 모바일 데이터와 무선 네트워크를 비교할 때는 같은 서버를 사용하세요. 무선 네트워크의 웹 로그인 절차를 완료했는지도 확인해야 합니다. 인증 포털 때문에 프록시 연결과 일반 웹페이지가 모두 비정상으로 보일 수 있습니다.

화면 잠금 후 연결 끊김과 앱 분할 라우팅 확인

연결 직후에는 작동하지만 일정 시간 화면을 잠근 뒤 끊긴다면 배터리 최적화와 백그라운드 제한을 먼저 확인하세요. 제조사마다 메뉴 이름이 다를 수 있으므로 다른 브랜드의 경로를 그대로 따라 하지 말고 앱 정보에서 배터리 사용, 백그라운드 활동, 자동 시작 권한을 확인하세요. 현재 클라이언트에 필요한 설정만 조정하고 알림이 표시되는 상태에서 화면을 잠갔다가 다시 깨워 테스트하세요. 모든 앱의 제한을 풀면 배터리가 더 소모되고 서버 문제인지 확인하는 데도 도움이 되지 않습니다.

일부 앱만 작동하지 않으면 앱 분할 라우팅 목록이 ‘선택한 앱만 프록시 사용’인지 ‘선택한 앱은 프록시 우회’인지 확인하세요. 모드에 따라 같은 체크 표시가 포함 또는 제외를 의미할 수 있습니다. 설정을 바꾼 뒤 VPN을 중지하고 다시 연결한 다음 대상 앱을 완전히 종료했다가 다시 여세요. 기존 연결은 이전 경로를 유지할 수 있습니다. 업무 프로필의 앱은 별도의 관리 범위에 속할 수 있으므로 개인 공간에서 선택한 설정이 모든 앱에 적용된다고 가정하지 마세요.

휴대폰에서 핫스팟을 켜도 연결된 기기의 트래픽이 휴대폰 클라이언트 VPN을 자동으로 통과하는 것은 아닙니다. 핫스팟 전달, 휴대폰 자체 요청, 로컬 네트워크에 프록시 포트를 여는 것은 서로 다른 경로입니다. 휴대폰에서 웹페이지가 열린다는 사실만으로 인터넷 공유가 정상이라고 판단하지 마세요. 휴대폰 자체 연결을 점검할 때는 공유 기능을 끄세요. 신뢰할 수 있는 기기에 프록시를 제공해야 한다면 수신 주소, 인증, 네트워크 접근 범위를 별도로 확인하세요. 테스트를 위해 신뢰할 수 없는 네트워크에 프록시 포트를 노출하지 마세요.

구독·네트워크 전환·설치 문제를 구분하세요

v2rayNG의 ‘구독 그룹 설정’에서 그룹 주소와 활성화 상태를 확인한 뒤 ‘구독 업데이트’를 실행하세요. 사용 가능한 연결이 없으면 업데이트 요청을 직접 경로로 보내야 할 수 있습니다. 메뉴와 로그를 확인해 방식을 선택하세요. 브라우저에서 주소에 접속된다는 이유만으로 클라이언트의 업데이트 경로도 정상이라고 단정할 수 없습니다. 업데이트가 완료되면 서버를 다시 선택하고 연결하세요. 구독 주소에는 접근 권한이 포함될 수 있으므로 공개 클립보드 기록 도구에 보관하거나 전체 QR 코드를 다른 사람에게 보내지 마세요.

무선 네트워크에서 모바일 데이터로 전환한 뒤 연결이 끊기면 서비스를 한 번 중지하고 새 네트워크에서 다시 연결하세요. 이 방법으로 복구된다면 시스템의 백그라운드 네트워크 제한, 이전 DNS 상태가 유지되는지, 두 네트워크에서 원격 주소에 연결할 수 있는지를 점검하세요. 처음부터 네트워크 설정 전체를 초기화하지 마세요. 듀얼 스택 네트워크와 통신사의 주소 변환으로 연결 조건이 달라질 수 있습니다. 일반 웹페이지가 열린다고 UDP를 사용하는 앱의 동작까지 확인된 것은 아니므로 실제 앱으로 비교하세요.

마지막으로 연결 후 대상 사이트 접속, 화면 잠금 및 다시 켜기, 네트워크 전환 후 재연결, 정상 연결 해제 후 직접 접속을 순서대로 확인하세요. 모든 단계가 통과해야 모바일 사용 환경까지 점검한 것입니다. 문제가 계속되면 시스템 버전, 클라이언트 이름, 네트워크 종류, 화면 잠금과의 관련 여부, 민감한 내용을 삭제한 최초 오류를 정리한 다음 자주 묻는 질문을 확인하세요. 기본 설정을 다시 구성해야 한다면 빠른 시작 가이드로 돌아가세요. 테스트용 설정을 평소 기본값으로 계속 사용하지 마세요.