V2Ray 문제 해결
연결·구독·클라이언트 설정

인터넷 연결 불가: 문제 발생 구간부터 확인

“클라이언트에는 연결됨으로 표시되지만 웹페이지가 열리지 않는” 현상은 앱이 실행 상태에 들어갔다는 뜻일 뿐, 원격 서버와의 연결이 성공했다는 의미는 아닙니다. 전체 경로는 앱, 시스템 프록시 또는 가상 네트워크 인터페이스, 로컬 인바운드, 아웃바운드 설정, 원격 서버, 대상 웹사이트로 이어집니다. 설정을 계속 바꾸기보다 요청이 어느 단계에서 멈추는지 먼저 확인하세요. 반복해서 재현할 수 있는 대상을 하나 정하고, 현재 네트워크에서 보통 바로 접속되는 웹사이트도 비교용으로 준비하세요.

프록시를 끄고 기본 네트워크 확인

데스크톱에서는 시스템 프록시를 끈 다음 클라이언트 연결을 중지하세요. Android에서는 클라이언트가 만든 VPN 연결을 해제합니다. Wi-Fi 연결과 게이트웨이가 정상인지 확인하고, 공용 네트워크라면 웹 인증을 완료하세요. 프록시를 중지해도 비교용 웹사이트가 열리지 않으면 네트워크 로그인, 기기 시간, 라우터와 통신사 네트워크부터 점검하세요. 기본 연결 문제를 프로토콜 탓으로 돌리지 마세요. 공용 네트워크의 인증 페이지는 보통 프록시를 끈 상태에서 완료해야 합니다.

직접 연결이 정상이라면 클라이언트를 다시 시작하되, 우선 트래픽을 가로채는 방식은 하나만 사용하세요. 다른 프록시나 VPN, 네트워크 설정을 변경하는 가속 도구를 동시에 실행하지 마세요. 데스크톱에서는 먼저 로컬 프록시로 테스트하고, 아웃바운드 연결이 되는 것을 확인한 뒤 추가 권한이 필요한 트래픽 처리 모드를 활성화하세요. 이렇게 하면 원격 연결 실패와 트래픽이 클라이언트로 들어오지 않는 문제를 분리해 확인할 수 있습니다.

선택한 구성과 로컬 포트 확인

v2rayN에서 목록의 다른 항목을 단순히 선택한 것이 아니라 테스트하려는 서버가 실제로 활성화되어 있는지 확인하세요. 구독을 갱신하면 활성 구성이 달라졌을 수 있으니 연결을 시작하기 전에 주소, 포트, 전송 옵션을 점검하세요. 이어서 로그에 로컬 인바운드가 정상적으로 시작되었다는 기록이 있는지 확인합니다. 포트가 이미 사용 중이라는 메시지가 나오면 해당 프로그램을 찾아 종료하거나 클라이언트 포트를 변경한 뒤 앱 설정도 함께 수정하세요. 계속 재시작하는 것으로 해결하려 하지 마세요.

로컬 SOCKS 포트는 클라이언트에 표시된 값을 사용하세요. 아래 예시는 해당 포트가 실제로 10808일 때만 사용할 수 있습니다. Windows에서는 터미널에서 curl.exe를 실행하고, macOS와 Linux에서는 보통 curl을 사용합니다. 명령에 프록시를 직접 지정하면 브라우저가 시스템 프록시를 따르는지 여부와 관계없이 테스트할 수 있습니다. 대상 웹사이트의 HTTP 오류 응답과 연결 실패는 구분해서 해석하세요.

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

HTTP 응답 헤더가 반환되면 해당 요청은 적어도 로컬 프록시와 원격 접속 경로를 통과한 것입니다. 그렇다고 모든 웹사이트가 정상이라는 뜻은 아닙니다. 로컬 주소에 연결할 수 없다는 메시지가 나오면 클라이언트 실행 여부와 리스닝 프로토콜이 맞는지 확인하세요. 로컬 연결은 성공했지만 이후 원격 오류가 발생한다면 아웃바운드 로그를 살펴보세요. SOCKS 포트를 HTTP 프록시 전용 입력란에 넣어서는 안 됩니다. 포트 번호만 같다고 두 프로토콜을 바꿔 쓸 수는 없습니다.

라우팅을 비교해 요청 경로 확인

로컬 프록시 테스트는 성공하지만 브라우저에서 실패한다면 브라우저 프록시 확장 기능, 별도 DNS 설정, 캐시를 먼저 확인하세요. 일부 웹사이트만 실패하면 잠시 프록시 우선 라우팅으로 전환해 비교한 뒤 원래 설정으로 되돌리세요. 여기서 ‘프록시 우선’은 아웃바운드 선택을 바꾸는 것이지 모든 앱이 자동으로 프록시를 사용한다는 뜻은 아닙니다. 트래픽이 클라이언트로 들어오는지는 시스템 프록시, 앱 설정 또는 가상 네트워크 인터페이스에 따라 달라집니다.

라우팅을 바꾼 뒤 정상화된다면 기존 규칙이 대상 트래픽을 실수로 직접 연결로 보냈는지, 차단 아웃바운드와 일치했는지, 규칙 세트가 정상적으로 로드됐는지 확인하세요. 규칙은 보통 순서대로 적용되므로 앞쪽의 넓은 규칙이 뒤쪽의 세부 규칙보다 먼저 적용될 수 있습니다. 모든 규칙을 한꺼번에 지우지 마세요. 먼저 백업한 뒤 대상 도메인 하나만으로 범위를 좁혀 검증하세요. 기업 내부망, 로컬 네트워크 기기, 공개 웹사이트의 접속 요구는 서로 다르므로 전역 모드 하나로 장기적인 문제를 해결하려 해서는 안 됩니다.

결과를 확인하고 이번 점검 마무리

마지막으로 직접 접속, 프록시를 명시한 접속, 평소 사용하는 앱 접속을 각각 다시 테스트하세요. 프록시를 명시하면 되지만 앱에서는 안 된다면 시스템 프록시 항목을 확인하세요. 모든 아웃바운드 연결이 시간 초과된다면 노드 시간 초과 항목으로, 도메인 요청만 이상하다면 DNS 항목으로 이동하세요. 작동하는 구성은 별도로 저장하고 테스트 중 추가한 임시 규칙을 제거한 다음 필요한 기능을 하나씩 복원하세요.

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

