Shadowrocket 문제 해결 가이드

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

이 장에서는 Home의 연결 스위치가 켜진 상태를 유지하지 못하거나, 켜자마자 다시 꺼지거나, 처음 연결할 때 시스템 권한 요청에서 멈추는 경우를 다룹니다. 먼저 ‘터널이 설정되지 않은 경우’와 ‘터널은 설정됐지만 접속할 수 없는 경우’를 구분하세요. 전자는 시스템 권한과 설정 파일 로드를, 후자는 라우팅과 서버를 우선 점검합니다. 상단에 VPN 표시가 나타나는지만으로 모든 요청이 정상 처리됐다고 판단할 수는 없습니다.

시스템 팝업과 현재 작업 확인

처음 연결할 때 시스템에서 VPN 구성을 추가하도록 허용하고 기기 암호나 생체 인증으로 확인하라는 메시지가 표시될 수 있습니다. 이는 시스템에 네트워크 구성을 저장하기 위한 권한 절차이며 구독 확인과는 다릅니다. 팝업의 목적을 이해한 뒤 승인하세요. 이전에 취소했다면 Shadowrocket으로 돌아가 연결을 다시 시도하고 결과를 확인하세요. 팝업을 처리하기 전에 스위치를 반복해서 누르면 어느 작업이 적용됐는지 판단하기 어렵습니다.

팝업 없이 스위치가 바로 꺼진다면 시스템 Settings에서 VPN 및 기기 관리 관련 메뉴를 열어 Shadowrocket 항목이 있는지 확인하세요. 시스템 메뉴 이름은 언어와 화면 구성에 따라 다를 수 있으므로 기기에 표시되는 내용을 기준으로 하세요. 먼저 기존 항목을 기록하고 한꺼번에 삭제하지 마세요. 관리 대상 기기의 네트워크 제한은 관리자가 확인해야 하며, 구성을 반복해서 다시 만들어 우회하려고 해서는 안 됩니다.

설정 로드 및 연결 충돌 확인

Home으로 돌아가 SERVER에 선택할 수 있는 서버가 있는지 확인하고, 현재 선택 항목이 이미 삭제된 구독 항목은 아닌지 살펴보세요. 가져오기에 성공했다는 것은 정보가 저장됐다는 뜻일 뿐, 모든 매개변수가 올바르다는 보장은 아닙니다. 특히 구독을 교체하거나 그룹을 삭제하거나 Config를 다시 가져온 뒤에는 선택 항목이 여전히 유효한지 확인하세요. 편집 직후 문제가 생겼다면 편집 전 백업을 먼저 복원해 테스트하세요.

다른 VPN 구성이 동시에 활성화돼 있거나 시스템 관리 정책이 연결을 다시 설정하고 있는지도 확인하세요. 네트워크를 제어하는 구성이 여러 개면 서로 대체되어 스위치가 꺼졌다 켜지거나 연결 상태가 계속 바뀔 수 있습니다. 관리 권한이 있는 구성이라면 다른 연결을 먼저 중지한 뒤 Shadowrocket만 단독으로 테스트하세요. 시스템의 네트워크 관련 설정을 모두 끄면 새로운 변수가 생길 수 있으므로 피하세요.

On Demand 설정도 점검해야 합니다. 네트워크 조건에 따라 자동으로 연결을 시작해 ‘수동으로 껐는데 다시 켜짐’처럼 보일 수 있습니다. 문제를 해결하는 동안 기존 조건을 기록하고 자동 연결을 잠시 중지한 뒤 수동 스위치로 다시 테스트하세요. 수동 연결은 안정적이고 자동 조건을 복원한 뒤에만 문제가 생긴다면, 서버 암호나 프로토콜 항목을 더 바꾸기보다 조건이 제대로 일치하는지 확인하세요.

최소한의 변경으로 복구 경로 확인

현재 기본 네트워크에서 일반 웹사이트에 접속할 수 있는지 확인한 뒤 연결을 완전히 끄고, 시스템 홈 화면으로 나갔다가 앱을 다시 열어 테스트하세요. 문제가 계속되면 기기를 재시동해 일시적인 시스템 네트워크 상태 문제인지 확인할 수 있습니다. 매번 상태 변경이 끝날 때까지 기다리세요. 스위치를 빠르게 반복해서 누르면 연결 과정이 빨라지는 것이 아니라 로그에 사용자가 중단한 기록만 쌓여 실제 오류 원인을 찾기 어려워질 수 있습니다.

최근 Config를 편집했다면 먼저 사본을 보관한 뒤, 이전에 정상 작동을 확인한 설정으로 전환하세요. 설정 파싱 오류와 원격 연결 오류는 서로 다른 단계의 문제입니다. 전자는 터널 설정 전에 중단될 수 있고, 후자는 보통 터널이 시작된 뒤 발생합니다. 앱에 표시되는 관련 메시지를 확인해 구체적인 오류부터 처리하세요. ‘연결 안 됨’이라는 이유만으로 규칙과 DNS를 한꺼번에 다시 작성하지 마세요.

백업을 완료하고 관리 정책으로 인한 제한이 아닌지 확인한 다음에만 Shadowrocket의 기존 VPN 구성을 제거할지 검토하세요. 이후 앱에서 시스템 권한을 다시 요청할 수 있습니다. 이 작업은 시스템 구성 기록을 처리할 뿐, 만료된 구독이나 잘못된 서버 설정을 고치지는 않습니다. 구독 주소, 인증서, 수동 항목을 별도로 백업했는지 작업 전에 하나씩 확인하세요. 권한을 다시 받는 것만으로 모든 데이터가 복구되는 것은 아닙니다.

이 장의 점검을 마치려면 스위치가 계속 켜져 있고, 시스템에서 권한을 반복 요청하지 않으며, 수동으로 연결을 끌 때 정상적으로 종료돼야 합니다. 이 조건을 충족해도 웹페이지가 열리지 않는다면 다음 장으로 이동하세요. 시스템이 구성을 계속 저장하지 못한다면 표시되는 전체 메시지, 기기 관리 여부와 재시동 후 결과를 기록하고 자주 묻는 질문의 권한 안내를 확인하세요.

연결됐지만 인터넷에 접속할 수 없을 때: 라우팅과 원격 연결 오류 구분

