Shadowrocket
문제 해결 가이드

연결 스위치가 켜지지 않을 때: 시스템 권한부터 확인

연결 스위치를 켠 직후 다시 꺼진다면 시스템에서 VPN 구성을 허용하는지, 다른 연결 구성과 충돌하는지 먼저 확인하세요. 이 단계만으로 서버 사용 가능 여부를 판단할 수는 없습니다. 시스템 터널이 제대로 만들어지지 않았다면 요청이 서버에 도달하지 않았을 수 있습니다. 먼저 시스템 안내가 표시되는지 확인하고, ‘권한 승인 미완료’, ‘구성을 시작할 수 없음’, ‘시작 직후 중지’를 구분하세요. 세 경우를 모두 서버 시간 초과로 판단하면 안 됩니다.

권한을 승인한 뒤 스위치 상태 확인

처음 연결을 시작할 때 시스템에서 VPN 구성 추가를 허용하라는 메시지가 표시될 수 있습니다. 현재 사용 중인 Shadowrocket에서 보낸 안내인지 확인하고 시스템 절차에 따라 인증한 다음 앱으로 돌아와 스위치 상태를 확인하세요. 이전에 거부했다면 다시 연결을 시도해 권한을 승인하세요. 안내가 다시 표시되지 않으면 시스템 설정에서 VPN을 검색해 해당 구성이 있는지 확인할 수 있습니다. 시스템 버전에 따라 메뉴 위치가 달라질 수 있으므로 기기에 표시되는 항목명을 기준으로 확인하세요.

시스템의 VPN 구성은 구독 내용도 서버 목록도 아닙니다. 이를 삭제해도 서버 설정이 자동으로 수정되지 않으며, 앱에서 권한을 다시 요청할 수 있습니다. 현재 구성이 어느 앱에 해당하는지 먼저 확인해 업무용 또는 학교에서 관리하는 구성을 잘못 삭제하지 않도록 하세요. 관리 기기에서는 VPN 추가나 수정이 제한될 수 있습니다. 옵션을 편집할 수 없다면 기기 관리자에게 제한 사항을 확인하세요. 스위치를 반복해서 눌러도 관리 정책 문제는 해결되지 않습니다.

권한 승인 후에는 앱을 종료하지 말고 연결을 한 번 켠 다음 상태가 안정될 때까지 기다리세요. 그런 다음 시스템 설정에서 VPN이 연결됨으로 표시되는지 확인하세요. 스위치가 권한 승인 전, 승인 후, 다른 앱으로 전환한 뒤 중 언제 꺼지는지 기록하세요. 앱이 백그라운드로 전환될 때만 중지된다면 On Demand 동작과 시스템 상태를 확인하세요. 앱을 열어 둔 상태에서 바로 중지된다면 웹 규칙이나 DNS를 먼저 바꾸지 말고 당시 표시된 오류 메시지를 확인하세요.

자동 연결 및 구성 충돌 확인

연결을 끈 뒤 자동으로 다시 켜진다면 On Demand가 활성화되어 있는지, 현재 네트워크 조건이 적용되는지 확인하세요. On Demand 연결 때문에 수동 스위치가 예상과 다르게 동작할 수 있지만, 이것만으로 스위치 고장이라고 볼 수는 없습니다. 원인을 분명히 확인하려면 기존 조건을 기록한 뒤 본인의 On Demand 조건을 잠시 비활성화하고 수동 연결을 한 번 테스트하세요. 테스트가 끝나면 설정을 복원하세요. Wi-Fi 조건, 도메인 조건, 서버를 한꺼번에 바꾸면 어떤 변경이 영향을 주었는지 알기 어렵습니다.

시스템에 자동 연결 중인 다른 VPN 구성이 있는지도 확인하세요. 테스트할 때는 확인하려는 연결만 남기고 다른 구성의 자동 실행을 먼저 중지한 뒤 Shadowrocket을 다시 시도하세요. 수정할 수 없는 관리 구성은 그대로 두고 관리자에게 문의하세요. 스위치가 계속 켜져 있다면 실제 접속도 확인하세요. 시스템에 VPN이 연결됨으로 표시되어도 모든 도메인, 프로토콜, 서버가 정상이라는 뜻은 아닙니다.

구성 파일이 여러 개라면 목록에 파일이 있는지만 보지 말고 현재 예상한 파일이 활성화되어 있는지 확인하세요. 기존 파일의 사본을 보관하고, 직접 확인한 서버와 간단한 구성으로 테스트할 수 있습니다. 간소화한 구성은 시작되지만 기존 구성은 시작되지 않는다면 최근 수정한 구성 항목과 형식을 확인하세요. 구독 업데이트가 성공했다고 해서 구성 문법까지 올바른 것은 아닙니다. 두 작업은 서로 다른 내용을 처리합니다.

데이터를 보존하면서 순서대로 복구

저장하지 않은 수정 사항이 없는지 확인한 뒤 앱을 정상적으로 종료하고 다시 열어 보세요. 이어서 기기를 재시동하고 시스템 상태가 복구되는지 확인하세요. 재시동 후에는 먼저 기본 네트워크를 테스트한 다음 연결을 켜면 원래 인터넷 문제와 연결 시작 문제를 구분할 수 있습니다. 오류가 계속되면 표시된 메시지 원문, 문제가 발생한 단계, 네트워크 유형을 기록하세요. ‘켜지지 않음’이라고만 적으면 원인을 찾기 어렵고 이미 시도한 점검을 반복할 수도 있습니다.

위 점검을 마친 뒤에 시스템 VPN 구성을 다시 만들고, 본인 소유임이 분명한 구성만 처리하세요. 재구성 후 권한을 다시 요청하고 On Demand 및 현재 서버를 확인하세요. 앱을 재설치하면 로컬 구성, 기록, 사용자 설정에 영향을 줄 수 있으므로 복원할 정보가 있는지 먼저 확인하세요. 구매 항목 복원 및 재다운로드 방법은 구매 항목 복원을, 시스템 권한과의 관계는 VPN 구성 안내 메시지 설명을 참고하세요.

연결되지만 인터넷에 접속할 수 없을 때: 라우팅과 출구를 나누어 확인

스위치가 켜져 있지만 웹페이지에 접속할 수 없다면 세 가지를 비교하세요. 연결을 끈 상태에서 기본 네트워크가 정상인지, 연결을 켠 뒤 모든 대상이 실패하는지, 현재 Global Routing에서 어떤 항목을 선택했는지 확인합니다. 연결 상태가 정상이라는 것은 시스템 터널이 만들어졌다는 뜻일 뿐입니다. 실제 요청은 도메인 조회, 규칙 매칭, 출구 선택, 서버 전달 과정을 거칩니다. 이 순서대로 점검하면 서버, 규칙, DNS를 한꺼번에 바꾸는 것보다 원인을 명확히 찾기 쉽습니다.