시간 초과는 응답을 기다리는 상태를 말할 뿐, 원인을 알려주지는 않습니다. 같은 ‘연결 실패’ 메시지도 원격 포트에 연결할 수 없거나, TLS 핸드셰이크가 완료되지 않았거나, 전송 경로가 잘못됐거나, 대상 웹사이트가 응답하지 않는 등 다양한 원인에서 발생할 수 있습니다. 먼저 클라이언트 로그를 열고 실패 동작을 한 번만 실행한 다음, 같은 시간대의 로그에서 가장 먼저 나타난 오류를 찾으세요. 이후에 이어지는 연결 종료 기록은 앞선 오류의 결과인 경우가 많으므로 원인으로 먼저 단정하지 마세요.

로그가 발생한 단계별로 원인 확인

dial tcp와 시간 초과가 함께 나타나면 주소, 원격 포트, 네트워크 연결 상태를 우선 확인하세요. connection refused는 대상 포트에서 서비스가 실행 중이지 않거나 연결이 거부됐을 가능성을 나타냅니다. TLS 단계까지 진행됐다면 서버 이름, 인증서 검증, 기기 시간을 먼저 확인하세요. 로그는 점검할 범위를 좁히는 단서일 뿐, 짧은 오류 문구 하나만으로 원격 서비스가 반드시 중단됐다고 단정할 수는 없습니다. 다른 네트워크에서도 비교해 보세요.

클라이언트 내장 테스트는 실패했는데 실제 웹페이지는 열린다면 테스트 대상에 접속할 수 있는지, 테스트가 같은 아웃바운드 경로를 사용하는지 확인하세요. TCP 연결, 프록시 핸드셰이크, 웹 요청 테스트는 측정하는 대상이 다르므로 결과를 그대로 비교하면 안 됩니다. 반대로 단순 연결 테스트에 성공해도 인증, 암호화, 앱 수준의 접속이 정상이라는 뜻은 아닙니다.

프로토콜과 전송 매개변수 하나씩 확인

신뢰할 수 있는 출처에서 받은 원본 구성과 대조해 프로토콜, 주소, 포트, 사용자 ID, 암호화 옵션, 전송 유형을 확인하세요. WebSocket은 경로와 서버가 요구하는 Host가 일치해야 하고, gRPC는 서비스 이름을 맞춰야 합니다. TLS 서버 이름과 연결 주소는 서로 다를 수 있으므로 두 값을 임의로 합치지 마세요. 주소창에서 웹사이트가 열린다고 해서 그 사이트의 프록시 서비스도 같은 접속 주소를 사용한다는 뜻은 아닙니다.

VLESS와 REALITY 등을 함께 사용하는 경우 서버에서 요구하는 공개 키, short ID, 서버 이름, 흐름 제어 옵션이 클라이언트의 지원 기능 및 구성과 일치해야 합니다. 이름이 비슷하다는 이유로 매개변수를 다른 전송 유형에 복사하거나, 코어를 바꾸면 누락된 값이 해결된다고 생각하지 마세요. 구독을 가져온 뒤 일부 항목이 비어 있다면 먼저 클라이언트가 해당 형식을 지원하는지 확인하고, 구성 제공자에게 필요한 정보를 문의하세요.

기기 시간이 맞지 않으면 인증서 검증이 실패하거나 일부 인증 절차에 문제가 생길 수 있습니다. 먼저 시스템 자동 시간 설정을 켜고 시간대가 맞는지 확인한 뒤 다시 시도하세요. 오류를 피하려고 인증서 검증을 장기간 꺼두지 마세요. 연결의 보안 수준이 낮아지고 서버 이름을 잘못 입력한 문제를 가릴 수 있습니다. 관련 옵션은 통제된 테스트에서 필요할 때만 확인하고, 테스트가 끝나면 정상적인 검증 설정으로 되돌리세요.

네트워크와 구성 조합을 바꿔 비교

같은 구성을 유지한 채 현재 네트워크와 신뢰할 수 있는 다른 네트워크에서 각각 테스트하세요. 이어서 현재 네트워크는 그대로 두고 정상 작동이 확인된 다른 구성으로 바꿔 테스트합니다. 첫 번째 비교는 로컬 네트워크 차이를, 두 번째 비교는 원격 서버나 개별 구성의 차이를 확인하는 데 도움이 됩니다. 테스트 중 DNS가 바뀌었는지, 다른 VPN이 실행 중인지, IPv6 경로에서만 실패하는지도 기록해 여러 변경을 하나의 결론으로 섞지 마세요.

도메인이 IPv4와 IPv6 주소를 모두 반환하면 한 주소 계열의 경로 문제로 응답이 지연될 수 있습니다. 로그에서 실제로 연결한 주소를 확인한 뒤 주소 계열을 일시적으로 비교하세요. 시스템 전체에서 IPv6를 영구적으로 끄지는 마세요. 서버 주소가 도메인 이름이라면 해석 결과가 서비스 제공자의 안내와 맞는지도 확인하세요. 잘못된 주소로 해석된다면 DNS 문제로 다뤄야 하며 모든 시간 초과 값을 무작정 높일 필요는 없습니다.

원격 서비스 장애와 재시도 범위 확인

서로 다른 여러 네트워크에서 같은 구성만 실패하고 매개변수와 유효 기간도 확인했다면 원격 서비스 또는 구성 사용 권한 문제로 범위를 좁히세요. 민감 정보를 가린 첫 오류 로그, 발생 시각, 네트워크 비교 결과를 전달하고 전체 구독 주소는 보내지 마세요. 계속 재시도해도 서버 리스닝이나 계정 제한 문제는 해결되지 않으며, 오히려 추가 제한이 걸릴 수 있습니다. 확인을 기다리는 동안 검증된 대체 구성을 사용하고 원래 항목은 나중에 비교할 수 있도록 보관하세요.

구독 오류: 가져오기·파싱·구성 사용 단계 구분

구독 업데이트는 주소에서 내용을 가져오는 단계, 내용을 클라이언트 구성으로 변환하는 단계, 그중 하나를 선택해 연결하는 단계로 나뉩니다. 업데이트 성공은 앞의 두 단계가 완료됐다는 뜻일 뿐, 모든 구성이 연결된다는 보장은 없습니다. 연결 실패가 구독을 다시 추가해야 한다는 뜻도 아닙니다. 화면에 표시된 오류가 네트워크 오류인지, 형식 오류인지, 가져온 뒤 목록이 비어 있는 문제인지 먼저 확인한 다음 해당 단계에 맞게 처리하세요. 아직 작동하는 항목을 성급히 삭제하지 마세요.

링크 유형과 접속 정보 확인