연결 스위치가 켜져 있다는 것은 로컬 터널이 작동 중이라는 뜻일 뿐입니다. 실제 요청은 규칙 매칭, 이름 확인, 원격 연결을 거쳐야 합니다. 먼저 Shadowrocket을 끄고 현재 네트워크에서 평소 정상적으로 접속되는 웹사이트 두 곳을 열어 보세요. 끈 상태에서도 접속되지 않는다면 Config를 바꾸기보다 Wi-Fi 인증, 셀룰러 데이터 권한 또는 기본 네트워크를 먼저 확인하세요. 기본 연결을 확인한 뒤 다시 켜고 같은 대상을 테스트하세요.

Global Routing으로 비교 테스트하기

기존 Global Routing 설정을 기록한 뒤 필요에 따라 Config, Proxy, Direct를 잠시 비교 테스트에 사용하세요. 한국어 설명으로는 각각 설정, 프록시, 직접 연결에 해당하지만 실제 인터페이스 표기는 영어를 유지합니다. 이 설정은 요청이 이동하는 경로를 바꾸기 위한 것이며 모든 네트워크 문제를 해결하는 만능 스위치는 아닙니다. 테스트가 끝나면 원래 필요한 설정으로 되돌려 임시 설정이 계속 적용되지 않도록 하세요.

Proxy에서는 접속되지만 Config에서 실패한다면 실패한 요청에 적용된 규칙, 지정된 정책과 설정의 실제 활성화 여부를 중점적으로 확인하세요. Direct에서는 접속되지만 Proxy에서 실패한다면 현재 서버와 원격 연결 경로를 확인하세요. 터널을 꺼야만 정상으로 돌아오더라도 바로 서버 문제라고 단정하지 마세요. 터널 내부의 DNS, 시스템 권한 및 다른 네트워크 설정이 서로 영향을 주는지도 확인해야 합니다.

규칙 순서를 확인하고 전체 설정을 교체하지 않기

규칙은 일반적으로 설정에 적힌 순서대로 평가됩니다. 범위가 넓은 조건이 앞에 있으면 다른 정책이 필요한 요청이 먼저 매칭될 수 있습니다. 구체적인 도메인에 적용되는 규칙을 찾은 다음 뒤쪽의 기본 처리 규칙을 확인하세요. 아래 예시는 매칭 순서를 설명하기 위한 것으로, 모든 환경에 그대로 사용할 수 있는 완성 설정은 아닙니다. 실제로 적용하기 전에 기존 설정의 정책 이름과 실행 환경이 맞는지 확인해야 합니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

예시에서 첫 번째 규칙은 지정된 도메인과 하위 도메인에 적용되고, 두 번째 규칙은 지리적 주소를 기준으로 판단하며, 마지막 규칙은 앞에서 매칭되지 않은 요청을 처리합니다. 범위가 넓은 규칙을 앞에 두면 뒤의 구체적인 조건이 평가되지 않을 수 있습니다. 수정 전에 현재 Config를 복사하고 사본에서 관련 규칙 하나만 조정한 뒤 같은 요청으로 확인하세요. 전체 설정을 한 번에 교체하면 변경 사항을 되돌리기 어려울 수 있습니다.

웹사이트 첫 화면은 열리지만 이미지나 로그인이 실패한다면 각 요청을 별개의 대상으로 보세요. 한 페이지가 기본 도메인, 정적 리소스 도메인, 인증 도메인을 함께 사용할 수 있습니다. 첫 화면 도메인에만 규칙을 추가해도 관련 리소스가 같은 경로를 이용한다는 보장은 없습니다. 관련 요청의 도메인과 실제 적용 정책을 확인한 뒤 필요한 조건만 추가하세요. 리소스 하나를 해결하려고 모든 트래픽을 다른 경로로 돌리지 마세요.

규칙 판정과 서비스 응답을 구분하기

앱에서 연결 기록을 제공한다면 문제를 한 번 재현한 뒤 대상 도메인, 매칭된 규칙, 선택된 정책과 오류 유형을 확인하세요. 기록이 백그라운드 새로고침이 아닌 이번 작업에서 나온 것인지 먼저 확인해야 합니다. HTTP 상태 코드, 인증 실패 또는 웹사이트의 접속 거부는 연결 자체가 안 되는 문제와 다릅니다. 원격 서비스에서 응답을 받았다면 단순 시간 초과보다는 애플리케이션 단계에 가까우므로 응답 내용을 바탕으로 계속 확인하세요.

규칙이 REJECT라면 요청이 의도적으로 거부된 것이 설정의 예상 결과일 수 있습니다. 웹페이지 요소가 표시되지 않을 때는 서버 오류로 단정하기 전에 해당 리소스에 이런 규칙이 적용됐는지 확인하세요. 허용해야 한다면 관련 조건만 조정하고 이유를 기록하세요. 이름 확인 실패는 이후 주소 기반 판단에도 영향을 줄 수 있으므로 이와 관련된 현상이라면 DNS 장도 확인하세요.

이 장의 점검을 마치려면 ‘어떤 대상이 어떤 모드에서 어떤 정책을 통해 실패했는지’를 설명할 수 있어야 합니다. 막연한 연결 상태 화면보다 이런 결론을 기록하는 편이 유용합니다. Proxy에서 모든 대상이 시간 초과되면 서버 시간 초과 장으로 이동하세요. Config에서만 문제가 생기면 규칙을 자세히 확인하세요. 모든 경로에서 이름 확인 오류가 발생한다면 DNS를 우선 점검하고, 이미 정상이라고 확인한 서버 정보를 반복해서 바꾸지 마세요.

서버 시간 초과: 서버와 프로토콜 설정을 단계별로 확인

Connectivity Test의 시간 초과는 정해진 조건 안에 테스트가 예상한 결과를 얻지 못했다는 뜻이며, 모든 실제 요청이 반드시 실패한다는 의미는 아닙니다. 테스트 방법에 따라 대상과 프로토콜이 다를 수 있으므로 실제 웹사이트 접속도 함께 살펴보세요. 먼저 한 항목만 시간 초과인지, 같은 구독의 여러 항목인지, 보유한 모든 항목인지 기록하세요. 문제 범위에 따라 점검 방향이 달라지며 숫자 하나만으로 사용 가능 여부를 비교할 수는 없습니다.

네트워크 범위에 따라 점검 방향 정하기

현재 네트워크에서 이전에 정상 작동을 확인한 대상을 테스트한 뒤, 허용되는 다른 네트워크에서도 다시 확인하세요. 같은 서버가 셀룰러 데이터에서는 정상이고 특정 Wi-Fi에서 실패한다면 해당 네트워크의 인증 상태, 접속 제한과 외부 연결 조건을 확인하세요. 모든 네트워크에서 실패한다면 서버 실행 여부, 포트, 계정 유효성, 서버 설정의 변경 여부를 중점적으로 확인해야 합니다.