먼저 문제 범위 확인

연결을 끄고 평소 접속할 수 있는 일반 웹페이지를 열어 Wi-Fi 네트워크 인증이 필요한지 확인하세요. 기본 네트워크에도 접속할 수 없다면 앱을 점검하기 전에 라우터, 신호 또는 네트워크 인증 문제를 해결하세요. 연결을 켠 뒤 같은 대상으로 다시 테스트하고 다른 대상도 하나 추가하세요. 웹사이트 하나만 테스트하면 사이트 자체의 장애, 계정 상태, 지역별 서비스 문제를 앱 오류로 오인할 수 있습니다.

브라우저와 문제가 발생한 앱의 결과가 같은지 각각 기록하세요. 특정 앱만 실패한다면 해당 앱의 캐시, 계정 요청, 자체 DNS 조회 또는 연결 재사용을 고려해야 합니다. 모든 앱에서 실패한다면 공통 출구나 DNS 경로 문제일 가능성이 더 큽니다. 비교할 때는 비슷한 시간과 같은 네트워크에서 테스트하세요. Wi-Fi나 서버를 바꾼 뒤 한참 전의 성공 기록과 비교하면 정확한 판단이 어렵습니다.

기본 네트워크에 로그인 페이지가 있다면 연결을 끄고 먼저 인증을 완료한 다음 다시 연결하세요. 네트워크 인증이 끝나지 않으면 기기에 Wi-Fi 연결로 표시되더라도 인증에 필요한 주소만 접속할 수 있습니다. 이때 구독 업데이트, 서버 테스트, 웹 접속이 모두 실패할 수 있습니다. 이 현상을 우회하려고 규칙을 계속 바꾸지 말고 기기가 기본 네트워크에 정상적으로 접속할 수 있는지 먼저 확인하세요.

Global Routing으로 제한된 비교 테스트

Global Routing의 Config, Proxy, Direct는 각각 구성 파일, 프록시, 직접 연결을 뜻합니다. 원래 선택을 기록한 다음 짧게 비교해 문제가 규칙과 관련 있는지 확인하세요. Direct는 직접 연결 결과를, Proxy는 프록시 출구 결과를 확인하는 데 도움이 됩니다. Config는 규칙이 적용된 실제 동작을 점검할 때 사용합니다. 이는 진단을 위한 조건이지, 특정 항목으로 전환하면 반드시 문제가 해결된다는 뜻은 아닙니다.

Proxy에서는 접속되지만 Config에서 같은 대상이 실패한다면 규칙이 다른 정책으로 요청을 보내는지 확인하세요. Direct에서는 정상이고 Proxy에서 대부분 실패한다면 현재 서버와 설정을 먼저 점검하세요. 세 옵션 모두 실패하더라도 곧바로 DNS 문제라고 단정할 수 없습니다. 기본 네트워크, 대상 사이트 장애, 기존 연결 상태도 확인해야 합니다. 옵션을 바꾼 뒤에는 브라우저가 이전 연결을 재사용하지 않도록 요청을 새로 시작하세요.

앱에서 제공하는 연결 기록이나 진단 정보를 통해 대상 도메인, 적용된 규칙, 최종 정책을 확인하세요. 메뉴 이름은 현재 인터페이스를 기준으로 합니다. REJECT가 표시되면 예상한 규칙에 따른 차단인지 먼저 확인하세요. DIRECT가 표시되는데 해당 대상에 본인 서버를 통해 접속해야 한다면 규칙 순서를 확인하세요. 파일에 규칙이 있다는 이유만으로 실제 적용된다고 단정하지 마세요.

매칭 순서에 따라 구성 문제 확인

규칙은 일반적으로 위에서 아래 순서로 적용됩니다. 범위가 넓은 조건이 앞에 있으면 뒤에 있는 구체적인 조건보다 먼저 적용될 수 있습니다. 아래는 순서를 이해하기 위한 예시이며 example.com은 설명용 도메인으로, 방문해야 하는 서비스를 뜻하지 않습니다. 테스트 전에 기존 구성의 사본을 만들고 문제가 있는 대상과 관련된 최소 범위만 수정하세요. 사용 중인 구성 파일 전체를 예시로 덮어쓰지 마세요.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

FINAL은 앞선 규칙에 매칭되지 않은 요청을 처리하며, 앞선 규칙에 이미 매칭된 결과를 수정하지는 않습니다. 로컬 네트워크 접속을 확인할 때는 대상 주소와 현재 네트워크의 실제 대역이 일치하는지도 확인하세요. 모든 가정용 네트워크가 예시 대역을 사용한다고 가정하면 안 됩니다. 도메인 규칙과 주소 규칙은 확인 방법이 다릅니다. DNS 관련 문제가 의심된다면 마지막 정책만 바꾸지 말고 다음 단계에서 실제 조회 결과도 함께 확인하세요.

간소화한 구성에서는 같은 대상이 정상인데 기존 구성에서 실패한다면 규칙을 단계별로 복원하면서 다시 테스트해 특정 조건을 찾을 수 있습니다. 테스트가 끝나면 원래 라우팅 설정으로 되돌리고, 필요한 변경과 이유를 기록하세요. Proxy를 임시 설정으로 남겨 두지 마세요. 순서 예시는 규칙 순서와 FINAL을, 인터페이스 용어는 용어 가이드를 참고하세요.

서버 연결 시간 초과: 서버 설정을 단계별로 확인

Connectivity Test에 시간 초과가 표시되면 해당 테스트가 예상한 시간 안에 완료되지 않았다는 뜻입니다. 이것만으로 비밀번호 오류, 서버 중단, 전체 구독 만료를 입증할 수는 없습니다. 테스트 방식에 따라 서로 다른 연결 단계를 확인할 수 있으며 결과는 현재 네트워크와 대상의 영향을 받습니다. 단일 항목만 실패하는지, 같은 구독의 모든 항목이 실패하는지, 특정 네트워크에서만 실패하는지 먼저 구분한 뒤 서버 설정, 서비스 상태, 로컬 네트워크 중 어디를 점검할지 결정하세요.

원본 정보와 실제 항목 비교