HTTP 또는 HTTPS 구독 주소는 보통 업데이트 가능한 구성 여러 개를 반환합니다. vmess://, vless:// 같은 공유 링크는 대개 노드 하나를 나타냅니다. 단일 노드 링크를 구독 주소 입력란에 넣으면 가져오기에 실패할 수 있고, 구독 내용을 일반 웹 주소처럼 복사하면 쿼리 매개변수가 빠질 수 있습니다. 먼저 출처 페이지의 안내를 확인한 뒤 ‘구독 그룹’이나 ‘클립보드에서 가져오기’ 등 알맞은 메뉴를 선택하세요.

복사한 내용 앞뒤에 공백이나 줄바꿈이 들어갔는지, 메신저가 문장 부호를 덧붙였는지, 쿼리 문자열이 잘렸는지 확인하세요. 구독 주소의 액세스 토큰은 비밀번호처럼 다루세요. 공개 진단 사이트에 붙여 넣거나 공용 기기에서 직접 열지 마세요. 주소가 노출됐다면 서비스 제공자에게 접속 정보를 재설정해 달라고 요청하세요. 클라이언트 기록에서 주소를 삭제해도 다른 사람이 이미 확보한 주소를 무효화할 수는 없습니다.

공유 링크와 구독 주소의 차이는 공유 링크와 구독의 차이를 참고하세요. 노드 하나를 수동으로 가져오는 방법은 임시 확인에 적합하지만 구독 업데이트 기능은 제공하지 않습니다. 장기간 사용할 때는 그룹 이름을 알아보기 쉽게 정하고 수동 항목과 구독 항목을 구분해 다음 업데이트 후 구성이 바뀐 것으로 오해하지 않도록 하세요.

가져오기가 실패한 단계 확인

업데이트 로그에서 HTTP 상태와 네트워크 오류를 확인하세요. 인증 또는 권한 오류라면 계정, 주소, 유효 기간을 먼저 확인합니다. 요청이 너무 많다는 응답이 오면 연속 새로고침을 중단하고 기다리세요. 서버가 성공 상태를 반환했는데도 내용을 해석할 수 없다면 구성 본문 대신 로그인 페이지, 점검 안내 페이지, 네트워크 인증 페이지를 받은 것일 수 있습니다. 상태 코드와 콘텐츠 유형을 함께 살펴보고 모든 오류를 클라이언트 버전 탓으로 돌리지 마세요.

직접 연결로 구독을 가져올 수 없지만 기존 프록시는 작동한다면, 클라이언트에 관련 옵션이 있는 경우 기존 프록시를 통해 업데이트를 시도할 수 있습니다. 반대로 프록시 자체가 작동하지 않는데 업데이트를 프록시로 강제하면 기존 구성이 필요해 새 구성을 가져올 수 없는 의존 관계가 생깁니다. 현재 업데이트 경로를 확인하고 필요하면 사용할 수 있는 직접 연결 네트워크로 전환하거나 검증된 임시 연결을 이용하세요.

콘텐츠 형식과 호환성 확인

가져오기는 완료됐지만 등록에 실패한다면 구독 제공자가 클라이언트에서 인식할 수 있는 공유 링크 모음을 제공하는지 확인하세요. 다른 클라이언트 전용 형식을 범용 구독으로 취급하지 마세요. 임의의 YAML, 웹페이지 소스, 별도로 변환된 텍스트도 그대로 사용할 수 있는 것은 아닙니다. 공유 형식의 매개변수 지원 범위는 클라이언트와 코어에 따라 다릅니다. 항목 이름이 표시돼도 모든 전송 정보가 보존됐다는 뜻은 아닙니다.

먼저 별도의 테스트 그룹에 같은 출처의 공유 링크 하나를 가져와 주소, 프로토콜, 전송 설정이 모두 들어왔는지 확인하세요. 단일 링크는 작동하지만 그룹 전체가 실패한다면 구독 내용과 변환 방식을 점검하세요. 링크 하나만 가져와도 필드가 빠진다면 우선 형식 지원 여부를 확인해야 합니다. 개인 구독을 출처가 불분명한 온라인 변환 서비스에 입력하지 마세요. 변환 과정에서 주소와 접속 정보가 노출될 수 있습니다.

업데이트 후 활성 구성 다시 선택

구독을 업데이트하면 이전에 선택한 항목의 이름이나 구성이 바뀌거나 항목 자체가 사라질 수 있습니다. 활성 서버와 그룹을 다시 확인하고 연결을 한 번 실행해 로그를 살펴보세요. 업데이트 전에는 작동했지만 이후 실패한다면 표시 이름뿐 아니라 프로토콜과 전송 매개변수를 비교하세요. 서버가 변경되면 새 구성 필드가 필요할 수 있으며 오래된 클라이언트는 이를 제대로 해석하지 못할 수 있습니다. 클라이언트 업데이트가 필요하다면 다운로드 센터에서 플랫폼에 맞는 설치 파일을 선택하고 먼저 마이그레이션 안내를 확인하세요.

복구 후에는 필요한 업데이트 주기만 설정하고 수동 항목이 덮어쓰이지 않는지 확인한 다음 이번에 사용한 가져오기 경로를 기록하세요. 같은 구독에서 일부 항목만 문제가 있다면 그룹 전체를 다시 만들 필요 없이 노드 시간 초과 항목에서 계속 확인하면 됩니다. 문제를 신고할 때는 민감 정보를 가린 상태 코드, 파싱 오류, 클라이언트 이름을 포함하세요. 전체 링크나 사용자 ID, 가공하지 않은 구독 내용은 보내지 마세요.

속도 저하: DNS·연결·전송 단계별 확인

웹페이지가 늦게 열리는 문제, 동영상 재생 중 끊김, 대용량 파일 다운로드 지연은 서로 다른 원인일 수 있습니다. 웹페이지는 DNS나 핸드셰이크 단계에서 지연될 수 있고, 동영상이나 다운로드는 지속적인 전송 속도, 패킷 손실, 서버 부하와 더 관련이 있을 수 있습니다. 고정된 대상을 정해 비슷한 시간대에 같은 앱으로 다시 테스트하고, 시작까지 오래 걸리는지 연결 후에도 계속 느린지 기록하세요. 서로 다른 웹사이트, 파일, 네트워크의 결과를 바로 비교하지 마세요.

반복 가능한 테스트 조건 만들기

백그라운드에서 대량 데이터를 주고받는 작업을 중단하고 Wi-Fi 신호와 로컬 네트워크가 안정적인지 확인한 다음, 작동이 확인된 구성으로 테스트하세요. 노트북은 가능하면 유선 네트워크와 비교하고, 휴대전화는 Wi-Fi와 모바일 데이터를 비교할 수 있습니다. 한 번에 한 항목만 바꾸고 원래 증상을 재현할 만큼 테스트하세요. 클라이언트의 연결 테스트 결과는 대역폭을 보장하지 않으며 장시간 전송이 안정적인지도 단독으로 판단할 수 없습니다.