연속으로 여러 항목을 한꺼번에 테스트하는 것으로 원인을 찾으려 하지 마세요. 하나를 선택하고 테스트가 끝난 뒤 실제 접속 결과를 확인하세요. 대량의 동시 요청은 결과에 영향을 주거나 원격 제한을 유발할 수 있습니다. 시간과 네트워크 유형을 기록하면 지속적인 장애와 일시적인 변동을 구분하는 데 도움이 됩니다. 특정 시간대에만 실패한다면 그 시간대의 반복 결과를 보관하세요. 한 번 성공했다고 설정이 완전히 복구된 것은 아닙니다.

서버에서 제공된 원본 정보와 항목별로 비교

서버 주소와 포트는 본인의 서버 정보와 일치해야 합니다. 주소 앞뒤의 공백, 복사 과정에서 섞인 줄바꿈, 잘못된 포트는 연결을 방해할 수 있습니다. 포트는 임의로 바꿔 보아도 되는 값이 아니라 서버가 실제로 수신 대기 중인 포트여야 합니다. 도메인을 사용한다면 이름 확인 결과가 올바른지 확인하세요. 주소를 임시 비교에 사용할 때도 기존에 필요한 TLS 호스트 이름의 의미는 유지해야 합니다.

전송 계층 설정이 있는 항목은 전송 유형, 경로와 관련 호스트 항목도 서버 정보와 대조해야 합니다. 주소는 서버를 찾는 데 쓰이고, TLS 호스트 이름은 상대방의 신원을 확인하며, 일부 전송의 호스트 항목은 요청 라우팅에 사용됩니다. 이 값들은 항상 같은 의미가 아닙니다. 서버에서 동일한 값을 요구하는 경우에만 같게 설정하고, 도메인 입력란이 여러 개 있다고 해서 같은 값을 무조건 복사하지 마세요.

인증서 오류에는 보통 ‘시간 초과’보다 구체적인 메시지가 표시됩니다. 기기의 날짜와 시간, 인증서 유효 기간 및 이름 일치 여부를 확인하세요. 인증서 확인을 끄는 것은 일반적인 해결책이 아닙니다. 보안 경계를 바꾸면서 서버 인증서 설정 자체의 문제는 해결하지 못합니다. 서버를 직접 관리한다면 해당 인증서와 서버 설정을 수정하세요. 기존 서비스 정보를 사용하는 경우에는 임의로 조합을 추측하지 말고 유효한 매개변수를 확인하세요.

전송 제한과 서버 문제 구분

일부 프로토콜이나 기능은 UDP에 의존합니다. 일반 웹페이지에 접속되는 네트워크라고 해서 관련 트래픽까지 도달할 수 있는 것은 아닙니다. 특정 네트워크에서만 어떤 전송 방식이 실패한다면 네트워크 차이와 서버 요구 사항을 함께 확인하세요. 근거 없이 MTU, 연결 유지 또는 시간 초과 설정을 바꾸지 마세요. 패킷 분할, 경로 또는 유휴 연결 문제를 뒷받침하는 증거가 없다면 설정 변수가 늘어나 단순한 장애가 더 복잡해질 수 있습니다.

직접 관리하는 서버라면 서비스 실행 상태, 수신 포트, 방화벽과 같은 시간대의 서버 기록을 확인하세요. 클라이언트에 연결 종료가 표시돼도 원격 서버가 끊었을 수도 있고 중간 네트워크가 끊겼을 수도 있습니다. 하나의 메시지만으로 원인을 확정할 수는 없습니다. 클라이언트와 서버의 시간을 대조해 요청이 도달했는지, 어느 단계에서 멈췄는지 확인하세요. 점검 기록에 전체 인증 정보를 복사할 필요는 없습니다.

구독을 업데이트한 뒤 기존 항목이 사라지거나 주소가 바뀌었다면 현재 유효한 정보를 기준으로 항목을 다시 선택하세요. 더 이상 관리되지 않는 로컬 항목을 계속 테스트하지 마세요. 구독 목록에 표시되는 이름은 식별용일 뿐, 이름이 같아도 실제 매개변수까지 같다는 뜻은 아닙니다. 복구 후 실패한 네트워크, 오류 단계, 수정한 항목과 실제 접속 결과를 기록하세요. 구독을 계속 새로고침할 수 없다면 다음 장에서 가져오기와 파싱 과정을 확인하세요.

Subscribe 실패: 가져오기, 파싱, 항목 변경 구분

구독 업데이트는 주소 요청, 응답 수신, 내용 파싱, 항목 저장이라는 여러 단계로 이루어집니다. 어느 단계에서든 실패할 수 있습니다. 기존에 작동하던 항목을 먼저 보존하고 삭제한 뒤 업데이트를 시도하지 마세요. 일시적인 요청 실패로 사용할 수 있는 로컬 정보까지 지워질 수 있습니다. 오류 메시지를 기록하고 연결 시간 초과, 상태 오류, 지원하지 않는 형식, 업데이트 성공 후 항목 수 변경을 구분하세요.

주소를 안전하게 보관하고 전체 여부 확인

구독 주소에 접근 자격 정보가 들어 있을 수 있으므로 민감 정보로 취급하세요. 복사할 때 뒷부분의 매개변수가 빠지지 않았는지, 공백이나 문장 부호 또는 메신저가 추가한 줄바꿈이 섞이지 않았는지 확인하세요. 전체 주소를 공개 게시판에 올리거나 출처를 알 수 없는 페이지에서 내용을 변환하지 마세요. 구조를 다른 사람에게 설명해야 한다면 도메인 유형과 매개변수 이름만 남기고 계정을 식별할 수 있는 값은 가리세요.

브라우저에서 주소가 열린다고 해서 가져올 수 있는 내용이 반환됐다는 뜻은 아닙니다. 브라우저에 로그인 상태가 남아 있거나 웹페이지, 인증 화면 또는 접속 오류 안내가 표시될 수 있습니다. 앱의 안내와 구독 제공자가 안내한 내용을 바탕으로 응답 유형을 확인하세요. 원본 응답을 확인할 때도 예상한 형식인지 살펴보는 데 그치고, 인증 정보가 포함될 수 있는 전체 텍스트를 공개된 곳에 복사하지 마세요.

네트워크 오류와 콘텐츠 오류를 구분

