Shadowrocket 문제 해결

01 / VPN 설정 및 연결 상태

연결 스위치가 켜지지 않거나 바로 꺼짐

권한 요청이 승인되지 않은 경우와 연결 후 종료되는 경우를 구분하세요

Home에서 연결 스위치를 켠 뒤 시스템에서 VPN 구성 추가 요청이 표시되는지, 스위치가 권한 승인 전부터 반응하지 않는지, 아니면 잠시 연결된 다음 Not Connected로 돌아가는지 확인하세요. 두 현상은 서로 다른 단계에서 발생합니다. 전자는 시스템 권한을 확인해야 하고, 후자는 현재 구성이 시작될 수 있는지도 점검해야 합니다. 서버 목록부터 삭제하지 마세요. 발생 시각, 사용 중인 네트워크, 화면에 표시된 안내 문구 전체를 기록하면 시스템 요청을 확인하지 않은 상황을 서버 오류로 오해하지 않고, 이후에도 같은 문제를 재현하기 쉽습니다.

VPN 구성을 처음 추가할 때는 시스템 팝업에서 승인한 다음 기기 안내에 따라 인증을 완료하세요. 이전에 요청을 취소했다면 Shadowrocket으로 돌아가 다시 진행하고 앱이 여전히 전면에 표시되어 있는지 확인하세요. 이어서 시스템 Settings에서 VPN을 검색해 해당 구성이 있는지, 다른 연결이 활성화되어 있는지 살펴보세요. 메뉴 위치는 시스템 버전에 따라 다를 수 있으므로 기기에 표시된 내용을 기준으로 합니다. 관리형 기기는 조직 정책에 따라 변경이 제한될 수 있으니 먼저 기기 관리자에게 권한 범위를 확인하세요.

최소한의 변경으로 연결 환경 복구하기

먼저 현재 연결을 끄고, 같은 연결 환경을 두고 경합할 수 있는 다른 VPN이나 네트워크 필터 기능이 활성화되어 있는지 확인하세요. 한 번에 하나만 일시 중지하고 테스트가 끝나면 원래 상태로 되돌리세요. 집 Wi-Fi에서는 연결되지만 다른 네트워크에서는 안 된다면 해당 네트워크에서 웹 인증이 필요한지 확인하세요. 공용 네트워크에서 로그인 페이지 인증을 마치지 않으면 연결 요청이 계속 실패할 수 있습니다. 연결을 끊은 상태에서 네트워크 로그인을 완료한 뒤 다시 시도하세요. 로그인 페이지가 열리지 않는다는 이유만으로 구성이 손상됐다고 판단해서는 안 됩니다.

필수 항목이 모두 입력된 서버 기록이 있는지, 현재 선택한 항목이 아직 존재하는지 확인하세요. 구독을 업데이트하거나 그룹을 삭제한 뒤에는 이전에 선택한 항목이 바뀌었을 수 있습니다. 앱에서 구성 필드 오류를 명확히 표시한다면 스위치를 계속 누르지 말고 최근 수정한 파일부터 점검하세요. 새로 추가한 규칙, 재작성 또는 기타 선택 기능은 백업 상태로 잠시 되돌리고 기본 연결 조건은 유지하세요. 이렇게 하면 문제가 시작 설정에서 비롯됐는지 원격 연결에서 비롯됐는지 확인하면서 기존에 정상 작동하던 설정까지 불필요하게 바꾸는 일을 막을 수 있습니다.

시스템에 이전 Shadowrocket VPN 구성이 남아 있다면 앱 설정을 백업한 뒤 연결을 중지하고 해당 시스템 VPN 구성을 제거한 다음 앱에서 권한 요청을 다시 진행할 수 있습니다. 이 절차는 시스템의 연결 기록만 다루며 구독 내용을 복원하지 않고 로컬 데이터를 되찾아 주지도 않습니다. 앱 삭제부터 시도하지 마세요. 백업이 없으면 재설치 과정에서 기존 서버, 규칙과 문제 해결에 필요한 정보가 함께 사라져 원인을 파악하기 더 어려워질 수 있습니다.