특정 웹사이트만 느리고 다른 대상은 정상이라면 해당 사이트의 부하, 콘텐츠 전송 경로, 계정 제한을 먼저 고려하세요. 프록시 출구가 바뀌면 웹사이트가 다른 콘텐츠 서버를 선택할 수 있어 같은 구성에서도 사이트별 차이가 크게 나타날 수 있습니다. 한 페이지가 느리다는 이유만으로 모든 로컬 매개변수를 바꾸지 마세요. 다른 브라우저나 같은 사이트의 다른 콘텐츠로 문제 범위를 확인한 뒤 아웃바운드 설정을 조정할지 결정하세요.

첫 응답 지연과 지속 전송 저하 구분

처음 열 때는 느리지만 두 번째에는 빨라진다면 DNS 캐시, TLS 세션 설정, 브라우저의 연결 재사용을 확인하세요. 매번 DNS 조회 단계에서 기다린다면 라우팅이나 전송 동시성을 조정해도 효과가 없을 수 있습니다. DNS 응답은 빠르지만 핸드셰이크가 반복해서 실패한다면 시간 초과 항목에서 전송 매개변수를 확인하세요. 지속 전송 속도가 점점 떨어진다면 DNS 시간 초과를 무작정 줄이기보다 네트워크 패킷 손실, 원격 서버 부하, 로컬 기기 리소스를 살펴보세요.

터미널에서 요청 단계별 누적 시간을 확인할 수 있습니다. 아래 예시는 로컬 SOCKS 포트가 실제로 10808일 때만 사용하세요. 요청 단계를 살펴보는 용도이며 속도 측정 도구는 아닙니다. 프록시를 통한 접속에서는 DNS 조회와 핸드셰이크 시간이 프록시 터널 설정을 포함할 수 있습니다. 특정 항목을 원격 DNS에 걸린 시간으로 단정하거나 한 번의 결과로 구성을 순위 매기지 마세요.

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -o /dev/null -sS -w "connect=%{time_connect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n" https://example.com/

이 명령은 일반적으로 필요한 터미널 도구가 포함된 macOS와 Linux에서 사용할 수 있습니다. Windows에서는 curl.exe를 실행하고 출력 파일을 NUL로 바꾸세요. 비교 테스트는 같은 대상과 같은 프록시 경로를 사용해야 합니다. 첫 바이트가 도착하기까지 오래 걸린다는 사실만으로 요청 처리 단계를 더 살펴볼 필요가 있다는 점을 알 수 있을 뿐, 로컬 기기, 프록시 서비스, 대상 웹사이트 중 어느 한쪽이 반드시 문제라고 결론 내릴 수는 없습니다.

로컬 기기 부하와 추가 처리 확인

시스템 작업 관리 도구를 열어 클라이언트, 코어 프로세스, 다른 앱의 CPU·메모리·디스크 사용량을 살펴보세요. 높은 부하가 지속된다면 상세 로그, 많은 규칙 처리량, 다른 앱과의 리소스 경쟁이 원인일 수 있습니다. 문제를 확인하는 동안 디버그 로그를 일반 수준으로 되돌리고 불필요한 작업을 중지한 뒤 다시 테스트하세요. 모든 시스템 보안 기능을 한꺼번에 끄지 마세요. 차단 증거가 있다면 해당 프로그램과 구체적인 경고를 확인해 조치하세요.

다중화, 동시 연결, 전송 매개변수는 값을 크게 설정한다고 항상 빨라지는 것이 아닙니다. 연결 재사용 방식이 바뀌고 서버 구현의 제약을 받을 수도 있습니다. 설정 출처의 요구 사항을 모른다면 기본값을 먼저 사용하세요. 옵션을 검증할 때는 기존 값을 보관하고 한 가지 변수만 바꿔 비교하세요. 변경 후 끊김이나 지연이 생기면 다른 ‘최적화’ 옵션을 더 추가하지 말고 원래대로 되돌려 이후 점검의 기준을 유지하세요.

라우팅·주소 계열·네트워크 전환 점검

라우팅 오류로 직접 연결이 가능한 리소스가 프록시를 거치거나, 프록시를 사용해야 하는 연결이 반복 실패할 수 있습니다. 대상 트래픽이 실제로 어떤 아웃바운드와 일치하는지 확인한 뒤 규칙을 수정하세요. IPv4와 IPv6 경로 차이, 가상 네트워크 인터페이스의 MTU 불일치도 작은 요청은 성공하지만 큰 응답은 멈추는 현상을 일으킬 수 있습니다. 관련 증거가 있을 때만 해당 항목을 테스트하고, ‘느리다’는 이유만으로 시스템 MTU부터 바꾸지 마세요.

네트워크를 바꾼 뒤 문제가 사라진다면 같은 구성을 유지하면서 관찰하고, 기존 네트워크의 Wi-Fi 품질, 게이트웨이 부하, 접속 제한을 확인하세요. 여러 네트워크에서 특정 아웃바운드만 느리다면 대상, 시간대, 민감 정보를 가린 로그를 서비스 제공자에게 전달하세요. 복구 여부는 특정 테스트 수치가 좋아졌는지가 아니라 같은 작업이 안정적으로 완료되는지로 판단해야 합니다. 마지막으로 테스트를 위해 일시 중지한 기능을 복구하고 추가한 특수 라우팅 규칙을 정리하세요.

DNS 문제: 조회 경로와 라우팅 설정 확인

DNS는 도메인 이름을 IP 주소로 바꾸지만 클라이언트에는 여러 조회 경로가 있을 수 있습니다. 시스템 리졸버, 브라우저의 암호화 DNS, 프록시 프로토콜에 포함된 도메인, 라우팅 규칙에 필요한 코어의 조회가 함께 작동할 수 있습니다. 웹페이지 하나가 열린다고 모든 DNS 요청이 예상대로 처리된다는 뜻은 아닙니다. 점검을 시작하기 전에 해결하려는 문제가 조회 실패인지, 잘못된 주소인지, 특정 요청의 출구 제한인지 먼저 정리하세요.

문제가 실제 DNS 조회 단계에서 발생하는지 확인

로그에 DNS 시간 초과, 빈 결과, DNS 서버 사용 불가 기록이 있는지 확인하세요. 시스템 명령으로 도메인을 조회할 수 있다는 것은 시스템 경로가 작동한다는 뜻일 뿐, 프록시 코어도 같은 리졸버를 사용한다는 뜻은 아닙니다. HTTPS 웹사이트를 IP 주소만 입력해 테스트해 DNS 문제를 판단하지 마세요. 인증서와 서버 이름은 여전히 원래 도메인에 의존하는 경우가 많으므로 IP 접속 실패만으로 주소에 접근할 수 없다고 결론 내릴 수 없습니다.