요청 시간 초과나 도메인 이름 확인 실패라면 네트워크와 DNS를 확인하세요. 명확한 인증 실패라면 주소 만료 여부, 계정 상태와 자격 정보 변경 여부를 살펴보세요. 요청이 너무 많다는 메시지가 표시되면 새로고침을 반복하지 말고 안내에 따라 기다린 뒤 다시 시도하세요. 항목을 계속 삭제하고 다시 추가해도 접근 권한은 복구되지 않으며, 오히려 서버에 반복 요청이 쌓여 원인을 파악하기 어려워질 수 있습니다.

구독을 가져올 때 현재 프록시가 필요한데 그 프록시가 만료된 구독에서 제공된다면 업데이트가 서로 의존하는 상황이 생길 수 있습니다. 해당 주소를 현재 네트워크에서 직접 접속할 수 있는지, 앱이 업데이트 요청을 어떤 방식으로 처리하는지 먼저 확인하세요. 정상 작동을 확인한 다른 경로가 있다면 한 번 비교해 볼 수 있습니다. 없다면 기본 연결부터 복구해야 합니다. 한 번의 업데이트로 모든 네트워크 문제가 자동 해결되리라 기대하지 마세요.

형식 오류가 발생하면 서버에서 제공한 내용이 현재 Shadowrocket에서 지원하는 가져오기 형식인지 확인하세요. 웹 링크, 설정 파일 주소, 서버 공유 정보는 서로 다른 항목이므로 복사할 수 있다는 이유만으로 같은 입력란에 넣어서는 안 됩니다. 원본 정보에 맞춰 Subscribe 또는 해당 가져오기 작업을 선택하세요. 처음 사용하는 기능이라 입력 위치가 확실하지 않다면 빠른 시작으로 돌아가 기본 절차를 확인하세요.

‘업데이트 성공’ 후 항목 상태 확인

업데이트에 성공했는데 목록이 비었다면 반환된 내용에 실제 유효한 항목이 포함돼 있는지, 필터가 적용됐는지 확인하세요. 서버에서 항목을 정상적으로 제거해 목록이 줄었을 수도 있으므로 앱에서 항목이 사라졌다고 바로 판단하지 마세요. 현재 결과를 먼저 저장하고 보유한 구독 안내와 대조한 뒤 이름 필터, 그룹 차이 또는 일시적인 응답 오류가 있는지 확인하세요. 원인을 파악하기 전에 유일한 로컬 백업을 여러 번 덮어쓰지 마세요.

구독에서 생성된 항목을 수동으로 편집하면 다음 업데이트에서 서버 정보로 다시 덮어쓸 수 있습니다. 테스트용 매개변수는 수동 항목으로 별도 저장하고 원본 구독 항목은 비교용으로 남겨 두세요. 두 항목의 이름을 구분해 편집한 내용이 적용되지 않은 것으로 착각하거나 실제로는 다른 항목을 테스트하는 일이 없도록 하세요. 점검이 끝나면 임시 사본을 정리해 오래된 테스트 정보가 나중에 선택되지 않도록 하세요.

가져온 항목과 Config 활성화 여부도 각각 확인하세요. Subscribe는 서버 정보 업데이트를 위한 기능이며, 모든 규칙, DNS와 정책이 현재 네트워크에 맞는다는 보장은 없습니다. 새 항목이 Home에 표시되더라도 유효한 서버를 선택하고 Global Routing을 확인한 뒤 실제 접속을 테스트해야 합니다. 목록은 업데이트됐지만 연결할 수 없다면 같은 주소를 반복해서 가져오지 말고 서버 시간 초과 장을 확인하세요.

복구 가능한 업데이트 습관 만들기

큰 변경을 하기 전에 보관해야 할 수동 정보와 Config를 백업하고 백업에 어떤 내용이 포함됐는지 확인하세요. 내보내기 방식에 따라 저장되는 데이터 범위가 다르므로 파일이 하나 있다는 이유만으로 모든 정보가 보존됐다고 볼 수 없습니다. 민감한 백업은 직접 관리하는 안전한 위치에 보관하세요. 문제를 공유할 때는 오류 유형, 발생 시간과 자격 정보를 제거한 최소한의 구조만 제공하세요.

이 장의 점검을 마치려면 목록에 한 번 표시되는 것뿐 아니라 업데이트를 반복할 수 있고, 항목 내용이 예상과 일치하며, 선택한 항목을 실제로 사용할 수 있어야 합니다. 주소가 이미 만료됐다면 보유한 서비스의 관리 절차에 따라 정보를 업데이트하세요. 앱 구매와 구독 유효성은 서로 별개의 관계입니다. 구매 또는 구입 항목 복원 문제는 구입 항목 복원 안내에서 확인하세요. 구독 문제를 해결하려고 앱을 반복해서 구매하지 마세요.

속도가 느릴 때: 응답 시간·전송량·안정성을 나눠 측정

‘느리다’는 현상에는 첫 화면을 여는 데 오래 걸림, 전송 시작 후 처리량이 낮음, 재생이 자주 끊김, 네트워크 전환 후 잠시 연결이 중단됨 등이 포함됩니다. 먼저 현상을 구체적으로 기록한 뒤 무엇을 측정할지 정하세요. Connectivity Test 결과는 특정 테스트 조건만 반영하므로 대용량 전송 속도나 모든 웹사이트의 성능을 그대로 나타내지 않습니다. 테스트 시간이 한 번 짧게 나와도 이후 패킷 손실이나 원격 혼잡까지 배제할 수는 없습니다.

비교 가능한 테스트 조건 마련

평소 접속되는 고정 대상을 하나 정하고 같은 기기, 같은 네트워크, 비슷한 시간대에 비교하세요. 먼저 연결을 끈 상태의 기본 접속을 테스트한 다음 현재 설정을 확인하고, 마지막으로 보유한 다른 유효 항목으로 바꿔 보세요. 매번 조건 하나만 바꾸고 다른 앱의 다운로드와 동기화 상태는 최대한 동일하게 유지하세요. 네트워크, 서버, 규칙을 한꺼번에 바꾸면 개선 원인을 파악할 수 없어 같은 결과를 재현하기 어렵습니다.

속도가 느려지는 단계를 살펴보세요. 주소를 입력한 뒤 시작까지 오래 걸린다면 이름 확인, 연결 설정 또는 핸드셰이크 문제일 수 있습니다. 전송이 시작된 뒤에도 속도가 낮다면 회선 용량, 패킷 손실과 서버 부하를 살펴보세요. 한 페이지의 일부 리소스만 늦게 표시된다면 관련 도메인에 다른 정책이 적용됐을 수 있습니다. 단순히 ‘오래 걸렸다’고 기록하는 것보다 단계별로 판단하는 편이 점검 범위를 좁히는 데 도움이 됩니다.