현재 선택한 항목을 열고 서비스 제공업체가 제공한 정보와 하나씩 비교하세요. 먼저 프로토콜, 서버 주소, 포트를 확인한 뒤 인증 및 전송 항목을 확인합니다. 복사해서 붙여넣을 때 앞뒤 공백, 잘못된 줄바꿈, 전각 문자가 들어가지 않았는지 확인하세요. 주소 입력란에 설명 문구가 섞여서는 안 됩니다. 가져온 뒤 표시 이름이 같아도 설정이 같다는 뜻은 아닙니다. 특히 비슷한 이름의 항목을 여러 번 가져왔다면 실제 연결에 선택된 항목을 확인하세요.

구독에서 생성된 항목이라면 원본 구독과 현재 기록을 먼저 보존하고, 항목을 바로 하나씩 수정하지 마세요. 직접 수정한 값은 다음 업데이트 때 덮어써질 수 있고 원본 정보와 비교하기 어려워질 수 있습니다. 서비스 제공업체가 설정을 변경했다고 확인되면 기존 구독을 업데이트하고 결과를 확인한 뒤 해당 항목을 다시 선택하세요. 업데이트에 실패했다면 구독 관련 항목을 확인해야 합니다. 이전 항목의 시간 초과를 업데이트 완료로 판단하면 안 됩니다.

서버 주소를 확인할 때 도메인 이름과 숫자로 된 주소를 구분하세요. 도메인은 DNS 조회에 의존하며, 숫자 주소는 인증서의 이름과 다를 수 있습니다. 도메인을 조회된 주소로 임의 변경하면 인증서 검증이나 라우팅 결과가 달라질 수 있으므로 일반적인 해결 방법으로 사용할 수 없습니다. 도메인 조회 문제가 의심되면 원래 주소를 유지하고 조회 결과를 기록한 뒤 DNS 항목의 비교 절차를 따르세요. 서로 다른 문제를 혼동하지 않도록 주의하세요.

프로토콜별 설정을 올바르게 조합

프로토콜마다 인증 항목과 전송 요구 사항이 다릅니다. Shadowsocks는 서버에서 지정한 암호화 방식과 비밀번호를 확인하세요. VMess, VLESS 등은 해당 프로토콜의 인증 정보와 전송 설정을 점검하세요. TLS를 사용하는 경우 관련 이름과 인증서 요구 사항도 함께 확인해야 합니다. 입력값을 저장할 수 있다는 것은 입력이 허용되었다는 뜻일 뿐 서버 설정과 일치한다는 뜻은 아닙니다. 다른 항목에서 비슷해 보이는 설정을 가져와 누락된 값을 대신하지 마세요.

인증서 관련 오류가 발생하면 먼저 기기의 날짜와 시간이 올바른지 확인한 뒤 서버에서 요구하는 이름과 인증서 상태를 점검하세요. 인증서 검증을 끈다고 구성이 수정되는 것은 아니며 검증 범위도 달라지므로 평소 점검 방법으로 사용하지 마세요. 필드의 의미가 불분명하면 값을 반복해서 바꾸지 말고 서비스 제공업체에 전체 설정을 확인하세요. 항목의 표시 이름보다 오류 메시지 원문이 문제를 파악하는 데 더 유용합니다.

Hysteria2, WireGuard 등은 각각 고유한 전송 및 키 설정이 있으므로 다른 프로토콜의 설정 조합을 그대로 사용하면 안 됩니다. 한 네트워크에서는 연결되지만 다른 네트워크에서는 실패한다면 해당 네트워크가 관련 전송을 처리하는 방식이 원인일 수 있습니다. 하지만 한 번의 시간 초과만으로는 원인을 확정할 수 없습니다. 같은 항목과 대상을 사용해 이용 가능한 네트워크 두 곳에서 비교하고 다른 조건을 동일하게 유지해야 의미 있는 결과를 얻을 수 있습니다.

교차 테스트로 문제 범위 좁히기

같은 조건에서 한 항목만 실패하고 본인이 보유한 다른 항목은 정상이라면 실패한 항목의 설정과 서비스 상태를 중점적으로 확인하세요. 모든 항목이 실패한다면 기본 네트워크를 확인하고 구독이 만료되었거나 이전 내용을 반환하는지 점검하세요. 짧은 시간에 테스트를 대량으로 반복하지 마세요. 네트워크 혼잡, 서버 제한, 기기 부하가 문제를 키워 결과를 해석하기 어렵게 만들 수 있습니다.

Wi-Fi에서는 실패하지만 셀룰러 네트워크에서는 정상이라면 Wi-Fi 인증을 완료했는지 확인한 뒤 라우터 네트워크와 DNS 환경을 점검하세요. 셀룰러 네트워크를 사용할 수 없다면 가능할 때 다른 신뢰할 수 있는 Wi-Fi와 비교하세요. 한 번 성공했다고 장기간 안정적으로 작동한다는 뜻은 아닙니다. 비교가 끝나면 원래 네트워크로 돌아가 문제가 반복되는지 확인하고, 우연한 성공을 최종 결론으로 삼지 마세요.

서비스 제공업체에 문의할 때는 프로토콜 유형, 문제가 발생한 시간, 네트워크 유형, 오류 메시지 원문, 영향을 받은 항목이 하나뿐인지 알려주세요. 비밀번호, 인증 정보, 개인 키, 전체 구독 주소는 가리세요. 이런 정보는 공개 스크린샷에 포함할 필요가 없는 경우가 대부분입니다. 이 설명서는 이미 보유한 정보를 확인하는 방법을 안내하며 연결 서비스를 제공하지 않습니다. 서버 테스트는 통과했지만 실제 사용에 실패한다면 ‘연결되지만 인터넷에 접속할 수 없음’ 항목으로 돌아가 실제 라우팅을 확인하세요.

구독 오류: 가져오기·파싱·업데이트 결과 구분

구독 업데이트는 별도의 절차로 이루어집니다. 먼저 주소에 접속해 현재 네트워크로 내용을 요청하고, 응답을 항목으로 파싱한 뒤 로컬 목록에 반영합니다. 연결이 정상이어도 구독 업데이트가 반드시 성공하는 것은 아니며, 구독이 성공해도 모든 항목을 사용할 수 있는 것은 아닙니다. 문제를 점검할 때는 정확한 안내 문구를 기록하고 요청 실패, 예상과 다른 응답, 파싱 실패, 업데이트 후 항목 수 변화로 구분하세요. 원인을 감추기 위해 삭제 후 다시 추가하지 마세요.

본인의 구독 주소 확인