스위치가 자동으로 바뀌면 작동 조건을 확인하세요

수동으로 끈 뒤 다시 자동 연결되거나 네트워크를 전환할 때 상태가 즉시 바뀐다면 On Demand가 활성화되어 있는지 확인하세요. On Demand는 설정된 조건에 따라 작동하므로 수동으로 스위치를 한 번 조작하는 것과 구분해야 합니다. 기준을 파악하려면 먼저 조건을 기록하고 잠시 비활성화한 뒤 수동 연결과 연결 해제를 각각 테스트하세요. 상태가 안정적이면 조건을 하나씩 다시 활성화하고, 지정된 Wi-Fi, 셀룰러 네트워크, 도메인 트리거 간에 상반된 동작이 있는지 특히 살펴보세요. 자세한 조건 설명은 On Demand 설정 안내를 참고하세요.

03 / 서버 및 프로토콜 핸드셰이크

서버 시간 초과 및 연결 재설정

테스트 결과와 실제 서비스 이용은 구분하세요

Connectivity Test 결과는 지정된 테스트 방식과 대상을 기준으로 한 한 번의 관찰입니다. 시간 초과는 서버에 연결할 수 없거나 테스트 대상이 응답하지 않는 경우, 프로토콜 핸드셰이크 실패, 현재 네트워크의 전송 영향 등 여러 원인으로 발생할 수 있습니다. 먼저 실제 테스트 방식과 대상 설정을 확인한 다음 실제 웹 요청과 비교하세요. 한 번의 테스트 실패만으로 기존 서버가 작동하지 않는다고 단정할 수 없습니다. 반대로 테스트에 수치가 표시되어도 로그인, 동영상 재생 또는 다른 작업이 정상적으로 완료된다는 뜻은 아닙니다. 두 결과가 확인하는 항목은 서로 다릅니다.

서버 주소와 포트가 사용자가 이미 보유한 유효한 정보에서 가져온 것인지 확인하고 복사할 때 공백, 줄바꿈 또는 한국어 문장 부호가 섞이지 않았는지 살펴보세요. 주소 필드에는 일반적으로 호스트 이름이나 주소 자체를 입력하며 전체 구독 링크를 잘못 붙여 넣어서는 안 됩니다. 연결 주소, TLS 서버 이름, 전송 계층의 Host도 구분해야 합니다. 일부 구성에서는 서로 다른 값을 사용할 수 있지만 서버 측에서 정한 값과 일치해야 합니다. 세 필드가 모두 같아야 한다고 생각해 하나의 값으로 통일하면 정상적인 라우팅이나 인증서 검증 조건이 깨질 수 있습니다.

프로토콜별로 관련 설정을 함께 확인하세요

설정을 확인할 때는 여러 기록의 필드를 조합하지 말고 한 개의 전체 기록을 원본 정보와 비교하세요. 전송 방식, 경로, Host, TLS는 서로 의존하는 경우가 많아 하나만 바꿔도 연결이 설정된 직후 종료될 수 있습니다. 기존 구독에서 가져온 기록이라면 직접 편집하기 전에 구독의 해당 항목부터 다시 확인하세요. VMess 등의 용어는 용어 안내에서 확인할 수 있습니다. 이 표는 문제 해결 순서만 설명하며 프로토콜 설정 전체를 나열하지는 않습니다.

인증서 관련 오류가 발생하면 기기의 날짜와 시간이 정확한지, 네트워크 인증이 완료되지 않은 상태는 아닌지, 서버 이름이 올바른지 확인하세요. 인증서 검증을 끄는 방법을 일반적인 해결책으로 사용하지 마세요. 잘못된 주소, 만료된 인증서, 이름 불일치가 가려질 수 있습니다. 기존 정보에 특정 서버 이름이 지정되어 있다면 원래 정보 출처에 정확한 값을 확인하세요. 기기 시간과 이름을 확인한 뒤에도 오류가 발생하면 오류 유형과 발생한 네트워크를 기록해 서버 관리자가 인증서 체인과 서버 수신 상태를 점검하도록 하세요.