로컬 네트워크와 대상별 차이 확인

Wi-Fi 신호 막대만으로 네트워크 품질을 완전히 알 수는 없습니다. 거리, 간섭, 액세스 포인트 부하와 인터넷 회선이 전송에 영향을 줍니다. 먼저 액세스 포인트 가까이에서 테스트하고 같은 네트워크에서 대량의 백그라운드 전송이 없는지 확인한 뒤 셀룰러 데이터와 비교하세요. 특정 Wi-Fi에서만 느리다면 해당 네트워크를 우선 확인하세요. 셀룰러 데이터에서도 문제가 있다면 기기의 저데이터 모드나 앱 네트워크 권한 제한을 살펴보세요.

같은 프록시 항목으로 서로 다른 대상에 접속해도 속도 차이가 크게 날 수 있습니다. 원격 출구에서 대상 웹사이트까지의 경로가 다르기 때문입니다. 대상 서버의 부하, 콘텐츠 배포 노드와 계정 측 제한도 결과에 영향을 줄 수 있습니다. 범위를 확인하려면 한 곳 이상의 대상을 사용하되 대량의 동시 속도 테스트는 필요하지 않습니다. 특정 웹사이트 하나가 느리다는 사실만으로 앱 전체의 성능 이상이라고 단정하거나 모든 설정을 바꾸지 마세요.

규칙, 재시도와 백그라운드 부하 확인

Config에서 일부 리소스가 REJECT되거나 사용할 수 없는 정책으로 전달되면 웹페이지가 재시도를 기다리느라 느려 보일 수 있습니다. 먼저 실패한 요청이 같은 도메인이나 정책에 집중되는지 확인한 뒤 규칙 순서를 살펴보세요. Proxy에서는 페이지가 완전히 표시되지만 Config에서 지연된다면 관련 규칙만 비교 테스트하면 됩니다. 문제를 점검하는 동안 모든 요청의 경로를 계속 바꿀 필요는 없습니다.

구독을 자주 새로고침하거나 여러 연결 테스트를 한꺼번에 실행하거나 진단 기록을 과도하게 수집하는지도 확인하세요. 이런 작업이 근본 원인은 아니더라도 네트워크와 처리 자원을 사용해 테스트 결과를 방해할 수 있습니다. 문제를 해결하는 동안 불필요한 반복 작업을 중지하고 필요한 항목만 관찰하세요. 더 많은 정보를 얻겠다고 상세 기록을 무기한 유지하지 마세요. 재현 조건을 찾으면 필요한 부분만 저장한 뒤 일상적인 설정으로 되돌리세요.

전송 매개변수는 보유한 서버의 요구 사항을 기준으로 설정해야 합니다. 동시 연결 수를 임의로 늘리고, 시간 초과를 계속 줄이거나 MTU를 바꿔도 속도 개선이 보장되지 않습니다. 오히려 연결 재설정과 재전송이 늘 수 있습니다. 특정 문제를 뒷받침하는 근거가 있을 때만 관련 매개변수를 테스트하세요. 예를 들어 특정 네트워크에서 큰 패킷만 전송되지 않고 작은 요청은 정상일 때를 들 수 있습니다. 테스트 전에 기존 값을 저장하고 어떤 결과를 개선으로 볼지, 어떤 경우에 되돌릴지 정하세요.

실제 작업으로 개선 여부 확인

다른 유효 항목으로 바꾼 뒤 정상으로 돌아왔다면 같은 조건에서 기존 항목이 여전히 느린지 다시 확인하세요. 시간 변화가 서버 차이로 오인되지 않도록 해야 합니다. 같은 네트워크에서 모든 항목이 느리고 다른 네트워크에서는 정상이라면 로컬 외부 연결을 더 살펴보세요. 모든 네트워크에서 특정 대상만 느리다면 대상 서비스와 접속 경로를 확인하세요. 우연히 한 번 성공한 결과가 아니라 최소 한 번은 비교 테스트를 반복해 결론을 내리세요.

기기 온도와 백그라운드 작업도 고려해야 합니다. 시스템 업데이트 직후, 사진 동기화 중이거나 많은 콘텐츠를 색인하는 동안에는 기기가 여러 작업을 동시에 처리해 웹페이지 표시가 늦어질 수 있습니다. 콘텐츠 다운로드 완료와 페이지 표시 완료를 구분해 관찰하세요. 기기가 눈에 띄게 뜨거우면 고부하 작업을 멈춘 뒤 다시 테스트하세요. 충전하면서 높은 부하를 계속 유지한 채 미세한 차이를 비교하지 마세요.

마지막으로 처음 문제가 발생한 작업을 다시 수행해 안정적으로 탐색되는지, 재생 중 멈춤이 있는지, 네트워크 전환 후 복구되는지 확인하세요. 테스트 수치 하나가 낮아지는 것만 목표로 삼지 마세요. 설명에 도움이 되는 기록 두세 개면 충분합니다. 기다림이 주로 도메인의 첫 이름 확인 단계에서 발생한다면 다음 장으로 이동하세요. 속도 저하와 배터리 소모가 함께 나타나면 배터리 장에서 백그라운드 재연결과 진단 작업도 확인하세요.

DNS 문제: 이름 확인 경로와 캐시 확인

DNS는 도메인 이름을 이후 연결에 필요한 주소로 변환합니다. 이름 확인에 성공해도 서비스에 접속할 수 있다는 뜻은 아니며, 이름 확인 실패가 서버 인증 오류를 뜻하지도 않습니다. 특정 도메인이 열리지 않거나 첫 접속이 오래 걸리고, 네트워크 전환 후 잠시 오류가 나거나 같은 도메인의 결과가 경로마다 다른 경우가 흔합니다. 먼저 대상 도메인과 구체적인 오류를 기록한 뒤 문제가 실제로 이름 확인 단계에서 발생했는지 확인하세요.

시스템 DNS, 사용자 지정 DNS, 암호화된 DNS 구분