서비스 제공업체가 제공한 공식 정보에서 전체 주소를 다시 복사하고 끝부분 매개변수가 빠졌는지, 공백이나 설명 문구가 섞였는지 확인하세요. 웹 관리 페이지, 설명 문서, 구독 주소는 비슷해 보일 수 있지만 용도가 다릅니다. 브라우저에서 페이지가 열린다고 해서 구독으로 가져올 수 있는 주소라는 뜻은 아닙니다. 주소의 특정 단어만 보고 형식을 추측하지 말고 서비스 제공업체의 안내를 따르세요.

구독 주소에는 접근 정보가 포함될 수 있으므로 비밀번호처럼 안전하게 보관하세요. 문제를 문의할 때 전체 주소를 공개하거나 출처가 불분명한 온라인 검사 도구에 붙여넣지 마세요. 응답 유형, 오류 코드, 안내 문구 원문은 설명할 수 있지만 계정을 식별할 수 있는 매개변수는 가리세요. 주소가 유출되었다고 의심되면 먼저 서비스 제공업체의 관리 방법으로 조치한 뒤 앱에 저장된 주소를 업데이트하세요.

먼저 수동 업데이트를 한 번 실행해 앱이 표시하는 결과를 확인하세요. 항목 이름이 바뀌었는지만 보면 안 됩니다. 서비스 제공업체가 이름을 유지하면서 설정을 변경했을 수 있고, 로컬에 이전 항목이 표시된다고 해서 요청이 성공한 것도 아닙니다. 업데이트 전에 기존 그룹과 현재 선택 항목을 기록하고, 업데이트 후 실제 내용을 비교해야 어느 단계에서 변화가 있었는지 알 수 있습니다.

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

연결할 수 없음, 시간 초과, 도메인 조회 실패 안내가 표시되면 먼저 현재 네트워크에서 기본 접속이 가능한지 확인하세요. 그런 다음 구독 도메인에 특정 접속 조건이 필요한지 점검하세요. 작동하는 서버를 이미 보유한 경우 서비스 제공업체가 허용하는 조건에서 연결 전후의 업데이트 결과를 비교할 수 있습니다. 업데이트를 위해 출처를 알 수 없는 구성을 반복해서 추가하지 마세요. 네트워크 접속 여부와 응답 내용을 따로 확인하고 모든 오류를 형식 문제로 단정하지 마세요.

서버가 로그인 페이지, 인증 페이지, 오류 페이지, 빈 내용을 반환하면 앱이 구독 데이터로 인식하지 못할 수 있습니다. 상태 코드는 원인을 파악하는 데 도움이 되지만 응답 내용 확인을 대신하지는 않습니다. 성공 응답이어도 예상한 데이터가 아니라 웹페이지일 수 있습니다. 접근 거부 안내가 표시되면 주소가 유효한지, 본인의 서비스가 정상인지 확인하세요. 인증 정보를 확인하기 전에 요청을 계속 반복하지 마세요.

형식이 맞지 않는다면 서비스 제공업체가 제공한 구독 유형과 현재 가져오기 방법이 일치하는지 먼저 확인하세요. 서버 항목 구독과 전체 구성 파일은 서로 다른 종류의 내용입니다. 둘 다 주소로 받을 수 있다는 이유로 같은 메뉴에서 처리하면 안 됩니다. 가져온 결과가 예상한 목록이 아니라 구성 파일이라면 원래 안내를 다시 확인해 용도를 파악하세요. 파일 확장자를 바꿔 해결하려고 하지 마세요.

업데이트 후 문제 및 자동 업데이트 확인

업데이트가 끝나면 현재 선택한 항목이 여전히 있는지, 소속 그룹이 바뀌었는지, 설정이 교체되었는지 다시 확인하세요. 서비스 제공업체가 항목을 제거했다면 기존 선택 항목이 더 이상 사용할 수 없는 항목일 수 있습니다. 본인이 보유한 목록에서 다시 선택해 확인하세요. 항목 수가 줄었다고 반드시 파싱이 누락된 것은 아닙니다. 원격 내용 자체가 변경되었을 수도 있으므로 업데이트 안내와 서비스 제공업체의 설명을 함께 확인하세요.

앱을 열 때 자동 업데이트되는 경우와 수동 업데이트는 실행 시점이 다릅니다. 앱을 시작할 때마다 오류가 발생한다면 관련 자동 업데이트 옵션을 잠시 끄고 수동 업데이트로 과정을 확인하세요. 완료 후 원래 설정을 복원합니다. 시작 직후에는 실패하지만 나중에 수동 업데이트가 성공한다면 당시 기본 네트워크가 아직 준비되지 않았을 수 있습니다. 네트워크 상태를 먼저 확인하고 구독 전체를 바로 삭제하지 마세요.

구독에서 생성된 항목을 직접 수정했다면 업데이트 후 값이 바뀐 것은 원격 내용이 다시 적용된 결과일 수 있습니다. 개별 사용자 설정을 보존해야 한다면 로컬 수정과 구독 업데이트를 앱이 어떻게 처리하는지 확인하고 필요한 사본을 저장하세요. 구독 항목을 임시로 수정한 내용을 안정적인 백업으로 간주하지 마세요. 복원에 필요한 것은 유효한 원본 주소, 본인의 서비스 정보, 명확히 기록한 구성 차이입니다.

구독을 다시 추가하는 작업은 주소와 형식을 확인한 뒤에 해야 합니다. 기존 기록을 보존하고 테스트 항목에 구분하기 쉬운 이름을 지정한 다음 성공을 확인한 뒤 중복 항목을 정리하세요. 새 항목과 기존 항목이 모두 실패한다면 기존 항목을 삭제해도 요청 경로가 개선되지 않습니다. 실행 방법은 구독 수동 업데이트 및 자동 업데이트 안내를, 처음 가져오는 방법은 시작하기를 참고하세요.

속도 저하 및 연결 끊김: 같은 조건으로 병목 지점 확인

웹페이지 로딩 지연, 동영상 버퍼링, 파일 전송 속도 저하, 잦은 연결 끊김은 각각 다른 지표를 나타냅니다. 한 번의 연결 테스트 응답 시간으로 지속적인 전송 성능을 판단할 수 없고, 파일 하나의 속도로 모든 접속을 평가할 수도 없습니다. 먼저 증상을 구체적으로 기록하세요. 처음 열 때 오래 기다리는지, 시작 후 전송량이 적은지, 일정 시간이 지난 뒤 갑자기 중단되는지 확인하세요. 어느 단계에서 발생하는지 알아야 DNS, 연결 경로, 대상, 기기 상태 중 무엇을 점검할지 결정할 수 있습니다.

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