네트워크를 비교해 원격 연결 문제 범위를 좁히세요

조건이 허용되고 예상치 못한 데이터 요금이 발생하지 않는 범위에서 같은 서버와 테스트 대상을 유지한 채 Wi-Fi와 셀룰러 네트워크를 전환해 보세요. 특정 네트워크에서만 시간 초과가 발생한다면 해당 네트워크의 이름 확인, 전송 제한 또는 경로와 관련된 문제일 가능성이 큽니다. 여러 네트워크에서 모두 실패하면 원격 서비스 상태와 인증 정보를 점검하세요. 일부 프로토콜은 UDP에 의존하므로 웹페이지가 직접 연결된다고 해서 해당 전송 방식도 반드시 사용 가능하다는 뜻은 아닙니다. 근거 없이 포트나 전송 방식을 바꾸지 마세요. 서버 측 설정과 맞아야 합니다.

사용자가 이미 이용 가능한 기록을 여러 개 보유하고 있다면 정상 작동이 확인된 다른 기록 하나로 비교할 수 있지만, 이 결과만으로 전체 서비스 품질을 평가할 수는 없습니다. 여러 항목을 연속으로 테스트하면 일시적인 혼잡과 실제 설정 오류가 뒤섞여 원인이 더 불분명해질 수 있습니다. 문제 해결 후 서버 관리자에게 프로토콜 종류, 오류가 발생한 단계, 네트워크 유형, 개인 정보가 제거된 안내 문구를 전달하세요. 공개 스크린샷에 암호, 전체 식별 정보, 구독 주소가 나타나지 않도록 하세요. 인증은 성공했지만 특정 대상만 실패한다면 인증 필드를 반복해서 입력하지 말고 규칙 및 DNS 장으로 돌아가세요.

05 / 처리량, 지연 시간 및 대상별 차이

연결은 정상인데 속도가 느림

먼저 ‘느림’을 비교할 수 있는 현상으로 구체화하세요

속도 저하는 페이지를 처음 열 때 오래 기다리는 현상, 지속적인 전송 속도 저하, 동영상의 반복 버퍼링, 간헐적인 요청 지연 등 여러 증상으로 나타날 수 있습니다. 원인이 같다고 볼 수는 없습니다. 특정 앱, 대상 도메인, 네트워크 유형, 문제가 발생한 단계를 기록하고 같은 대상을 몇 차례만 반복 테스트하세요. Connectivity Test 수치는 해당 테스트 조건에서의 결과이며 실제 서비스 전송 속도와 같지 않습니다. 테스트 응답이 빠른 기록도 대상 서비스로 이어지는 경로가 혼잡할 수 있으므로 단일 테스트 결과만으로 평소에 사용할 서버를 결정하지 마세요.

연결을 끊고 기본 네트워크가 안정적인지 확인하세요. Wi-Fi 신호, 라우터 부하, 다른 기기에서 대량 전송이 진행 중인지 살펴보세요. 셀룰러 네트워크는 신호와 위치, 네트워크 전환의 영향도 받습니다. 테스트 중에는 기기 위치와 네트워크를 유지하고 대역폭을 많이 사용하는 동기화 작업은 일시 중지하세요. 기본 네트워크 자체가 불안정하다면 먼저 환경을 안정시킨 뒤 프록시 경로를 평가하세요. 그렇지 않으면 테스트 결과 차이가 방금 변경한 설정이 아니라 무선 환경 변화에서 비롯될 수 있습니다.

이름 확인 지연과 지속적인 전송 문제를 구분하세요