시스템 DNS는 보통 현재 네트워크에서 제공받고, 사용자 지정 DNS를 설정하면 이름 확인 요청에 사용할 서비스가 달라집니다. DNS over HTTPS는 HTTPS로 이름 확인 요청을 전송하지만, 기본 네트워크 연결과 올바른 인증서 확인, 사용 가능한 서비스 주소가 여전히 필요합니다. 설정만 입력한다고 모든 연결 문제가 해결되는 것은 아닙니다. 형식만 보고 신뢰성을 판단하지 말고 현재 네트워크 조건에 맞는 방식을 선택하세요.

암호화된 DNS 서비스가 도메인 이름을 진입점으로 사용한다면 처음 연결할 때 해당 주소를 어떻게 확인하는지, 요청이 어떤 경로를 거치는지도 고려해야 합니다. 기존 프록시가 전혀 작동하지 않는데 DNS 서비스에 도달하려면 그 프록시가 필요하다면 DNS 요청도 실패할 수 있습니다. 먼저 이런 의존 관계를 정리한 뒤 도달 가능한 방식으로 비교하세요. DNS, 서버와 모든 규칙을 한꺼번에 바꾸면 오류 경로가 더 복잡해집니다.

도메인 하나로 반복 가능한 점검

반복해서 실패하는 도메인 하나를 고르고 같은 네트워크에서 연결을 끈 상태와 켠 상태를 각각 확인하세요. 연결을 켠 뒤에만 실패한다면 현재 Config의 DNS 설정과 이름 확인 요청 경로를 확인하세요. 두 상태에서 모두 실패한다면 네트워크 측 이름 확인과 대상 서비스 상태를 살펴보세요. 테스트에는 완전히 같은 도메인을 사용하세요. 홈페이지 도메인과 이미지 리소스 도메인의 서로 다른 결과를 같은 비교 테스트로 간주하면 안 됩니다.

‘주소를 직접 입력하면 접속된다’는 사실만으로 도메인 문제라고 단정하지 마세요. HTTPS 서비스는 TLS 호스트 이름과 가상 호스트 라우팅에 의존할 수 있습니다. 주소를 직접 입력하면 요청의 의미가 달라져 결과를 단순 비교할 수 없습니다. 이름 확인 기록, 오류 단계와 실제 연결 기록을 함께 살펴보는 편이 좋습니다. 특정 주소로 테스트해야 한다면 서비스에 필요한 호스트 이름을 유지하고 인증을 끄지 마세요.

규칙과 이름 확인의 상호작용 이해

DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD는 도메인 조건을 기준으로 판단하며 IP-CIDR, IP-CIDR6, GEOIP는 주소 조건과 관련이 있습니다. 먼저 이름 확인이 필요한지, 어떤 주소가 반환되는지, 이후 어떻게 매칭되는지는 실제 규칙과 설정에 따라 다릅니다. 문제를 해결할 때 모든 요청이 도메인 규칙에 한 번만 매칭된다고 가정하지 말고 실패한 요청이 실제로 어떻게 처리됐는지 확인하세요.

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

위 주소 범위는 문서 예시이며 실제 네트워크를 설정하는 데 그대로 사용해서는 안 됩니다. no-resolve는 주소 규칙이 매칭을 위해 도메인 이름 확인을 직접 유발하지 않는다는 뜻이지, 전체 DNS를 중단한다는 뜻은 아닙니다. 이 차이를 이해해야 이름 확인을 한 번 줄이려다 설정 전체의 동작을 바꾸는 일을 피할 수 있습니다. 예시로 학습한 뒤에는 기존 설정으로 돌아가 관련 규칙을 확인하고 사용 중인 내용을 그대로 덮어쓰지 마세요.

IPv4와 IPv6도 함께 살펴보세요. 어떤 네트워크가 IPv6 주소를 반환해도 해당 경로가 안정적으로 작동하지 않을 수 있습니다. 일부 요청이 대기한 뒤 다른 주소로 전환되는 현상이 생길 수 있습니다. 먼저 네트워크별 결과를 비교하고 주소 계열과 연결 기록을 확인하세요. 근거 없이 IPv6 관련 설정을 모두 끄지 마세요. 주소 선택을 바꾸면 다른 요청에도 영향을 줄 수 있으므로 원상 복구 경로를 확보해야 합니다.

캐시와 설정 덮어쓰기 확인

DNS 설정을 바꿔도 기존 연결, 앱 캐시 또는 시스템 캐시 때문에 잠시 동안 예상과 다른 결과가 나올 수 있습니다. 현재 연결을 끊고 새로 연결한 뒤 새로운 요청을 테스트하세요. 필요하면 대상 앱의 이전 세션을 종료하고 다시 접속하세요. 꼭 필요한 경우에만 기기를 재시동하고, 재시동 후 우연히 정상으로 돌아온 것을 최종 해결로 여기지 마세요. 변경 사항이 지속되는지 기록해야 캐시 영향인지 원래 간헐적인 문제인지 판단할 수 있습니다.

기기에 다른 DNS 구성 프로파일이 설치돼 있는지, 현재 Config가 앱 내 다른 메뉴의 설정을 덮어쓰는지도 확인하세요. 설정 화면에 값이 입력돼 있다고 해서 이번 요청에 실제로 적용됐다는 뜻은 아닙니다. 적용된 설정과 기록을 기준으로 덮어쓰기 여부를 하나씩 확인하세요. 관리 대상 기기의 조직 배포 네트워크 설정은 임의로 제거하지 말고, 관리 요구 사항과 본인의 권한을 먼저 확인하세요.

이 장의 점검을 마치려면 대상 도메인이 적절한 결과를 반환하고, 이후 연결이 계속되며, 네트워크를 바꿔도 정상 동작을 다시 확인할 수 있어야 합니다. 자세한 설정 안내는 Shadowrocket DNS 설정 상세 안내를 참조하세요. 이름 확인은 정상인데 핸드셰이크가 실패한다면 서버 설정을 다시 확인하세요. 일부 리소스만 거부된다면 규칙 장으로 돌아가고 이미 정상임을 확인한 DNS를 계속 바꾸지 마세요.

배터리 소모와 업데이트 후 오류: 백그라운드 활동 및 설정 변경 확인

배터리 소모 증가와 업데이트 후 오류는 함께 언급되는 경우가 많지만 각각 별도로 확인해야 합니다. 배터리 문제는 관찰 시간 동안의 실제 활동을 살펴보고, 업데이트 후 오류는 무엇이 바뀌었는지 확인해야 합니다. 연결이 계속 켜져 있다고 해서 항상 대량 전송이 이뤄지는 것은 아닙니다. 시스템 배터리 사용량에서 앱 비중이 높다고 해서 전체 배터리 소모의 원인이 그 앱 하나라는 뜻도 아닙니다. 비교 가능한 사용 조건을 정한 뒤 지속적인 이상 여부를 판단하세요.