정상적으로 이용할 수 있고 내용이 비교적 안정적인 대상을 선택해 비슷한 시간대에 테스트하세요. 네트워크 유형, 선택한 서버, 라우팅 방식, 백그라운드 전송 여부를 기록합니다. 앱을 업데이트하거나 사진을 동기화하거나 대용량 파일을 다운로드하면서 연결 속도를 판단하지 마세요. 다른 작업이 네트워크와 처리 자원을 함께 사용합니다. 불필요한 대용량 작업을 먼저 일시 중지해야 영향을 줄일 수 있습니다.

두 결과를 비교할 때는 대상과 동작을 동일하게 유지하세요. 웹페이지를 처음 열 때는 도메인 조회, 연결 설정, 리소스 다운로드가 필요할 수 있지만 두 번째에는 캐시가 사용될 수 있습니다. 따라서 두 번째가 더 빠르다고 해서 방금 바꾼 설정이 원인이라고 볼 수는 없습니다. 대상의 기존 연결을 종료한 뒤 다시 테스트하거나 같은 순서로 여러 차례 반복해 추세를 확인하세요. 가장 빠르거나 느린 결과 하나만 골라 결론을 내리지 마세요.

연결을 끈 뒤에도 직접 접속할 수 있는 같은 대상이 느리다면 기본 네트워크와 대상 서비스를 먼저 점검하세요. Wi-Fi 신호가 강해도 상위 네트워크에 여유가 있다는 뜻은 아닙니다. 라우터 부하와 네트워크 혼잡도 실제 결과에 영향을 줍니다. 다른 신뢰할 수 있는 네트워크와 비교할 때는 같은 서버와 대상을 유지하세요. 네트워크만 바꿨을 때 개선된다면 먼저 원래 네트워크 환경을 살펴보세요.

응답 시간과 실제 전송 속도 구분

Connectivity Test 결과는 해당 테스트가 완료되었는지 확인하는 용도입니다. 숫자만 단순 비교해 특정 항목이 모든 작업에 더 적합하다고 판단하지 마세요. 웹페이지는 여러 도메인과 리소스로 구성되며 지속적인 전송 성능은 출구 대역폭, 대상 부하, 연결 품질에도 영향을 받습니다. 응답 시간이 짧아도 파일 전송은 느릴 수 있고, 응답 시간이 길어도 전송은 안정적일 수 있습니다. 실제 사용하는 대상을 기준으로 확인하세요.

특정 대상만 느리다면 해당 대상에 예상한 정책이 적용되는지, 리소스 도메인이 다른 출구를 사용하는지 먼저 확인하세요. 페이지의 기본 도메인에 접속할 수 있어도 이미지, 로그인, 미디어 리소스가 모두 같은 경로를 사용하는 것은 아닙니다. 관련 연결 기록에서 실패하거나 반복 재시도하는 요청을 찾아보세요. 한 페이지를 빠르게 만들겠다고 모든 규칙을 같은 정책으로 바꾸면 정확한 원인을 찾기 어렵습니다.

사용 가능한 항목을 여러 개 보유한 경우 같은 시간대에 같은 대상으로 각각 테스트하세요. 특정 항목만 계속 느리다면 서비스 상태를 확인하고 서비스 제공업체에 문의하세요. 모든 항목이 느리다면 로컬 네트워크나 대상 서비스의 공통 문제를 고려해야 합니다. 여러 항목을 동시에 자주 연결하지 말고 순차적으로 비교해야 각 결과를 명확한 출구와 연결할 수 있습니다.

연결 끊김, 장시간 연결 및 네트워크 전환 점검

Wi-Fi에서 셀룰러 네트워크로 전환하면 네트워크 주소와 경로가 달라질 수 있으며 기존 세션을 다시 연결해야 할 수 있습니다. 잠깐 멈춘 것만으로 프로토콜 설정을 바꾸지 마세요. 네트워크가 안정될 때까지 기다린 뒤 같은 작업을 다시 시작하세요. 네트워크 전환 순간에만 실패하고 안정된 뒤 정상이라면 지속적인 서버 접속 불가가 아니라 네트워크 전환 관련 현상으로 기록하세요.

일정 시간이 지난 뒤 연결이 끊긴다면 대략적인 지속 시간, 화면 잠금 여부, 네트워크 전환 여부, 스위치가 계속 켜져 있는지 기록하세요. 장시간 연결된 세션이 끊기는 문제와 터널이 종료되는 문제는 점검 방법이 다릅니다. 전자는 대상, 전송, 세션 복구를 확인하고 후자는 권한, On Demand, 시스템 상태를 확인해야 합니다. 기기가 뜨겁거나 백그라운드 작업이 많은 경우 환경을 정상화한 뒤 같은 조건으로 다시 테스트하세요.

MTU 등 하위 계층 설정을 경험만으로 한꺼번에 바꾸지 마세요. 재현 가능한 특정 현상이 있고 서버나 네트워크에 근거가 있을 때만 사본에서 한 번에 하나씩 비교하세요. 변경 전 값을 기록하고 결과를 남깁니다. 여러 설정을 무작위로 바꿔 우연히 성공해도 원인을 입증하기 어렵습니다. 명확한 근거가 없다면 신호, 동시 작업, 규칙 적용, 서버 상태부터 확인하는 편이 유효한 결론을 얻기 쉽습니다.

마지막으로 네트워크, 대상, 항목, 동작, 재현 여부를 간단히 기록하세요. 서비스 제공업체에 문의할 때는 순간적인 속도 스크린샷만 보내기보다 이 조건을 우선 전달하세요. 테스트를 마치면 자동 업데이트와 평소 라우팅 설정을 복원하고 불필요한 반복 테스트를 중단하세요. 계속 속도를 측정하면 데이터와 배터리를 소모하고 관찰 중인 네트워크 부하도 달라질 수 있습니다.

DNS 문제: 조회 경로와 규칙 결과 확인

DNS는 도메인을 주소로 변환하지만 도메인 접속 실패가 항상 DNS 문제인 것은 아닙니다. 연결 설정, TLS 인증, 대상 응답 실패도 웹페이지를 열 수 없는 현상으로 나타날 수 있습니다. 먼저 오류 메시지에 도메인 조회 실패가 명시되어 있는지 확인한 뒤 앱의 DNS 설정과 요청 기록을 점검하세요. 숫자 주소를 직접 입력하는 것은 동등한 테스트가 아닙니다. 인증서, 가상 호스트, 리소스 도메인 모두 원래 이름에 의존할 수 있습니다.