SOCKS를 명시한 테스트에서 socks5h는 보통 도메인 조회를 프록시 측에 맡기며, 일반 SOCKS 사용 방식은 먼저 로컬에서 조회할 수 있습니다. 두 방식의 차이는 DNS 경로를 구분하는 단서가 되지만 클라이언트의 아웃바운드 로그도 함께 확인해야 합니다. 브라우저에서 자체 암호화 DNS를 사용하면 시스템 DNS 테스트와 웹페이지 결과가 다를 수 있으므로 비교 전에 해당 옵션의 상태를 기록하세요.

domainStrategy의 적용 범위 이해

라우팅의 domainStrategy는 도메인 및 IP 규칙을 비교할 때 DNS 조회가 필요한지 제어합니다. DNS 요청의 출구를 설정하는 옵션은 아니며, 이것만으로 DNS 요청이 프록시를 통과한다고 보장할 수 없습니다. 다음 예시는 라우팅 객체에 들어가는 유효한 일부 항목으로, 필드의 역할을 설명하기 위한 것입니다. 인바운드, 아웃바운드, DNS 서버를 정의하지 않으므로 완전한 구성으로 실행할 수 없으며 그래픽 클라이언트가 생성한 설정 전체를 덮어써서도 안 됩니다.

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

AsIs는 보통 이미 알고 있는 도메인 정보에 따라 일치 여부를 판단하며 IP 규칙을 위해 적극적으로 조회하지 않습니다. IPIfNonMatch는 도메인 규칙이 일치하지 않을 때 조회를 시도해 계속 비교하고, IPOnDemand는 관련 IP 규칙을 만났을 때 조회할 수 있습니다. 실제 지원 여부는 사용하는 코어에 따라 다릅니다. 위 예시는 사용 가능한 지리 데이터와 direct라는 이름의 아웃바운드도 필요합니다. 필드 이름은 실제 구성과 일치해야 합니다.

따라서 DNS에 문제가 생겼다고 겉보기에 더 적극적인 옵션으로 전략을 바꾸는 것만으로는 해결되지 않습니다. 도메인 규칙이 대상과 일치하는지, 리졸버에 연결할 수 있는지, DNS 서버에 연결할 때 어떤 아웃바운드가 사용되는지 먼저 확인하세요. 조회 횟수가 늘면 지연이 더 두드러지거나 규칙 일치 결과가 달라질 수 있습니다. 설정을 바꿀 때마다 웹페이지가 우연히 열리는지만 볼 것이 아니라 대상 주소와 실제 아웃바운드를 함께 검증하세요.

DNS 서버의 의존성 순환 확인

HTTPS 기반 DNS 서비스를 사용하면 서비스 도메인도 먼저 조회해야 할 수 있습니다. 그 조회가 프록시에 의존하고 프록시 서버 주소 또한 같은 DNS에 의존한다면 시작 단계에서 순환 의존성이 생깁니다. 해결하려면 시작 시점의 DNS 경로와 접속 규칙을 분명히 정하고, 코어가 지원하는 방식으로 부트스트랩 조회를 설정하세요. 모든 리졸버를 임의로 같은 주소로 바꾸지는 마세요. 선택한 서비스에 현재 네트워크에서 접속할 수 있는지도 확인해야 합니다.

중국 본토와 해외 도메인을 나눠 조회할 때는 DNS 서버 선택, 라우팅 규칙, 대상 접속 출구가 서로 일치해야 합니다. 적절하지 않은 리졸버에 도메인을 보내면 사용할 수 없거나 비효율적인 주소가 반환될 수 있고, DNS 요청이 의도치 않게 직접 연결되면 예상과 다른 경로를 사용할 수 있습니다. 자세한 설정 항목은 DNS 분할 조회 설정을 참고하세요. 먼저 의존 관계를 이해한 다음 현재 클라이언트에 적용하세요.

캐시·유출 테스트·최종 점검

DNS 설정을 바꿔도 브라우저, 운영체제, 코어에 이전 캐시가 남아 있을 수 있습니다. 클라이언트 연결을 다시 설정하고 열려 있던 웹페이지를 닫은 뒤, 운영체제에서 제공하는 방법으로 캐시를 갱신하세요. 구성 디렉터리를 삭제하는 것을 캐시 초기화로 여기지 마세요. 내부 도메인은 회사나 가정 네트워크가 제공하는 리졸버에 의존할 수 있습니다. 이를 일괄적으로 공용 DNS에 맡기면 공개 웹사이트는 복구돼도 내부 리소스 접속이 실패할 수 있습니다.

검사 페이지에 표시된 DNS 출구는 현재 테스트의 표본일 뿐, 모든 앱이 같은 경로를 따른다는 뜻은 아닙니다. 서버 위치만 보고 DNS 유출 여부를 판단할 수도 없습니다. 브라우저 DNS 옵션, 클라이언트 로그, 여러 앱의 결과를 함께 비교하세요. 시스템 점검이 필요하다면 DNS 유출 검사 및 설정을 참고하세요. 수정 후에는 공용 도메인, 내부 도메인, IPv6 환경을 각각 확인하고 설명 가능한 조회 경로를 유지하세요.

시스템 프록시가 작동하지 않을 때: 앱의 프록시 사용 여부 확인

시스템 프록시는 앱이 읽어 사용할 수 있도록 제공하는 설정이지, 시스템의 모든 연결을 강제로 전달하는 장치가 아닙니다. v2rayN에서 자동 설정을 켜면 보통 로컬 프록시 주소가 시스템의 해당 위치에 기록됩니다. 하지만 코어가 정상적으로 리스닝 중인지, 앱이 설정을 따르는지, 라우팅에서 어느 아웃바운드를 선택하는지는 각각 별개의 단계입니다. 따라서 ‘설정이 켜짐’과 ‘대상 트래픽이 프록시를 통과함’ 사이를 실제 요청으로 확인해야 합니다.

로컬 프록시를 확인한 뒤 시스템 설정 테스트

인터넷 연결 불가 항목에 나온 프록시 명시 명령으로 테스트하세요. 명령에서 프록시를 직접 지정했을 때 성공한다면 로컬 인바운드와 해당 아웃바운드는 대체로 작동하는 것입니다. 이때 노드를 계속 바꾸기보다 시스템 프록시 주소와 포트, 앱 동작을 확인하세요. 호스트가 로컬 루프백 주소인지, 포트가 클라이언트의 현재 설정과 일치하는지, 앱 입력란이 HTTP 프록시와 SOCKS 프록시 중 어느 쪽을 요구하는지도 점검해야 합니다. 프로토콜을 서로 바꿔 입력하면 안 됩니다.