비교 가능한 배터리 사용량 관찰

시스템 Settings의 배터리 사용량에서 비슷한 길이의 시간 구간을 비교하고 화면 켜짐 시간, 신호 상태, 충전 여부와 주요 작업을 함께 기록하세요. 약한 신호, 동영상 재생, 핫스팟 공유와 백그라운드 동기화는 기기 전체의 배터리 소모를 늘릴 수 있습니다. 한 구간은 주로 대기 상태였고 다른 구간은 계속 데이터를 전송했다면 두 비율을 직접 비교할 수 없습니다. 최대한 비슷한 작업 조건에서 사용 추이를 확인하세요.

네트워크 확장은 다른 앱의 터널 통신을 처리하므로 시스템 사용량은 전체 데이터 흐름과 함께 해석해야 합니다. Data의 활동 내역과 비교해 예상하지 못한 대량 전송이 있는지 확인할 수 있지만, 통계에 표시된 항목만 보고 어떤 프로세스가 유휴 상태로 계속 작동한다고 단정하지 마세요. 당시 사진 동기화, 콘텐츠 다운로드 또는 다른 백그라운드 요청이 있었는지 확인한 뒤 Shadowrocket 설정을 바꿀지 결정하세요.

반복 재연결과 진단 부하 확인

연결 실패 후 계속 재시도하면 안정적으로 연결된 상태보다 핸드셰이크와 네트워크 깨우기가 많아질 수 있습니다. 신호가 불안정할 때 연결이 자주 재설정되는지, 테스트가 지나치게 자주 실행되는지, On Demand 조건이 반복해서 작동하는지 확인하세요. 기존 설정을 저장하고 불필요한 자동 테스트와 진단을 잠시 중지한 뒤 같은 시간 동안 관찰하세요. 배터리를 아끼려고 서버 요구 사항인 연결 유지 설정을 무작정 바꾸면 유휴 상태 이후 연결이 끊길 수 있습니다.

상세 로그는 문제를 짧게 재현할 때 유용하지만 목적 없이 계속 수집하기에는 적합하지 않습니다. 로그에는 도메인, 주소와 사용 정보가 포함될 수 있으므로 점검이 끝나면 일상적인 설정으로 되돌리고 민감한 기록은 필요에 따라 정리하세요. 기기가 눈에 띄게 뜨거우면 고부하 작업을 멈추고 상태가 안정된 뒤 비교를 계속하세요. 높은 온도가 지속된다면 기기와 시스템의 다른 원인도 확인해야 합니다.

업데이트로 바뀐 항목이 어느 단계인지 확인

앱 업데이트, 시스템 업데이트, 구독 새로고침과 원격 Config 업데이트는 서로 다른 변경입니다. 마지막으로 정상 사용한 뒤 무엇을 했는지 되짚어 각각 기록하세요. 앱 업데이트 여부는 App Store에서 확인하고 시스템 요구 사항은 App Store 페이지의 안내를 기준으로 하세요. 구독이나 원격 설정은 앱 업데이트와 별도로 바뀔 수 있습니다. 시기가 비슷하다는 이유만으로 모든 문제가 앱 업데이트 때문이라고 단정하지 마세요.

현재 데이터를 보존하고 이전에 정상 작동을 확인한 서버와 설정으로 최소한의 재테스트를 하세요. 수동으로 연결한 뒤 고정된 대상을 방문합니다. 서버는 그대로인데 Config가 바뀌었다면 규칙, DNS와 정책 참조를 우선 비교하세요. 구독 항목만 바뀌었다면 관련 필드를 다시 확인하세요. 정보는 그대로인데 시스템 권한 상태가 바뀌었다면 연결 스위치 장으로 돌아가 권한과 시스템 기록을 점검하세요.

설정을 비교할 때는 파일 이름이 아니라 실제 필드 차이를 살펴보세요. 이름이 같은 원격 파일도 업데이트됐을 수 있고, 이름이 다른 로컬 사본의 내용은 같을 수 있습니다. 이전 사본을 복원하면 원인을 찾는 데 도움이 될 수 있지만 필요한 변경을 계속 무시하라는 뜻은 아닙니다. 오류를 일으킨 차이를 확인했다면 용도를 이해한 뒤 수정하거나 복원하세요. 새 설정을 모두 삭제하는 방식은 피해야 합니다.

재설치는 첫 번째 해결 방법이 아닙니다

재설치 전에 백업 범위, 구독 주소와 수동 항목의 저장 위치를 확인하고 App Store 구매 계정도 확인하세요. 앱을 다시 받을 수 있다고 해서 로컬 설정까지 자동으로 모두 복원되는 것은 아닙니다. 구매 복원은 구입 항목 복원을 참조하세요. 이 절차는 앱을 다시 받을 권한을 처리하며 본인의 서비스 정보를 복원하거나 원격 서버의 작동 여부를 바꾸지는 않습니다.

환경을 다시 구성해야 한다면 한 번에 일부만 복원하세요. 먼저 권한과 기본 연결을 확인하고, 다음으로 보유한 유효한 서버를 복원한 뒤 마지막으로 전체 규칙과 추가 설정을 복원합니다. 이렇게 하면 어느 단계에서 문제가 다시 나타나는지 찾을 수 있습니다. 모든 백업을 한꺼번에 가져와 바로 테스트하면 문제가 여전히 있다는 것만 알 수 있고, 원인이 기존 설정인지 네트워크 조건인지 백그라운드 동작인지 구분하기 어렵습니다.

이 장의 점검을 마치려면 비정상적인 활동이 줄고 자주 사용하는 작업이 정상이며 비슷한 조건에서 같은 결과를 다시 확인할 수 있어야 합니다. 문제를 공유할 때는 시스템 유형, 네트워크 유형, 변경 범주와 민감 정보를 제거한 오류 내용만 제공하면 됩니다. 전체 백업을 공개할 필요는 없습니다. 같은 정보로 다른 기기에서는 정상인데 iPad에서만 문제가 생긴다면 다음 장에서 기기별 네트워크와 설정 차이를 확인하세요.

iPad 전용 점검: 네트워크 권한과 설정 일치 여부