도메인과 주소의 관계부터 확인

문제가 발생한 도메인을 기록하고 해당 도메인만 실패하는지, 새 조회가 필요한 모든 대상이 실패하는지 확인하세요. 기존 페이지가 열린다고 DNS가 정상이라는 뜻은 아닙니다. 기존 연결이나 캐시된 주소를 재사용 중일 수 있습니다. 반대로 도메인 하나만 실패한다면 해당 도메인의 레코드가 변경되었을 수도 있습니다. 다른 도메인도 비교해 실패가 특정 대상 유형이나 네트워크에 집중되는지 확인하세요.

현재 구성의 DNS 설정을 확인할 때는 먼저 사본을 저장하고 어떤 구성이 사용 중인지, 다른 설정이 이를 덮어쓰거나 조건에 따라 다른 조회 경로를 선택하는지 확인하세요. 파일에서 주소 하나를 바꿨다고 모든 요청이 그 주소를 사용한다고 가정하지 마세요. 구성 파일이 활성화되지 않았거나 앱에 별도의 관련 설정이 있을 수 있습니다. 정적인 문구만 살펴보지 말고 실제 진단 정보와 함께 판단하세요.

DNS 서버 주소 자체가 도메인이라면 처음에 그 주소가 어떻게 조회되는지도 고려해야 합니다. 보안 연결이 필요한 DNS 방식을 사용한다면 해당 DNS 서버에 접속할 수 있는지, 이름 검증이 올바른지도 확인해야 합니다. DNS 서버를 더 추가한다고 반드시 성공률이 높아지는 것은 아니며 대기 시간이 늘거나 결과가 일치하지 않을 수도 있습니다. 본인이 이해하고 검증할 수 있는 설정부터 사용하고, 출처가 불분명한 주소 목록을 일반적인 해결책으로 삼지 마세요.

조회 결과와 라우팅 규칙을 함께 확인

도메인 규칙은 이름 조건을 확인하고 IP-CIDR, IP-CIDR6, GEOIP 등의 규칙은 주소나 주소의 위치 정보를 확인합니다. 두 종류의 규칙은 서로 다른 단계에서 최종 정책에 영향을 줄 수 있습니다. 같은 도메인이라도 조회된 주소가 다르면 주소 규칙의 적용 결과가 달라질 수 있습니다. 따라서 ‘조회에 성공했는가’뿐 아니라 ‘어떤 주소가 반환되었고 최종적으로 어느 출구를 사용하는가’도 확인하세요.

기록에서 대상에 예상과 다른 정책이 적용되었다면 도메인 조건의 철자가 정확한지, 앞선 규칙이 이를 덮어쓰는지, 마지막 FINAL 정책이 무엇인지 확인하세요. DOMAIN-SUFFIX는 DOMAIN과 매칭 범위가 다르고 DOMAIN-KEYWORD는 더 많은 이름에 매칭될 수 있습니다. 특정 대상 하나를 고치려고 범위가 지나치게 넓은 키워드 규칙을 추가하지 마세요. 관련 없는 요청까지 바뀔 수 있습니다.

구성에 로컬 주소 규칙이 있다면 현재 기기의 실제 네트워크 대역과 서비스 이름을 확인하세요. 로컬 네트워크 기기 이름 조회는 해당 네트워크가 제공하는 기능에 의존할 수 있으므로 원격 DNS 서버가 가정 내 기기 이름을 조회할 수 있다고 가정하지 마세요. 집 안 기기에만 접속할 수 없고 일반 웹페이지는 정상이라면 이름으로 접속한 경우와 실제 기기 주소로 접속한 경우를 비교한 뒤 로컬 네트워크 경로와 관련 권한을 확인하세요.

IPv6, 캐시 및 네트워크 차이 점검

일부 도메인은 여러 주소 체계의 주소를 함께 반환합니다. 현재 네트워크, 서버, 대상에 따라 각 경로의 지원 여부가 다를 수 있습니다. 간헐적인 실패가 발생하면 특정 주소 유형과 관련이 있는지 살펴볼 수 있지만 IPv6 주소가 보인다는 이유만으로 문제라고 단정하지 마세요. 기존 구성을 보존해 비교하고 앱에서 제공하는 관련 옵션의 의미를 확인하세요. 한 번에 하나씩 바꾸고 테스트한 뒤 원래 설정으로 복구하거나 변경을 유지하는 이유를 기록하세요.

DNS 설정을 변경해도 이전 캐시와 기존 세션이 계속 사용될 수 있습니다. 연결을 새로 설정하고 대상 요청을 다시 시작하세요. 필요하면 관련 앱을 정상적으로 종료한 뒤 열어 이전 상태의 영향을 줄일 수 있습니다. 첫 시도에서 여전히 실패했다고 설정이 효과 없다고 판단하지 말고, 캐시된 주소로 한 번 접속되었다고 문제가 해결되었다고 보지도 마세요. 같은 조건에서 여러 새 요청이 안정적으로 완료되는지 확인한 뒤 변경 사항을 유지할지 결정하세요.

같은 구성이 한 Wi-Fi에서는 정상이고 다른 네트워크에서는 실패한다면 원래 네트워크의 인증 필요 여부, DNS 환경 차이, DNS 서버 접속 가능 여부를 확인하세요. 네트워크를 전환할 때 서버와 대상은 그대로 유지하세요. DNS 오류가 사라졌지만 연결이 계속 실패한다면 전송 단계를 점검하세요. 여러 문제가 있을 수 있으므로 모든 증상을 하나의 DNS 설정으로 설명하려고 하지 마세요.

복구할 때는 이전에 정상이라고 확인한 DNS 설정으로 먼저 되돌린 다음 필요한 변경을 하나씩 추가하세요. 문제가 발생한 도메인, 오류 메시지 원문, 네트워크 유형, 적용된 정책만 기록하면 됩니다. 전체 검색 기록을 공개할 필요는 없습니다. 관련 키워드는 용어 가이드에서 확인하세요. DNS 조회가 성공했는데도 요청이 실패한다면 서버 설정 또는 규칙 항목으로 돌아가 이미 정상인 DNS 설정을 반복해서 바꾸지 마세요.

배터리 소모 및 업데이트 후 문제: 기준을 보존한 뒤 비교