특정 도메인을 처음 열 때만 느리고 페이지가 로드된 뒤에는 계속 전송된다면 DNS와 연결 설정 단계를 우선 확인하세요. 모든 페이지에서 텍스트는 빠르게 표시되지만 이미지와 동영상 전송이 계속 느리다면 대상 경로, 원격 서버 부하, 실제 라우팅 결과를 살펴볼 필요가 있습니다. 여러 유형의 페이지를 비교할 때는 페이지마다 콘텐츠 크기가 다르다는 점을 고려하세요. 가벼운 페이지 하나가 빨리 열린다고 해서 모든 문제가 해결된 것은 아닙니다. 브라우저 캐시도 체감 속도에 영향을 주므로 재테스트 시 처음 요청인지 캐시된 콘텐츠인지 기록하세요.

Config에서 느린 요청이 예상한 정책을 사용하는지 확인하세요. 한 페이지가 여러 도메인에 동시에 요청을 보내는 경우 메인 사이트는 PROXY를 사용하고 리소스 도메인은 DIRECT를 사용하면 본문은 표시되지만 이미지가 계속 로딩되는 상황이 생길 수 있습니다. 실제 요청 기록에서 실패한 리소스 도메인을 찾아 필요한 규칙을 추가할지 판단하세요. 편의를 위해 DOMAIN-KEYWORD 적용 범위를 넓히지 마세요. 규칙 범위가 너무 넓으면 관련 없는 대상에도 영향을 주고 트래픽이 우회하는 경로가 늘어날 수 있습니다. 특정 웹사이트 규칙 작성법은 DOMAIN-SUFFIX 및 FINAL 예시를 참고하세요.

Proxy와 Config 모두 느리다면 테스트 대상을 동일하게 유지하고 같은 네트워크에서 사용자가 이미 보유한 다른 유효한 기록을 비교하세요. 이 결과는 이번 경로 간 차이를 보여줄 뿐 장기적인 품질을 직접 판단할 근거는 아닙니다. 서버 부하, 대상 서비스의 속도 제한, 네트워크 간 경로는 시간에 따라 바뀔 수 있습니다. 대용량 테스트를 계속 실행하면 데이터가 추가로 소모되고 다른 요청에도 영향을 줄 수 있으므로 필요한 정보를 얻을 수 있는 적은 횟수로 테스트하세요. 지속적으로 측정하려면 먼저 데이터 사용 조건을 확인해 문제 해결 과정 자체가 대역폭을 더 많이 사용하지 않도록 하세요.

근거 없이 매개변수를 무작위로 변경하지 마세요

연결이 오래 멈추거나 큰 콘텐츠 일부만 실패하고 작은 요청은 정상이라면 경로와 전송 조건을 추가로 살펴볼 수 있습니다. 하지만 MTU, 동시 연결 수, 프로토콜 매개변수를 무작정 바꾸는 것은 피하세요. 이러한 값에는 네트워크와 서버 측 제약이 있으며 높이거나 낮춰도 부작용이 생길 수 있습니다. 먼저 기본값이나 정상 작동이 확인된 값을 유지하고 특정 네트워크에서만 문제가 발생하는지 기록하세요. 명확한 오류 근거가 있거나 관리자가 해당 환경에 적합한 값을 제공한 경우에만 한 항목씩 비교하고 원래 값으로 바로 복구할 수 있도록 보관하세요. 관련 없는 상황의 설정을 그대로 따라 하지 마세요.

기기 과열, 배터리 부족 모드, 백그라운드 동기화, 대상 앱의 자체 디코딩 문제도 네트워크가 느린 듯한 페이지 지연을 일으킬 수 있습니다. 다른 앱에서 비슷한 유형의 콘텐츠를 열어 네트워크 대기와 화면 조작 지연을 비교하세요. 특정 대상만 계속 느리고 다른 대상은 정상이라면 대상 서비스 상태도 고려해야 합니다. 문제를 해결한 뒤에는 자주 사용하는 페이지, 지속적인 전송, 네트워크 전환을 확인해 캐시로 잠시 빨라진 것이 아닌지 살펴보고 평소 설정과 백그라운드 작업을 복원하세요.