클라이언트 포트를 변경했다면 시스템 설정과 앱별 프록시 설정도 함께 업데이트하세요. 일부 프로그램은 시작할 때 프록시를 읽으므로 변경 후 완전히 종료했다가 다시 열어야 합니다. 창만 닫아서는 백그라운드 프로세스가 종료되지 않을 수 있습니다. 테스트할 때는 개별 프록시 확장 기능이 없는 브라우저 설정을 사용해 확장 기능이 덮어쓰는 문제를 제외하세요. 정상 작동을 확인한 다음 확장 기능과 별도 설정을 하나씩 복구해 충돌 원인을 찾으세요.

데스크톱 플랫폼별 설정 위치 확인

Windows에서는 사용자 인터페이스에 표시되는 프록시 설정이 모든 백그라운드 구성 요소에 공통으로 적용되는 것은 아닙니다. 브라우저는 정상인데 특정 서비스만 실패한다면 해당 프로그램의 안내를 확인하세요. 다른 프록시 하위 시스템을 전부 전역 변경하지 마세요. macOS에서는 현재 사용 중인 네트워크 서비스의 설정을 확인해야 합니다. 연결 방식을 바꾸면 이전 설정이 적용되지 않을 수 있습니다. Linux에서는 데스크톱 설정과 터미널 환경을 구분하세요. 두 설정은 서로 독립적인 경우가 많습니다.

터미널의 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY 환경 변수는 도구에 따라 앱 동작을 덮어쓰거나 보완할 수 있습니다. 특히 제외 목록에 테스트 중인 도메인이 포함되어 있는지 확인하세요. 문제를 확인할 때는 전역 환경 변수에 바로 기록하기보다 한 번 실행하는 명령에 프록시를 명시하는 편이 되돌리기 쉽습니다. 검증하지 않은 상태에서 모든 터미널 시작 파일을 수정하지 마세요.

시스템 프록시와 가상 네트워크 인터페이스 방식 구분

일부 앱은 시스템 프록시를 따르지 않거나 해당 프록시 모드가 처리하지 않는 연결 방식을 사용할 수 있습니다. 이때 클라이언트의 가상 네트워크 인터페이스 방식이 필요한지 검토하세요. 전역 라우팅으로 바꾸면 해결된다고 단정해서는 안 됩니다. 이 모드를 사용하려면 관리자 권한, 인터페이스 구성 요소, 올바른 라우팅이 필요할 수 있습니다. 다른 VPN, 가상 머신 네트워크, 조직의 네트워크 정책과 충돌할 수도 있으므로 먼저 기본 프록시가 작동하는지 확인하세요.

트래픽 처리 모드에서는 프록시 아웃바운드가 다시 자기 자신에게 전달되어 루프를 만들지 않도록 해야 합니다. 클라이언트가 보통 관련 제외 규칙과 인터페이스 규칙을 생성하지만 게이트웨이나 라우팅을 수동으로 바꾸면 이 관계가 깨질 수 있습니다. 활성화하자마자 모든 연결이 끊기면 기능을 중지하고 기존 연결을 복구한 다음 인터페이스 시작 로그와 라우팅 로그를 확인하세요. 정적 라우트를 계속 추가해 보는 식으로 대응하면 클라이언트를 종료한 뒤에도 별도의 네트워크 문제가 남을 수 있습니다.

로컬 네트워크 공유는 별도의 설정이 필요한 상황입니다. 로컬 루프백 주소는 해당 기기 자신을 가리키므로 다른 기기는 자기 루프백 주소로 이 컴퓨터에 접속할 수 없습니다. 공유가 필요하다면 리스닝 주소, 기기의 실제 주소, 방화벽 범위를 명확히 설정하세요. 연결을 위해 프록시 포트를 접근 가능한 모든 네트워크에 노출하지 마세요. 현재 로컬 문제를 확인하는 것이 목적이라면 리스닝 범위를 최소화해 변수를 줄이세요.

남은 설정 정리 후 정상 상태 복원

클라이언트가 비정상 종료된 뒤에도 시스템은 중지된 로컬 포트를 가리킬 수 있습니다. 앱을 닫자마자 인터넷까지 끊긴다면 시스템 설정에서 작동하지 않는 프록시를 끈 다음 클라이언트를 실행해 설정을 다시 적용하세요. 설정이 곧바로 다시 바뀐다면 다른 프록시 앱, 브라우저 확장 기능, 관리 정책이 계속 값을 쓰고 있는지 확인하세요. 조직에서 관리하는 기기는 관리 정책을 따르고 강제로 덮어쓰지 마세요.

마지막으로 시스템 프록시를 따르는 앱, 프록시를 명시한 명령, 별도 설정이 필요한 프로그램을 각각 테스트하세요. 세 결과를 각 설정에 따라 설명할 수 있어야 하며 시스템 트레이 아이콘만 확인해서는 안 됩니다. 복구 방법은 v2rayN 최초 설치 및 설정 점검을 참고하세요. 현재 유효한 포트를 기록해 두면 나중에 구성을 바꿀 때 앱 연결 문제를 노드 장애로 오해하지 않을 수 있습니다.

클라이언트 충돌: UI·코어·구성을 나눠 점검

시작 직후 종료되는 문제, 창 멈춤, 연결 후 코어가 중지되는 문제는 서로 다른 프로세스와 로그를 살펴봐야 합니다. 먼저 화면이 계속 표시되는지, 트레이 프로세스가 실행 중인지, 오류가 앱 실행·구성 읽기·연결 시작 중 어느 단계에서 발생하는지 확인하세요. 처음부터 데이터 디렉터리를 삭제하거나 반복해서 덮어 설치하지 마세요. 정상 구성을 잃고 문제를 설명할 수 있는 흔적까지 사라질 수 있습니다. 먼저 백업한 다음 최소한의 조건으로 재현해 보세요.

설치 파일과 실행 환경 확인

데스크톱에서는 v2rayN을 우선 사용하고 다운로드 센터에서 플랫폼과 프로세서 아키텍처를 확인하세요. Windows 데스크톱 버전과 기존 WPF 버전은 서로 다른 UI이므로 한쪽에 문제가 있다고 데이터 파일을 혼용해서는 안 됩니다. macOS는 Apple Silicon과 Intel을 구분하고, Linux는 아키텍처와 배포판의 패키지 형식을 모두 맞춰야 합니다. 압축을 풀 수 있다고 해서 안에 든 프로그램을 시스템에서 실행할 수 있다는 뜻은 아닙니다.