연결 중 배터리 소모가 늘었다면 데이터 사용량, 신호, 재시도, 기기 작업을 함께 살펴봐야 합니다. 시스템 배터리 통계에서 앱이 차지하는 비율은 추가 소모량을 직접 측정한 값이 아니므로 비율 하나만으로 구성이 잘못되었다고 판단할 수 없습니다. 업데이트 후 문제가 발생한 경우에도 앱 업데이트, 시스템 업데이트, 구독 업데이트, 구성 변경이 비슷한 시기에 있었을 수 있지만 각각 영향을 주는 내용은 다릅니다. 먼저 시간 순서를 명확히 정리하세요.

배터리 소모 당시 실제 작업 확인

시스템 배터리 정보에서 해당 시간대를 확인해 동영상 재생, 파일 동기화, 대량 다운로드, 약한 네트워크 신호가 있었는지 살펴보세요. 터널을 통과하는 네트워크 트래픽의 처리량은 기기 사용 상황과 함께 전력 소모에 영향을 줍니다. 연결을 켜 둔 시간만으로 배터리 소모량을 추정할 수는 없습니다. 비교할 때는 화면 밝기, 네트워크, 작업, 지속 시간을 비슷하게 유지하세요. 대기 상태와 동영상 연속 재생을 비교하지 마세요.

거의 사용하지 않는데도 계속 발열한다면 반복적인 업데이트, 잦은 연결 테스트, 실패 요청의 재시도가 있는지 확인하세요. 본인이 설정한 자동 작업을 잠시 중지하고 정상 연결은 유지한 채 비교하세요. 개선되는지 확인한 뒤 자동 작업을 하나씩 복원해 원인을 찾습니다. 모든 기능을 한 번에 끄고 특정 프로토콜 때문에 배터리가 소모된다고 단정하지 마세요. 동시 작업과 네트워크 재시도가 주된 원인일 수 있습니다.

신호 상태와 네트워크 전환도 확인하세요. 불안정한 네트워크 사이를 기기가 반복해서 전환하거나 접속할 수 없는 대상에 오랫동안 연결을 시도하면 활동이 늘어날 수 있습니다. 안정적인 기존 네트워크로 전환하고 같은 구성으로 관찰하세요. 그래도 기기가 눈에 띄게 뜨거워지면 고부하 테스트를 중단하고 기기가 정상 상태로 돌아온 뒤 계속 기록하세요. 테스트 자체가 지속적인 배터리 소모와 발열의 원인이 되어서는 안 됩니다.

업데이트 후 무엇이 바뀌었는지 먼저 확인

최근 변경된 항목이 앱, 시스템, 구독, 직접 수정한 구성 중 무엇인지 기록하세요. 구독 업데이트는 서버 설정을 바꿀 수 있고 구성 업데이트는 규칙을 바꿀 수 있지만 앱 업데이트가 본인의 서비스 상태를 동기화하지는 않습니다. 현재 선택한 서버, 활성 구성, Global Routing이 이전과 같은지 먼저 확인하세요. ‘업데이트 후 작동하지 않음’처럼 보이는 문제 중에는 현재 선택 항목이 바뀐 뒤 발생한 경우도 많습니다.

앱의 구입과 업데이트는 App Store에서 진행합니다. 정품 여부를 확인하려면 개발자 Shadow Launch Technology Limited, 공식 아이콘, 앱 ID 932747118을 확인하세요. 자세한 절차는 정품 확인 안내를 참고하세요. 시스템 요구 사항은 App Store 페이지에 표시된 내용을 기준으로 합니다. 화면 모양이 달라졌다는 이유만으로 출처를 판단하거나 확인되지 않은 구성 내용으로 앱 자체를 검증하지 마세요.

변경 전에는 기존 구성이 정상이었다면 보관한 사본과 비교해 규칙 변경인지 서버 자체의 문제인지 확인하세요. 백업에 포함된 서버도 이미 사용할 수 없게 되었을 수 있으므로 이전 구성에서도 실패한다는 사실만으로 앱 업데이트가 원인이라고 볼 수는 없습니다. 기본 네트워크, 서비스 상태, 간소화한 구성을 함께 확인해 재현 가능한 최소 조건을 찾으세요. 발생 시점이 비슷하다는 이유만으로 원인이라고 판단하지 마세요.

위험을 줄이는 순서로 복구하고 문제 전달

저장하지 않은 수정 사항을 먼저 보존하고 앱을 정상적으로 종료한 뒤 다시 여세요. 네트워크가 안정되면 연결을 한 번 새로 설정합니다. 시스템 업데이트를 막 마쳤다면 기기를 재시동한 뒤 다시 테스트할 수 있지만, 재시동은 임시 상태를 정리하기 위한 비교 절차일 뿐 모든 문제의 정답은 아닙니다. 복구 후에는 원래 자동 업데이트, On Demand 규칙, 라우팅 옵션도 확인해 임시 변경이 평소 사용 방식에 영향을 주지 않도록 하세요.

특정 구성에서만 문제가 발생한다면 모든 설정을 초기화하기보다 해당 파일을 복사한 뒤 최근 추가한 부분을 단계적으로 제거하는 편이 원인을 찾기 쉽습니다. 서버 비밀번호, 키, 인증 정보가 포함된 원본 파일을 공개하지 마세요. 필요한 최소 규칙, 오류 메시지 원문, 재현 절차만 보존하면 됩니다. 특정 부분을 제거했을 때 복구된다면 조건을 하나씩 확인하고 구성을 통째로 교체할 필요는 없습니다.

재설치하기 전에 유효한 구독 주소, 필요한 서버 정보, 로컬 사용자 구성을 보유하고 있는지 확인하세요. App Store에서 앱을 다시 받아도 모든 로컬 데이터가 자동으로 복원되는 것은 아닙니다. 구매 기록과 구성 백업은 별개입니다. 관련 절차는 기기 변경 및 재설치 후 복원을 참고하세요. 데이터를 복원할 수 있는지 확인하지 못했다면 현재 상태를 보존하고 삭제하지 않는 점검을 계속하세요.

문제를 전달할 때 실제 시스템과 앱 정보, 변경 순서, 반복 가능한 단계, 이미 확인한 결과를 적으세요. ‘업데이트 후 고장’이라고만 쓰지 마세요. 이 문서에서는 앱 버전이나 업데이트 날짜를 고정해 안내하지 않으며 실제 배포 정보는 App Store 페이지를 기준으로 합니다. 배터리 문제라면 같은 조건에서 사용한 시간대와 작업을, 연결 문제라면 스위치 상태와 오류 메시지 원문을 함께 기록하되 두 종류의 정보를 하나의 결론으로 섞지 마세요.