iPad와 iPhone은 같은 유형의 서버 정보를 사용할 수 있지만 네트워크 조건까지 같다고 보장할 수는 없습니다. Wi-Fi만 사용하거나 셀룰러 데이터를 이용하거나 핫스팟에 연결하는 경우, 관리 대상 네트워크 설정 등이 차이를 만들 수 있습니다. 한 기기에서 같은 구독이 정상이라고 해서 다른 기기의 앱이 손상됐다고 단정하지 마세요. 먼저 실제 네트워크, 선택한 항목과 적용 중인 Config를 두 기기에서 맞춘 뒤 비교하세요.

기본 네트워크가 실제로 작동하는지 먼저 확인

공용 Wi-Fi에 연결한 뒤 네트워크 자체의 인증 페이지에서 로그인해야 할 수 있습니다. 상태 표시줄에 연결이 표시돼도 외부 대상에 접속할 수 있다는 뜻은 아닙니다. 먼저 연결을 끄고 네트워크의 정식 인증을 완료한 뒤 일반 웹페이지에 접속해 확인하세요. 기본 네트워크가 복구된 다음 Shadowrocket을 켜세요. 인증 세션이 만료됐다면 네트워크 로그인을 먼저 처리해야 하며 구독을 반복해서 업데이트해도 해결되지 않습니다.

셀룰러 데이터를 사용하는 기기는 시스템 Settings에서 앱의 셀룰러 데이터 사용이 허용됐는지, 백그라운드 활동에 영향을 주는 제한이 켜져 있는지 확인하세요. Wi-Fi만 지원하는 기기에는 없는 셀룰러 옵션을 찾을 필요가 없습니다. 시스템 요구 사항과 지원 기기는 App Store 페이지의 안내를 기준으로 하세요. 최초 설치와 권한 절차는 iPad 설치 안내에서 확인할 수 있습니다. 다른 기기의 메뉴 위치를 보고 추측하지 마세요.

이름이 같아도 설정은 같지 않을 수 있습니다

두 기기를 비교할 때 표시 이름만 보지 말고 서버 주소, 포트, 프로토콜, TLS와 전송 항목을 하나씩 확인하세요. 구독이 서로 다른 시점에 업데이트됐을 수 있고 목록에서 이름이 같은 항목도 이미 내용이 바뀌었을 수 있습니다. 이어서 Global Routing과 실제 선택된 Config를 확인하세요. 한 기기는 Proxy, 다른 기기는 Config라면 접속 결과가 다른 이유는 기기 성능이 아니라 규칙일 수 있습니다.

큰 화면에서는 목록과 상세 정보가 다른 방식으로 표시될 수 있습니다. 설정 상세 화면을 열었다고 해서 그 항목이 현재 사용 중이라는 뜻은 아닙니다. 서버 하나를 편집해도 실제로 선택된 다른 항목은 바뀌지 않을 수 있습니다. 편집이 끝나면 실제 선택 화면으로 돌아가 적용된 항목을 확인하세요. 인터페이스 용어가 익숙하지 않다면 Home, Config, Settings 용어 안내를 읽어 보세요.

백업을 가져온 뒤에는 어떤 내용이 복원됐는지 확인하세요. 서버, 구독 주소, 규칙 파일과 시스템 VPN 권한은 서로 다른 단계의 정보이므로 파일 하나를 복사하면 모든 절차가 끝난다고 가정하지 마세요. 처음 연결할 때 시스템 확인이 다시 필요할 수 있습니다. ‘데이터 존재 여부, 항목 선택, 설정 적용, 시스템 권한, 실제 접속’ 순서로 확인하고 각 단계의 결과를 확인한 뒤 다음으로 진행하세요.

핫스팟, 네트워크 전환 및 관리 대상 기기

iPad가 다른 기기의 핫스팟을 사용할 때 iPad의 네트워크 경로와 핫스팟을 제공하는 기기 앱의 트래픽 경로가 같다고 볼 수 없습니다. 핫스팟 제공 기기의 연결 상태를 iPad 요청도 같은 경로를 이용한다는 증거로 삼지 마세요. iPad에서 현재 네트워크와 연결 결과를 따로 확인하세요. 핫스팟 신호 불안정, 제공 기기의 절전 또는 상위 네트워크 변경도 간헐적인 연결 끊김의 원인이 될 수 있습니다.

Wi-Fi와 셀룰러 데이터 사이를 전환하면 기존 연결을 다시 설정해야 할 수 있고 이름 확인 결과가 잠시 이전 상태로 남을 수도 있습니다. 네트워크 전환이 완료될 때까지 기다린 뒤 새 요청을 보내세요. 계속 실패하면 연결을 중지했다가 다시 설정하고 같은 네트워크에 안정적으로 연결된 상태의 결과와 비교하세요. 네트워크 전환 중 On Demand 조건이 반복해서 작동하거나 예상치 않게 재연결하지 않는지도 확인하세요.

학교나 조직에서 관리하는 iPad는 네트워크 정책, 인증서, 구성 프로파일과 VPN 사용 규칙의 제한을 받을 수 있습니다. 먼저 기기 관리 요구 사항을 확인하고 본인이 관리하지 않는 설정을 삭제하지 마세요. 조직 네트워크에서만 실패한다면 해당 네트워크에서 나타나는 현상을 기록해 관리자에게 확인을 요청하세요. 서버 설정, 시스템 권한과 조직 정책은 각각 따로 처리해야 하며 권한 확인 대신 인증 항목을 바꾸어서는 안 됩니다.

교차 테스트를 마치고 복구 경로 보관

교차 테스트가 필요하다면 본인 소유의 두 기기를 같은 네트워크에 연결하고 각 기기에 저장된 동일한 유효 정보를 사용해 같은 대상을 차례로 방문하세요. 대량으로 동시에 요청하지 마세요. 결과가 다르면 기기 설정을 더 확인하고, 결과가 같지만 네트워크를 바꾼 뒤 달라지면 네트워크 경로 차이일 가능성이 큽니다. 본인 서비스의 동시 접속 제한도 고려하세요. 테스트 방식 자체가 원격 제한을 유발하면 잘못된 결론을 내릴 수 있습니다.

마지막으로 평소 사용 방식으로 돌아가 앱을 사용하는 동안의 접속, 잠시 화면을 잠근 뒤 복구, 일반적인 네트워크 전환을 확인하세요. Connectivity Test가 한 번 성공한 것만으로 점검을 끝내지 마세요. 정상 작동하는 Config를 안전하게 백업하고 권한, 매개변수, 규칙 또는 네트워크 조건 중 무엇을 수정했는지 기록하세요. 나중에 문제가 다시 생기면 모든 절차를 반복하지 않고 변경된 지점부터 확인할 수 있습니다.