시스템에서 실행 구성 요소가 없다고 안내하면 현재 설치 설명에 따라 필요한 환경을 추가하세요. 출처를 알 수 없는 팝업에서 복구 도구를 내려받지 마세요. macOS에서 출처나 권한 경고가 표시되면 파일 출처를 확인한 다음 시스템에서 제공하는 보안 설정으로 처리하세요. 보호 기능을 전역으로 끄는 일을 일반적인 해결 절차로 삼지 마세요. Linux에서는 패키지 관리자가 안내하는 의존성 정보를 확인해야 합니다. 모든 실행 오류를 파일 권한 문제로 단정하지 마세요.

압축을 풀어 실행한다면 현재 사용자가 쓸 수 있는 고정된 로컬 디렉터리에 파일 전체를 풀어야 합니다. 압축 파일 미리보기에서 바로 실행하지 마세요. 동기화 도구, 제어된 폴더, 다른 프로그램이 경로를 사용 중이면 구성 저장이 실패할 수 있습니다. 먼저 권한이 확실한 로컬 디렉터리로 옮겨 테스트한 다음 보안 프로그램의 구체적인 기록을 확인하세요. 격리 알림이 있으면 대상 파일을 확인하고, 원인을 모르는 오류를 피하려고 모든 보호 기능을 끄지 마세요.

UI 문제와 코어 종료 구분

UI는 사용할 수 있지만 연결 직후 중지된다면 코어 로그에서 첫 번째 시작 오류를 확인하세요. 주요 원인으로는 포트 충돌, 현재 코어가 지원하지 않는 필드, 존재하지 않는 참조 파일, 지리 데이터 로드 실패가 있습니다. 로그에 구성 파싱 오류가 있다면 인바운드가 시작되지 않았을 수 있으므로 시스템 프록시를 바꿔도 소용없습니다. 최근에 변경한 필드를 되돌린 다음 이전에 작동했던 구성으로 확인하세요.

UI 자체가 열리지 않는다면 시스템 이벤트 기록이나 클라이언트 시작 로그에서 데이터 파일 읽기, 창 상태, 쓰기 디렉터리와 관련된 문제가 있는지 살펴보세요. 기존 디렉터리는 보존하고 원래 데이터를 덮어쓰지 않는 별도 테스트 디렉터리에서 최소 환경으로 실행하세요. 새 빈 환경에서 실행된다고 해서 문제가 기존 데이터나 설정 쪽에 가까울 수 있다는 점만 알 수 있을 뿐, 과거 구성이 전부 손상됐다고 단정할 수는 없습니다.

구성 문제의 범위를 안전하게 좁히기

클라이언트를 종료하고 백그라운드 프로세스도 끝났는지 확인한 다음 구성, 구독 기록, 필요한 로그를 안전한 백업 위치에 복사하세요. 테스트 환경에는 검증된 구성 하나만 가져오고 복잡한 사용자 지정 라우팅이나 외부 규칙은 일단 제외하세요. 최소 환경이 안정적이면 구독, 라우팅, 다른 설정을 단계별로 복원해 문제가 다시 나타나는 지점을 찾습니다. 이렇게 하면 문제를 일으키는 항목을 찾을 수 있어 전체 설정을 다시 만들고도 원인을 모르는 상황을 피할 수 있습니다.

코어 전환은 구성이 해당 코어를 지원하는지 먼저 확인해야 합니다. Xray와 V2Fly는 서로 다른 코어 구현이므로 모든 필드를 그대로 사용할 수 있다고 가정하지 마세요. 다른 코어에서는 특정 전송 방식이나 보안 옵션을 다르게 처리해야 할 수 있습니다. 전환 직후 지원하지 않는 필드 오류가 발생하면 기존 코어로 되돌리거나 해당 코어가 지원하는 방식으로 구성을 다시 만드세요. UI의 옵션 이름이 같다고 완전히 호환된다는 뜻은 아닙니다.

리소스 부족과 마이그레이션 문제 확인

실행한 지 한참 지나서 충돌한다면 시작 매개변수만 살펴보지 말고 메모리, 디스크 여유 공간, 로그 증가량을 확인하세요. 디스크가 가득 차면 구성을 저장하지 못할 수 있으며 디버그 로그가 계속 쌓이면 디스크 부담이 커집니다. 대량 가져오기나 특정 규칙이 원인일 수 있다면 범위를 줄인 모음으로 다시 테스트하고 문제를 재현하는 최소 사례를 보관하세요. 로그에는 주소와 사용자 식별 정보가 포함될 수 있으므로 공유하기 전에 항목별로 민감 정보를 가리세요.

업데이트 후 처음 문제가 나타났다면 기존 데이터 백업과 마이그레이션 오류 기록을 먼저 보관하세요. 프로그램 상태나 데이터 형식이 다른 경우 데이터를 그대로 덮어쓰면 안 됩니다. 이전 버전으로 되돌릴 때는 원래 환경과 맞는 백업을 사용하세요. 마이그레이션된 데이터를 이전 프로그램이 읽지 못할 수 있습니다. 복구 후에는 시작, 가져오기, 연결, 종료, 재시작까지 한 차례 모두 확인해 앱이 일시적으로 열리는 데 그치지 않고 설정을 안정적으로 저장하고 다시 사용할 수 있는지 검증하세요.

모바일 문제: VPN 권한·앱별 설정·백그라운드 실행

Android에서는 v2rayNG를 우선 사용하고 V2Fly 코어가 필요한 경우에만 v2flyNG를 검토하세요. 화면이 비슷하다고 두 클라이언트의 구성과 코어 지원 범위까지 같다고 볼 수는 없습니다. 모바일에서는 원격 연결 외에도 시스템 VPN 권한, 앱별 규칙, 백그라운드 제한, 네트워크 전환을 살펴봐야 합니다. 먼저 화면을 켜 둔 상태에서 연결을 한 번 완료한 뒤 화면을 잠갔을 때 연결이 끊기는 문제를 확인하면 동시에 바뀌는 변수를 줄일 수 있습니다.

설치 패키지 아키텍처와 VPN 권한

설치에 실패하면 아키텍처, 시스템 요구 사항, 저장 공간, 기존 앱과의 충돌을 먼저 확인하세요. 최근 출시된 주류 휴대전화에서는 보통 arm64를 선택합니다. 아키텍처를 확인할 수 없다면 범용 패키지를 검토하세요. 패키지가 다르다고 계정 권한이 달라지는 것은 아닙니다. 서명 충돌 메시지가 나와도 기존 앱을 바로 삭제하지 마세요. 필요한 구성을 내보내고 백업이 제대로 됐는지 확인하세요. 앱을 삭제하면 대개 앱 전용 데이터도 지워집니다. 다운로드 경로는 Android 다운로드에서 확인하세요.