07 / 활동 시간 및 반복 연결

배터리 소모 증가 및 기기 과열

비교 조건이 동일한지 먼저 확인하세요

시스템 배터리 화면에 표시되는 앱 사용 비율은 선택한 기간의 통계이며 모든 상황에 적용되는 고정 소비량이 아닙니다. 사용 시간, 화면이 켜져 있던 시간, 네트워크 환경, 다른 앱의 활동에 따라 비율이 달라집니다. 사용 강도와 네트워크가 비슷한 시간대를 비교하면서 데이터 전송량이 많았는지, 연결이 반복됐는지, 기기가 계속 과열됐는지 살펴보세요. 비율이 올라갔다는 이유만으로 이상이 있다고 단정할 수 없습니다. 다른 앱의 사용량이 줄어도 같은 활동의 전체 사용량 대비 비율은 높아질 수 있습니다.

배터리 소모가 특정 구성 변경, 구독 업데이트, 네트워크 전환, 앱 업데이트 중 언제부터 시작됐는지 기록하고 화면이 켜진 상태와 대기 상태를 구분하세요. 대기 중에도 네트워크 활동이 계속된다면 사진 동기화, 파일 전송, 동영상 재생 등의 작업이 연결을 사용 중인지 먼저 확인하세요. 앱이 다른 앱의 데이터를 처리하면 작업량이 발생하지만 실제 트래픽은 백그라운드 작업에서 비롯될 수 있습니다. 점검할 때는 명확한 대용량 작업을 먼저 중지한 다음 연결이 안정적인지 확인하세요. 통계 항목 이름 하나만으로 배터리 소모의 전체 원인을 판단하지 마세요.

On Demand 및 네트워크 전환 반복을 확인하세요

Wi-Fi 신호가 약해 셀룰러 네트워크와 반복해서 전환되면 핸드셰이크와 연결 복구가 반복될 수 있습니다. 두 네트워크에서 On Demand 규칙이 서로 다른 동작을 하도록 설정되어 있다면 전환할 때 상태가 더 자주 바뀔 수도 있습니다. 신호가 안정적인 장소에서 한 네트워크만 유지해 비교하고 자동 실행 조건을 기록한 뒤 잠시 비활성화해 대기 중 활동이 눈에 띄게 달라지는지 확인하세요. 테스트가 끝나면 필요한 규칙을 복원하세요. 배터리 사용을 줄이려는 목적으로 의존하는 연결 조건을 영구히 제거하지 말고 반복 실행을 일으키는 네트워크나 규칙 조합부터 찾으세요.

서버 인증이 계속 실패하거나 원격 연결이 반복해서 종료되면 기기가 연결을 계속 복구하려고 시도할 수 있습니다. 배터리 상태를 평가하기 전에 서버 시간 초과 장의 절차에 따라 오류를 먼저 해결하세요. 화면을 잠그는 것만으로 잘못된 인증 설정이 저절로 복구되지는 않습니다. 기록에서 같은 오류가 짧은 시간 안에 반복되는지, 네트워크 전환 후에만 나타나는지 확인하세요. 한 번의 배터리 변화보다 규칙적인 재시도 패턴이 더 유용한 단서입니다. 필요하면 현재 연결을 중지해 성공 가능성이 없는 상태에서 계속 재시도하지 않도록 하고 개인 정보가 제거된 기록을 일정 시간 보관하세요.

문제 해결 과정에서 발생하는 추가 활동 줄이기