iPad 전용 점검: 기기·네트워크·구성 차이 구분

같은 구독이 iPhone에서는 정상이고 iPad에서는 문제가 생겨도 구독이 해당 기기를 지원하지 않는다고 단정하지 마세요. 두 기기가 서로 다른 네트워크에 연결되어 있거나, 다른 구성 파일과 라우팅 옵션 또는 서버 항목을 사용하거나, 서로 다른 시점에 업데이트된 내용을 보유할 수 있습니다. ‘같다’는 것이 구체적으로 어떤 설정이 같은지를 확인한 뒤 하나씩 비교하세요. iPad의 시스템 요구 사항과 호환성은 App Store 페이지에 표시된 내용을 기준으로 합니다.

앱과 시스템 상태부터 맞춰 확인

iPad에서 해당 App Store 제품 페이지를 열고 앱 정보와 호환성을 확인하세요. 구입 및 다운로드 안내는 iPad 안내를 참고하세요. 같은 계정의 구매 기록과 기기에 저장된 구성은 별개입니다. 앱을 설치한 뒤에도 본인의 구독 또는 서버 정보를 가져왔는지 확인해야 합니다. 다른 기기가 정상이라는 사실만으로 현재 기기에 필요한 모든 구성이 갖춰져 있다고 판단하지 마세요.

처음 연결할 때는 시스템 VPN 권한도 승인해야 합니다. 화면 크기에 따라 레이아웃이 달라진다면 Home, Config, Settings 등 원래 영어 메뉴 이름으로 기능을 찾으세요. iPhone에서 버튼이 있던 위치만 기억하지 마세요. 분할 화면이나 창 너비에 따라 표시 영역은 달라질 수 있지만 점검 순서는 같습니다. 현재 항목을 확인하고, 구성을 점검하고, 라우팅을 확인한 다음 연결을 켜 실제 접속을 검증하세요.

일부 iPad는 Wi-Fi 전용이라 같은 기기에서 셀룰러 네트워크와 비교할 수 없습니다. 가능하다면 다른 신뢰할 수 있는 Wi-Fi를 사용하세요. 셀룰러 네트워크를 지원하는 기기라면 네트워크 전환 전후의 결과를 기록하세요. iPhone과 iPad를 비교할 때는 두 기기를 같은 네트워크와 비슷한 시간대에 두세요. 한 기기는 셀룰러 네트워크, 다른 기기는 인증이 필요한 Wi-Fi를 사용하면서 차이를 기기 모델 탓으로 돌리지 마세요.

표시 이름만 보지 말고 설정을 하나씩 비교

두 기기에서 선택한 서버 주소, 포트, 프로토콜을 각각 확인한 다음 활성 구성과 Global Routing을 비교하세요. 표시 이름이 같아도 다른 항목일 수 있습니다. 여러 번 가져오기, 직접 수정, 구독 업데이트 후에는 특히 주의하세요. iPad의 내용을 전부 덮어쓰지 마세요. 먼저 차이를 기록하고 필요하다면 사본에서 한 항목만 바꾼 뒤 문제가 달라지는지 확인하세요.

두 기기에서 같은 구독 업데이트를 완료했는지, 원격에서 받은 내용도 같은지 확인하세요. 한 기기에는 이전 설정이 남아 있고 다른 기기에는 업데이트된 설정이 적용되었다면 내용의 시점 차이가 원인일 수 있습니다. 문제가 있는 기기에서 수동 업데이트를 실행하고 결과를 확인한 뒤 현재 사용할 수 있는 항목을 다시 선택하세요. 업데이트 자체가 실패하면 구독 항목을 확인하세요. 내용이 다른 두 기기를 계속 비교하지 마세요.

특정 대상에서 한 기기만 실패한다면 해당 기기에 로컬 규칙, 다른 DNS 설정, 별도의 시스템 구성이 있는지 확인하세요. 파일을 동기화해도 모든 앱 설정이 포함되는 것은 아니며 시스템 권한까지 완전히 같아지는 것도 아닙니다. 설정을 하나씩 맞출 때 기존 값을 보존하고, ‘완전히 동일하게’ 만들려고 기기에 필요한 로컬 네트워크 또는 업무 환경 설정을 삭제하지 마세요.

로컬 네트워크, On Demand 조건, 장시간 사용 점검

iPad는 같은 Wi-Fi에서 주로 사용하는 경우가 많습니다. 프린터, 화면 미러링, 홈 저장 장치에 접속할 때는 로컬 네트워크 경로와 원격 접속 경로를 구분하세요. 이런 기능만 실패한다면 연결을 끄고 비교한 뒤 기기의 실제 주소와 네트워크 대역을 확인하고 관련 규칙 및 시스템의 로컬 네트워크 권한을 점검하세요. 로컬 서비스 하나를 복구하려고 모든 인터넷 요청을 Direct로 바꾸지 마세요.

On Demand 조건은 현재 iPad가 실제로 연결된 네트워크를 기준으로 확인하세요. 같은 조건을 복사했더라도 두 기기의 Wi-Fi, 네트워크 유형, 도메인 트리거 과정은 다를 수 있습니다. 본인의 On Demand 조건을 잠시 비활성화하고 수동 스위치로 기준 상태를 확인한 뒤 조건을 복원해 하나씩 테스트하세요. 트리거 설정 방법은 On Demand 설정 안내를 참고하세요.

화면을 오랫동안 잠근 뒤 접속이 실패한다면 스위치가 계속 켜져 있는지, 시스템 VPN이 연결되어 있는지, 대상을 다시 열었을 때 복구되는지 확인하세요. 기존 세션만 만료된 경우와 연결 전체가 중지된 경우는 서로 다른 문제입니다. 백그라운드 연결을 사용할 수 없다고 바로 판단하지 말고 화면을 잠그기 전후의 네트워크 변화를 기록하세요. 분할 화면에서 실행 중인 다른 작업도 네트워크를 사용할 수 있으므로 속도 테스트 때는 기기 부하를 비슷하게 유지하세요.

마지막으로 같은 네트워크, 같은 항목, 같은 구성, 같은 대상을 사용해 기기별 결과를 비교한 기록을 남기세요. 기본 조건이 같은데도 차이가 반복된다면 시스템 정보와 오류 메시지 원문을 정리해 문의하세요. 간단한 설명은 자주 묻는 질문에서 확인할 수 있습니다. 전체 절차를 다시 진행해야 한다면 시작하기로 돌아가 가져오기, 라우팅, 권한 승인, 확인 순서대로 진행하세요.