처음 연결할 때는 보통 시스템 VPN 권한이 필요합니다. 권한 요청을 거부했다면 클라이언트에서 다시 연결을 시작해 승인 절차를 확인하세요. 업무용 프로필이나 조직 정책으로 관리되는 기기는 추가 제한이 있을 수 있습니다. 일반적으로 같은 사용자 환경에서는 VPN 서비스를 하나만 활성화할 수 있습니다. 다른 VPN, 일부 로컬 필터링 앱, 가속 도구가 해당 자리를 차지할 수 있으므로 연결 전에 현재 어떤 앱이 네트워크를 처리하는지 확인하세요.

시스템 상태 표시줄에 VPN 아이콘이 나타나도 VPN 서비스가 실행 중이라는 뜻일 뿐 원격 프록시 핸드셰이크가 성공했다는 의미는 아닙니다. 클라이언트 로그를 함께 확인하고 웹페이지 요청을 한 번 보내세요. 항상 켜기 VPN 또는 VPN을 사용하지 않을 때 연결 차단을 활성화했다면 클라이언트를 중지한 뒤 직접 연결이 불가능할 수 있습니다. 이는 시스템 정책에 따른 동작입니다. 기본 네트워크를 점검하기 전에 해당 설정을 확인해 정상적인 차단을 전체 네트워크 장애로 오해하지 마세요.

앱별 규칙과 일부 앱의 접속 문제

특정 앱 하나만 접속할 수 없다면 먼저 앱별 규칙에 포함되어 있는지 확인하세요. 화면에 표시되는 목록은 ‘선택한 앱만 프록시 사용’ 또는 ‘선택한 앱 제외’를 의미할 수 있으므로 같은 체크 동작의 결과가 정반대일 수 있습니다. 현재 모드와 설명을 확인하고 설정을 바꾼 뒤 연결을 다시 만든 다음 대상 앱을 완전히 종료하고 다시 실행하세요. 목록에 앱 이름이 보인다는 이유만으로 프록시를 거친다고 단정하지 마세요. 실제 접속 결과와 로그를 함께 확인해야 합니다.

일부 앱은 자체 DNS, 장시간 연결, 특수 전송 방식을 사용하므로 브라우저와 다르게 작동할 수 있습니다. 먼저 같은 네트워크에서 다른 앱은 정상인지 비교한 다음 해당 아웃바운드가 UDP 같은 트래픽을 지원하는지 확인하세요. 브라우저가 된다는 이유만으로 대상 앱 데이터를 전부 삭제하지 마세요. 로그인 정보와 로컬 파일이 사라질 수 있습니다. 먼저 연결을 다시 만들고 앱의 네트워크 권한을 확인한 뒤 분명한 목적이 있을 때만 캐시를 처리하세요.

화면 잠금 후 연결 끊김과 백그라운드 제한

화면이 켜져 있을 때는 정상인데 잠근 뒤 연결이 끊긴다면 시스템 배터리 최적화, 백그라운드 실행 권한, 제조사 절전 설정을 먼저 확인하세요. 필요한 경우 클라이언트의 백그라운드 실행을 허용한 뒤 다시 잠금 상태에서 테스트합니다. 모든 앱의 제한을 한꺼번에 해제하지 마세요. 해당 클라이언트만 조정한 다음 배터리 소모와 연결 안정성을 살펴보세요. 기기에 자동 시작이나 백그라운드 작업 관리 기능이 있을 수도 있습니다. 메뉴 이름은 다르지만 VPN 서비스가 예상치 않게 종료되지 않도록 하는 것이 핵심입니다.

VPN 서비스가 중지된 경우와 서비스는 실행 중이지만 네트워크 요청이 실패하는 경우를 구분하세요. 전자는 보통 VPN 아이콘이 사라지거나 프로세스가 다시 시작되는 현상이 동반됩니다. 후자는 재연결, DNS, 원격 시간 초과 로그를 확인해야 합니다. 백그라운드 앱을 많이 실행하면 시스템 메모리 부족으로 프로세스가 종료될 수도 있습니다. 발생 시간과 당시 시스템 상태를 기록한 다음 백그라운드 작업을 줄여 테스트하세요. 노드를 계속 바꾸는 것보다 기기 리소스 문제인지 판단하기 쉽습니다.

네트워크 전환 후 복구와 문제 보고 정보

Wi-Fi와 모바일 데이터 사이를 전환하면 기존 연결이나 DNS 캐시가 일시적으로 작동하지 않을 수 있습니다. 먼저 클라이언트가 연결을 다시 설정할 때까지 기다린 뒤 새 요청을 보내세요. 계속 실패한다면 연결을 한 번 끊었다가 다시 연결하고 새로운 네트워크 경로를 얻었는지 로그에서 확인하세요. 특정 Wi-Fi에서만 실패하면 웹 인증과 네트워크 접속 제한을 확인하세요. 모바일 데이터에서만 실패한다면 주소 계열, DNS, 서버 연결 가능성을 비교하고 데스크톱 설정을 전부 그대로 복사하지 마세요.

작은 페이지는 열리지만 큰 응답이 멈춘다면 경로와 MTU를 추가로 확인할 수 있습니다. 다만 기본값을 유지하고 재현 조건을 먼저 기록하세요. 매개변수를 임의로 줄이면 문제가 잠시 가려지거나 오히려 추가 부하가 생길 수 있습니다. 기기 간 구성을 옮길 때는 수동으로 가져온 뒤 프로토콜 지원, 라우팅, 포트, 플랫폼별 차이를 하나씩 확인하세요. 데스크톱의 파일 경로, 시스템 프록시 방식, 권한 설정을 휴대전화에 그대로 적용하지 마세요.

문제 기록에는 클라이언트 이름, 기기 시스템, 사용한 네트워크, 화면이 켜진 상태인지 잠금 상태인지, 앱별 모드, 민감 정보를 가린 첫 오류를 포함하세요. 연결 문제는 노드 시간 초과 항목에서, DNS 문제는 DNS 문제 항목에서 확인하세요. 기본 사용 절차를 다시 살펴보려면 입문 가이드로 돌아가면 됩니다. 복구 후에는 화면이 켜진 상태의 접속, 잠금 해제 후 복구, 네트워크 전환을 각각 테스트한 다음 평소 설정으로 되돌리세요.