Connectivity Test를 대량으로 실행하거나 구독을 자주 자동 업데이트하고 상세 기록을 계속 남기면 문제 해결 중 네트워크 사용과 처리 작업이 증가할 수 있습니다. 원인을 찾는 데 필요한 수준의 진단 기능만 사용하고 단서를 얻은 뒤에는 평소 설정으로 되돌리세요. 배터리 소모를 관찰하려고 여러 테스트를 동시에 반복 실행하거나 많은 대상 페이지를 계속 새로 고치지 마세요. 임시 작업을 중지한 뒤 문제가 해결되면 안정적으로 작동하던 프로토콜 설정부터 바꾸지 말고 테스트 빈도를 먼저 조정하세요. 진단 부하와 일상적인 연결 부하는 따로 평가해야 합니다.

기기 과열은 성능에도 영향을 주어 웹페이지가 느리게 보이게 할 수 있습니다. 대용량 작업을 중지하고 기기가 정상 온도로 돌아온 뒤 비교 테스트를 진행하세요. 충전 여부, 화면 밝기, 주변 온도도 결과에 영향을 주므로 가능한 한 조건을 동일하게 맞추세요. 기기 외부의 온도만으로 특정 부품이 고장 났다고 판단하지 마세요. 연결을 끊은 뒤에도 이상이 계속되면 시스템 배터리 화면에서 다른 활동을 확인하고 기기 시스템의 안내에 따라 조치하세요. 모든 배터리 문제를 네트워크 설정 하나의 탓으로 돌리면 안 됩니다.

복구 여부를 확인하려면 정상적인 사용 환경에서 한 번 사용하고 비슷한 조건으로 일정 시간 대기 상태를 관찰하세요. 성공 기준은 특정 비율 이하로 배터리 사용량이 떨어지는 것이 아니라, 반복 재연결이 멈추고 백그라운드 작업이 예상대로 작동하며 비슷한 사용 환경에서 과열이 다시 발생하지 않는 것입니다. 문의할 때는 통계 시간 범위, 네트워크 유형, On Demand 활성화 여부, 대량 테스트 실행 여부를 알려주세요. 방문 도메인, 서버 정보, 개인 활동이 포함될 수 있는 전체 트래픽 기록은 공개하지 마세요. 문제 발생 시각 전후의 필요한 부분만 따로 보관할 수 있습니다.

09 / iPad 네트워크 및 멀티태스킹

iPad 연결 및 복구 문제

구매 복원과 설정 이전을 구분하세요

iPad에서 다시 사용하려면 먼저 App Store에 해당 구매 기록이 있는 계정으로 로그인했는지 확인한 다음 iPad 구매 안내에 따라 진행하세요. 시스템 요구 사항과 구매 호환성은 App Store 페이지에 표시된 내용을 기준으로 합니다. 앱을 다시 받을 수 있다고 해서 이전 기기의 서버와 Config가 새 기기에 자동으로 나타나는 것은 아닙니다. 구매 기록과 사용자 설정은 별개입니다. 처음 실행한 뒤 바로 스위치를 켜고 연결 실패만으로 복원 과정의 오류를 판단하지 말고 기존 구독, 서버 정보, 파일이 모두 있는지 하나씩 확인하세요.

다른 기기에서 설정을 이전할 때는 직접 보관한 유효한 백업이나 기존 정보를 사용해 다시 가져오고 선택한 서버, Global Routing, 현재 Config를 확인하세요. 그룹 이름이 같다고 내용까지 완전히 같지는 않습니다. 특히 주소, 인증 매개변수, 규칙 끝의 FINAL을 살펴보세요. 서버 목록만 가져오고 해당 규칙 파일을 가져오지 않았다면 Config에서의 동작이 이전 기기와 달라질 수 있습니다. 먼저 시작하기 안내에 따라 기본 연결을 만든 뒤 복잡한 규칙을 복원하세요. 선택 기능을 한꺼번에 모두 이전하는 것보다 빠진 항목을 찾기 쉽습니다.

여러 창을 사용해도 연결 환경이 분리되지는 않습니다

iPad의 분할 화면과 여러 창 기능을 사용하면 매뉴얼과 앱을 함께 볼 수 있지만 시스템 네트워크 연결 상태는 하나의 환경으로 이해해야 합니다. 창을 전환하거나 크기를 조정하고 홈 화면으로 돌아가도 별도의 VPN 세션이 새로 만들어지는 것은 아닙니다. 진단할 때는 브라우저 창 하나와 테스트 대상 하나를 정해 캐시된 페이지를 다른 창에서 보고 혼동하지 않도록 하세요. 한 창에서는 정상이고 다른 창에서는 실패한다면 창 차이만으로 라우팅 규칙이 잘못됐다고 판단하지 말고 도메인, 로그인 상태, 실제 새로고침 여부를 비교한 뒤 요청 기록을 확인하세요.

일부 iPad는 Wi-Fi만 지원하고 다른 모델은 셀룰러 네트워크도 지원합니다. 셀룰러 기능이 없는 기기는 본인이 사용할 권한이 있는 다른 무선 네트워크에서 비교할 수 있지만 개인용 핫스팟을 이용하면 상위 네트워크 자체가 달라질 수 있습니다. 서버와 테스트 대상은 그대로 유지하고 접속 방식을 기록하세요. 공용 무선 네트워크에서는 인증 페이지를 먼저 완료해야 합니다. 화면을 잠근 뒤 다시 열었을 때 접속할 수 없다면 시스템 VPN 구성을 바로 삭제하지 말고 무선 네트워크 연결이 유지되는지 먼저 확인한 다음 VPN 상태를 점검하세요.

화면 잠금, 백그라운드 작업 및 관리형 기기

화면을 잠근 뒤 다운로드가 멈추더라도 반드시 연결 오류라고 볼 수는 없습니다. 대상 앱의 백그라운드 실행 정책이 작업 지속 여부에 영향을 줍니다. 먼저 기기를 잠금 해제하고 브라우저에서 새로운 간단한 요청을 보내 연결이 가능한지 확인하세요. 새 요청은 성공하지만 기존 작업이 재개되지 않는다면 원래 앱의 작업 상태를 확인하세요. 새 요청이 모두 실패하면 On Demand, 네트워크 전환, 서버 재연결 기록을 살펴보세요. 파일 작업 하나가 멈췄다고 시스템 전체가 오프라인이라고 판단하거나 화면을 계속 켜 두어 근본 원인을 가리지 마세요.

학교, 기업 또는 다른 조직에서 관리하는 iPad는 VPN 구성, 인증서, 네트워크 필터, 변경 권한이 제한될 수 있습니다. 시스템에 관리 상태가 표시되는지 확인하고 허용된 사용 방법을 관리자에게 문의하세요. 필요한 업무나 기기 권한과 연결되어 있을 수 있으므로 이해하지 못하는 관리 구성이나 인증서를 시험 삼아 제거하지 마세요. 개인 기기도 기존 시스템 구성을 먼저 기록하고 영향 범위를 확인한 뒤 변경하세요. VPN을 추가할 수 없는 문제는 권한 확인 장에서 다뤄야 하며 서버 인증 매개변수를 바꿔 해결할 수 없습니다.

iPad와 다른 기기가 같은 Wi-Fi에서 다르게 작동하더라도 무선 네트워크가 같다는 이유로 기기 자체의 차이를 배제해서는 안 됩니다. 각 기기의 시스템 시간, DNS, 현재 Config, 서버 선택을 하나씩 비교하세요. 브라우저의 개인정보 보호 설정, 저장된 네트워크 조건, 대상 앱의 권한도 요청 경로나 결과를 바꿀 수 있습니다. 같은 대상에 같은 방식으로 접속해 비교하고 앱의 실제 요청 기록에서 차이를 우선 확인하세요. 서로 다른 앱의 첫 화면만 비교해서는 신뢰할 만한 네트워크 결론을 내리기 어렵습니다.