Shadowrocket
Settings 설정 가이드

Shadowrocket의 실제 동작은 Settings의 특정 스위치 하나만으로 결정되지 않습니다. 시스템 네트워크 권한, 현재 선택된 서버, Global Routing, 사용 중인 Config, 서버 자체의 프로토콜 매개변수가 모두 영향을 줍니다. 설정을 바꿨는데도 달라진 점이 없다면 옵션을 계속 추가하기보다 먼저 어느 단계의 동작을 확인하고 있는지 살펴보세요. 이 매뉴얼은 사용자에게 자체 구독이나 서버 정보가 있다는 전제에서 작성되었습니다. 구독 링크는 서비스 제공업체에서 받아야 하며, 가져온 뒤에는 현재 서버와 Config가 올바른지 확인해야 합니다.

초기 상태가 모든 기기의 기본값을 뜻하지는 않습니다

‘기본값’은 세 가지 출처를 구분해야 합니다. 새로 설치했을 때 앱이 설정한 초기 상태, 가져온 Config에 명시된 값, 기기 백업이나 동기화에서 복원된 이전 값입니다. 이 값들은 서로 다를 수 있습니다. 앱 업데이트에 따라 화면도 바뀔 수 있으므로, 확인되지 않은 포트 번호나 테스트 주소, 제한 시간을 고정된 출고값처럼 안내하지 않습니다. 설정을 확인할 때는 현재 화면에 표시된 내용과 현재 Config를 함께 기록하세요. 화면에 표시되지 않는 값은 다른 사람의 스크린샷만 보고 추측하지 마세요.

설정을 조정하기 전에 현재 Config 사본을 보관하고 Global Routing, 선택된 서버, 네트워크 유형, 해결하려는 문제를 기록하세요. 기록에는 ‘현재 Wi-Fi에서 같은 도메인을 처음 열 때 실패한다’처럼 재현할 수 있는 현상을 적고, 단순히 ‘네트워크가 느리다’고만 쓰지 마세요. 그런 다음 서버, 네트워크와 접속 대상을 그대로 둔 채 관련 옵션 하나만 변경하세요. 결과가 나빠져도 명확한 시작 상태로 되돌릴 수 있어 기존 스위치 상태를 하나씩 기억해 낼 필요가 없습니다.

세 가지 모드에 따라 규칙 적용 여부가 달라집니다

Global Routing의 Config 모드는 현재 Config에 따라 요청을 처리합니다. Proxy 모드는 프록시 경로를 우선적으로 사용하고, Direct 모드는 직접 연결을 우선합니다. 세 모드는 문제를 진단할 때 비교 기준으로 유용하지만 네트워크에 반드시 연결된다는 보장은 아닙니다. 시스템에서 제외되는 트래픽, 앱 내부의 별도 처리 방식, 서버 가용성도 영향을 줍니다. 특히 Proxy 모드에서 규칙 변경을 시험한 결과만으로 Config의 규칙 순서가 올바른지 판단할 수는 없습니다.

일상적인 사용에서는 무조건 Proxy로 전환하기보다 현재 규칙을 이해한 상태에서 Config를 사용하는 것이 좋습니다. 문제를 확인하는 동안에는 모드를 잠시 바꿔 테스트한 뒤 원래 선택으로 되돌리세요. 전환 후에도 기존의 장시간 연결은 바로 재설정되지 않을 수 있으므로 대상 요청을 새로 보내세요. 필요하다면 적절한 시점에 연결을 끊었다가 다시 연결하세요. 음성 통화, 파일 업로드 등 중단할 수 없는 작업 중에는 모드를 반복해서 바꾸지 마세요. 테스트로 인한 중단을 서비스 장애로 오해할 수 있습니다.

규칙 파일도 별도의 입력으로 확인하기

아래 예시는 처리 순서를 설명하기 위한 것으로, 그대로 사용할 수 있는 완전한 Config가 아니며 서버를 생성하지도 않습니다. PROXY, DIRECT, REJECT는 규칙 정책이며 화면의 Proxy, Direct 모드와 혼동하지 마세요. 예시 도메인은 설명을 위한 것입니다. 규칙은 위에서 아래로 적용되며 FINAL은 마지막 기본 처리 규칙으로 두어야 합니다. 앞쪽에 배치하면 뒤의 규칙이 요청을 처리하지 못할 수 있습니다. 수정 전에는 현재 활성화된 파일을 편집하는지 확인하고, 이름이 같은 백업 파일과 혼동하지 마세요.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,ads.example.net,REJECT
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY

‘예상 동작’과 ‘실제 기록’을 나란히 확인하세요. 특정 도메인이 PROXY를 사용해야 한다면 홈 화면의 연결 스위치만 볼 것이 아니라 요청 기록에서 대상 도메인, 적용된 규칙과 최종 정책을 확인해야 합니다. 규칙이 DNS 조회 후 얻은 주소와 관련된다면 DNS 항목을 살펴보세요. 구매와 설치에 관한 내용은 정품 확인 안내를 참고하세요. 앱의 일회성 구매와 회선 요금제는 별개입니다. 어떤 설정을 조정해도 서비스 제공업체가 제공하는 유효한 연결 정보를 대신할 수는 없습니다.

DNS는 도메인 이름을 연결에 필요한 주소로 변환합니다. 조회에 성공했다고 대상 서비스에 연결할 수 있는 것은 아니며, 조회에 실패했다고 반드시 서버 장애인 것도 아닙니다. 일반적인 접속 과정에는 도메인 조회, 규칙 판단, 연결 수립, 앱 수준의 통신이 포함되며 어느 단계에서든 실패할 수 있습니다. DNS를 확인할 때는 대상 도메인 전체를 기록하고, 브라우저의 페이지 오류와 Shadowrocket 기록의 DNS 오류를 구분하세요. 인증서 문제, 대상의 연결 거부, 응답 시간 초과를 모두 DNS 문제로 묶어 부르지 마세요.

DNS 값의 출처

앱 화면의 DNS 관련 설정과 Config의 DNS 설정을 함께 살펴봐야 합니다. 파일에 DNS 조회 출처가 명시되어 있다면 시스템 Wi-Fi 설정에서 DNS만 바꿔도 현재 터널 안의 조회 방식은 달라지지 않을 수 있습니다. 반대로 Config에 특정 옵션이 없다고 해서 앱이 특정 공용 DNS를 사용한다고 단정할 수도 없습니다. 먼저 현재 파일에 관련 항목이 있는지 확인한 다음 Settings에 표시된 값을 기록하세요. 테스트를 되돌릴 때는 어느 단계의 설정을 취소하는지도 확인해야 합니다.

시스템 DNS를 조회 출처로 사용하면 기기와 현재 네트워크의 동작을 비교하기 쉬워 문제 해결의 출발점으로 적합한 경우가 많습니다. 다만 모든 네트워크에서 성능이 더 좋다는 뜻은 아닙니다. 기업, 학교 또는 가정 네트워크의 내부 도메인은 해당 네트워크의 DNS에서만 조회될 수 있습니다. 조회 출처를 외부 주소로 일괄 변경하면 내부 도메인이 작동하지 않을 수 있습니다. 서비스 제공업체에서 받은 Config가 있다면 DNS 설정의 의도를 먼저 파악하고 덮어쓸지 결정하세요. 역할이 불분명한 여러 설정을 함께 사용하지 마세요.

아래 예시는 Config에서 시스템 DNS를 조회 출처로 지정하는 구문만 보여 줍니다. 파일의 나머지 내용을 삭제해도 된다는 뜻이 아니며, 모든 요청에 적용된다는 보장도 없습니다. 편집 전 기존 파일을 보관하고 같은 섹션에 동일한 키가 있는지 확인해 중복 항목으로 혼란이 생기지 않도록 하세요. 현재 화면이나 파일 설명에서 확인되지 않은 고급 매개변수는 비슷한 이름만 보고 임의로 추가하지 말고 그대로 두는 것이 좋습니다.

[General]
dns-server = system

IPv4, IPv6와 도메인 규칙

같은 도메인에서 IPv4 주소나 IPv6 주소가 반환될 수 있습니다. 기기에 IPv6 주소가 할당되어 있어도 프록시 서버, 대상 사이트와 현재 네트워크 사이의 전체 경로가 같은 방식의 연결을 지원한다는 뜻은 아닙니다. 특정 네트워크에서만 대상에 연결할 수 없다면 조회 결과의 주소 유형과 이후 연결 오류를 비교한 뒤 관련 옵션을 조정하세요. IPv6를 끄는 것을 일반적인 최적화 방법으로 여기지 마세요. 다른 접속 경로에도 영향을 주며 실제 라우팅이나 서버 매개변수 문제를 가릴 수 있습니다.

DOMAIN, DOMAIN-SUFFIX 같은 규칙은 도메인을 기준으로 작동하고, IP-CIDR, GEOIP 등의 규칙은 주소를 판단합니다. 조회 결과가 달라지면 주소에 의존하는 규칙의 적용 결과도 달라질 수 있습니다. 따라서 ‘같은 웹사이트에 다른 정책이 적용됐다’면 도메인, 조회 주소와 규칙 순서를 함께 확인해야 합니다. Config에서 특정 조회 또는 매핑 방식을 사용하는 경우 기록에 나타난 주소도 그 방식에 따라 해석해야 합니다. 주소 하나의 형태만 보고 요청이 특정 경로로 전송됐다고 단정하지 마세요.

캐시와 재현 가능한 확인

DNS를 변경한 직후 페이지를 새로고침해도 이전 결과가 사용될 수 있습니다. 시스템, 앱과 웹페이지 자체가 캐시나 기존 연결을 보관할 수 있기 때문입니다. 먼저 대상 요청을 새로 보내고 새로운 조회 기록이 나타나는지 확인하세요. 필요하면 연결을 새로 설정하고 대상 앱을 다시 여세요. 캐시를 지우려고 여러 스위치를 연달아 바꾸지 마세요. 문제가 잠시 사라져도 조회 출처, 연결 재설정, 대상 캐시 중 무엇이 원인이었는지 알 수 없습니다.

문제 해결 순서는 다음과 같이 정할 수 있습니다. 같은 대상에 다시 요청하기, DNS 오류 확인하기, 현재 네트워크와 연결이 확인된 다른 네트워크 비교하기, Config의 DNS 항목 확인하기, 조회 출처 하나만 조정하기, 연결을 다시 설정한 뒤 재시험하기. 각 단계의 결과를 기록하세요. 내부 도메인만 작동하지 않으면 로컬 DNS 요구 사항을 먼저 확인하세요. 모든 도메인에 연결할 수 없다면 현재 네트워크에서 로그인이나 인증을 완료했는지 확인해야 합니다. 네트워크 자체를 사용할 수 없는 상태에서는 DNS를 바꾸어도 유효한 비교 조건을 만들기 어렵습니다.

암호화된 DNS 방식을 사용할 때는 DNS 서비스 주소를 어떻게 찾는지, 현재 정책에서 연결이 가능한지, 인증서 검증이 성공하는지도 함께 살펴봐야 합니다. DNS 주소가 여러 개라고 해서 조회 속도가 반드시 빨라지거나 결과가 완전히 같아지는 것은 아닙니다. 적절한 설정은 현재 네트워크에서 안정적이고, 경로를 설명할 수 있으며, 되돌릴 수 있어야 합니다. 확인이 끝나면 필요한 변경만 남기고 이유를 메모하세요. 다음 네트워크로 바뀌었을 때 해당 설정이 여전히 적합한지 판단하기 쉽습니다.

On Demand는 시스템이 인식할 수 있는 조건에 따라 연결을 자동으로 시도하는 기능입니다. 연결을 언제 시도할지에 영향을 주지만, 도메인에 최종적으로 어떤 정책이 적용되는지를 결정하거나 앱을 항상 전면에 표시하지는 않습니다. 이 점을 이해하는 것이 중요합니다. On Demand가 작동한 것처럼 보여도 대상에 연결할 수 없다면 서버, DNS 또는 규칙 문제일 수 있습니다. 반대로 수동 연결은 되지만 네트워크를 바꾼 뒤 자동 연결되지 않는다면 조건 일치나 시스템 설정을 확인해야 합니다.

수동 연결을 기준으로 확인한 뒤 조건 추가하기

먼저 자동 동작을 끄고 수동 연결이 안정적으로 되는지 확인하세요. 시스템 안내에 따라 VPN 설정 추가를 허용했는지, 현재 서버가 유효한지, 대상 요청에 예상한 정책이 적용되는지 확인한 다음 On Demand를 활성화하세요. 그렇지 않으면 수동 연결과 자동 연결에 모두 문제가 있어 오류가 트리거 단계에서 발생했는지 연결 단계에서 발생했는지 판단하기 어렵습니다. 첫 설정의 구체적인 위치와 사용 가능한 조건은 현재 앱 화면을 기준으로 확인하세요. 이전 화면의 옵션 이름이 모든 기기에 있다고 가정하지 마세요.

기본 상태는 해당 기기의 현재 화면에서 확인해야 합니다. 시스템 백업을 복원했거나 VPN 설정을 이미 사용한 기기라면 특히 그렇습니다. 앱을 다시 열었더라도 시스템에 저장된 On Demand 동작이 새로 설치했을 때와 같다고 볼 수 없습니다. 수정 전에 On Demand의 활성화 여부, 기존 조건의 순서와 해당 네트워크를 기록하세요. 일시적으로 문제를 확인하려는 경우 조건을 남겨 두고 관련 자동 동작을 잠시 중지할 수 있습니다. 나중에 업무용 네트워크 규칙을 복구하는 데 필요한 정보까지 잃지 않도록 모든 설정을 바로 삭제하지 마세요.

현재 화면에서 Wi-Fi, 셀룰러 네트워크 또는 특정 네트워크 이름에 따라 조건을 나눌 수 있다면 검증하기 쉬운 조건 하나부터 시작하세요. 예외를 한꺼번에 많이 추가하지 마세요. 네트워크 이름은 실제 화면과 대조해 철자, 공백과 대소문자를 확인해야 합니다. 이름이 같아도 네트워크 환경은 다를 수 있습니다. 네트워크 이름은 조건 입력값일 뿐, 네트워크가 신뢰할 수 있다는 증거가 아닙니다. 조직 내부 리소스에 연결할 때는 해당 네트워크의 접속 규정을 따르고 자동 조건으로 필요한 접근 관리를 대신하지 마세요.

자동 재연결과 수동 연결 해제의 차이

사용자가 연결을 수동으로 끈 뒤에도 On Demand 조건이 충족되면 새 네트워크 요청이 발생할 때 시스템이 다시 연결을 시도할 수 있습니다. 이때 연결 스위치를 계속 누르기보다 On Demand를 일시 중지해야 하는지 먼저 확인하세요. 잠시 연결을 끊어 두려면 자동 트리거 조건을 명확히 종료하고 시스템의 VPN 상태를 확인해야 합니다. 테스트가 끝나면 원래 설정으로 복구하세요. 자동 연결을 다시 켜지 않은 채 앱의 자동 연결 기능이 사라졌다고 오해하지 않도록 주의해야 합니다. 이 동작은 서버 연결 실패 후 재시도하는 경우와 별도로 기록하세요.

네트워크 전환은 한순간에 끝나지 않습니다. 기기가 Wi-Fi에서 벗어난 다음 셀룰러 네트워크에 연결되고, 이어서 새 DNS 조회와 연결이 처리될 수 있습니다. 기존의 장시간 연결은 끊길 수 있고 새 요청은 새로운 네트워크 경로를 사용합니다. 따라서 자동 연결은 전환 중 아이콘이 깜박이는지만 볼 것이 아니라 전환 후 요청을 다시 보낼 수 있는지 확인해야 합니다. 충분한 연결 시간을 주고 몇 초 사이에 네트워크를 반복해서 바꾸지 마세요. 잦은 전환은 변수를 늘리고 로그에서 서로 연관된 오류를 구분하기 어렵게 합니다.

네트워크 상황별 테스트 구성하기

다음 세 가지 상황을 각각 확인하는 것이 좋습니다. 현재 네트워크에서 수동으로 연결하기, 다른 네트워크로 전환한 뒤 자동 연결하기, 자동 동작을 잠시 중지하고 수동으로 연결 끊기. 매번 트리거 조건, 시스템 상태와 실제 요청 결과를 기록하세요. 특정 Wi-Fi에서만 실패한다면 로그인 페이지를 먼저 열어야 하는 네트워크인지 확인하세요. 인증이 끝나지 않으면 자동 연결이 네트워크 인증 절차와 충돌할 수 있습니다. 먼저 네트워크 접속을 완료한 다음 다시 테스트하고 프로토콜 매개변수는 섣불리 바꾸지 마세요.

기기가 조직에서 관리되는 경우 시스템에 다른 네트워크 정책이나 설정 제한이 있을 수 있습니다. 앱의 조건에 문제가 있는지 판단하기 전에 시스템 설정에서 실제로 적용된 VPN 구성과 관리 요구 사항을 확인하세요. 시스템 설정을 반복해서 삭제하며 시험하지 마세요. 권한, On Demand 조건과 기존 설정까지 함께 지워질 수 있습니다. 먼저 자동 동작을 일시 중지하고 기록을 보존한 채 수동 연결 경로만 확인하세요. 설정이 실제로 유효하지 않다고 확인된 경우에만 시스템 절차에 따라 다시 권한을 부여하세요.

일상적인 설정은 사용 방식에 따라 달라집니다. 연결 시간을 직접 관리해야 한다면 수동 방식이 이해하기 쉽고, 네트워크 조건에 따라 자동 연결하려면 On Demand를 항목별로 활성화하세요. ‘항상 연결’ 상태만을 위해 설명할 수 없는 조건을 여러 개 겹치지 마세요. 설정을 마친 뒤 화면을 잠갔다가 다시 켜고 네트워크를 한 번 전환한 다음 대상에 새로 요청해 전체 연결 주기가 예상대로 작동하는지 확인하세요. 최초 권한 부여와 연결 순서를 다시 확인하려면 빠른 시작 가이드에서 기본 절차를 참고하세요.

Ping, 연결 테스트와 실제 페이지 로딩은 서로 다른 작업입니다. 테스트 방식에 따라 서버 주소의 응답, 포트 연결 또는 지정한 경로를 통한 테스트 대상 접속을 확인할 수 있습니다. 구체적인 측정 범위는 현재 선택된 테스트 방식에 따라 달라집니다. 응답 시간이 짧다고 대상 웹사이트가 반드시 빠르게 열린다는 뜻은 아니며, 시간 초과만으로 서버 전체가 사용할 수 없다고 단정할 수도 없습니다. 결과를 비교하기 전에 테스트 유형, 대상과 당시 네트워크 조건을 확인해 같은 방식끼리 비교하세요.

테스트 방식과 측정 범위

테스트가 기본 네트워크 응답만 확인한다면 앱 프로토콜의 인증과 이후 전송 과정을 모두 검증하지 못할 수 있습니다. 포트 연결에 성공해도 암호, TLS, SNI 등의 매개변수가 올바르다는 뜻은 아닙니다. 전체 프록시 경로를 통해 대상을 확인하는 테스트는 더 많은 단계를 검사하지만 테스트 사이트 자체의 상태에도 영향을 받습니다. 먼저 기본 테스트로 주소나 포트에 연결할 수 있는지 확인한 다음 실제 요청으로 전체 경로를 검증하세요. 첫 번째 테스트 통과만으로 ‘모든 설정이 정상’이라고 판단하지 마세요.

테스트 대상과 시간 초과 옵션의 초기값은 현재 화면을 기준으로 확인하세요. 기존 Config나 이전 설정에 오래된 값이 남아 있을 수 있으므로 기기마다 결과를 숫자만으로 비교해서는 안 됩니다. 먼저 앱에서 현재 사용할 수 있는 초기 설정을 기준으로 삼으세요. 테스트 대상을 바꿔야 한다면 용도를 설명할 수 있고 현재 환경에서 접속 가능한 대상을 선택하세요. 측정 방식의 변화와 서버 성능 변화를 혼동하지 않도록 대상이나 시간 초과 중 한 번에 하나만 변경하세요.

테스트 대상은 가능한 한 안정적이고 응답이 단순하며 확인 목적에 맞아야 합니다. 로그인, 리디렉션, 요청 빈도 제한이 필요하거나 네트워크에 따라 다른 내용을 반환하는 대상은 결과에 추가 영향을 줄 수 있습니다. 서버를 많이 선택해 짧은 시간에 반복 테스트하지 마세요. 일시적인 대기나 제한을 지속적인 장애로 오해할 수 있습니다. 이미 구독을 사용 중이라면 실제로 사용하는 소수의 항목만 비교하면 충분합니다. 목록의 모든 항목에 비슷한 숫자가 표시되도록 할 필요는 없습니다.

시간 제한을 짧게 한다고 정확도가 높아지는 것은 아닙니다

대기 시간이 너무 짧으면 첫 DNS 조회, 연결 수립과 암호화 통신이 끝나기 전에 테스트가 시간 초과로 처리될 수 있습니다. 너무 길면 문제를 확인하기까지 기다리는 시간이 늘어납니다. 현재 값을 유지한 채 소수의 테스트를 반복해 결과가 안정적인지 먼저 살펴보세요. 실제 사용 요구에 따라 조정할 수 있습니다. 시간 제한을 계속 늘려도 대기 시간만 길어질 뿐 주소 오류나 인증 실패는 해결되지 않습니다. 몇 차례의 결과가 크게 다르면 가장 낮은 값을 바로 선택하기보다 네트워크 부하와 전환 여부를 확인하세요.

지연 시간은 특정 통신에 걸린 시간을 주로 나타내며, 실제 사용감에는 처리량, 패킷 손실, 혼잡도와 대상 서버 응답도 영향을 줍니다. 작은 페이지는 열리는데 큰 파일은 전송이 중단되거나, 문자 메시지는 정상인데 음성·영상이 불안정하다면 실제 작업에 가까운 방식으로 확인해야 합니다. 같은 기기, 네트워크, 비슷한 시간대와 테스트 대상을 사용해 비교한 뒤 실제 작업으로 다시 확인하세요. 다른 시간이나 방식으로 얻은 숫자는 각각의 상황을 기록한 값일 뿐입니다.

이상 수치에서 구체적인 매개변수 확인으로

서버 하나만 실패하면 해당 서버의 주소, 포트, 프로토콜과 서비스 제공업체가 안내한 정보를 먼저 확인하세요. 같은 네트워크에서 모든 항목이 동시에 실패하면 네트워크 접속과 테스트 대상의 사용 가능 여부를 먼저 살펴보세요. 기본 테스트는 성공하지만 실제 연결에 실패한다면 암호, TLS, SNI, 시스템 시간과 인증서 검증을 확인하세요. 성공 결과를 얻기 위해 인증서 검증을 끄지 마세요. 보안 범위가 달라지고 기존 매개변수가 올바르다는 증거도 되지 않습니다. 서비스 제공업체가 안내한 올바른 매개변수로 수정하세요.

테스트 전후에는 데이터 사용량과 기기 상태도 확인해야 합니다. 테스트를 많이 하면 추가 연결이 발생하고 셀룰러 네트워크에서는 데이터가 차감됩니다. 백그라운드 동기화나 다운로드가 진행 중이면 유휴 상태와 다른 결과가 나올 수 있으므로 기록에 다른 전송 작업이 있었는지도 적으세요. 비교적 안정적인 환경에서 몇 차례 반복해 결과 범위와 실패 유형을 살펴보세요. 우연히 나온 최저값을 장기적인 결론으로 삼거나 테스트 순위를 서버 품질의 보증으로 여기지 마세요.

관련 문제 해결은 서버 시간 초과 확인 순서에서 이어서 살펴볼 수 있습니다. 수치와 실제 사용감의 차이를 이해하려면 지연 시간, 지역과 프로토콜 선택 안내를 참고하세요. 이 장에서는 측정 조건을 일정하게 유지하고 수치를 단서로 활용한 뒤 실제 요청으로 확인할 것을 권합니다. 서버 매개변수가 바뀌면 새 기준을 설정하고 이전 테스트 결과로 새 Config를 판단하지 마세요.

Log는 연결 과정의 오류를 찾는 데 도움이 되고 Data는 관련 데이터와 요청 정보를 확인하는 데 사용됩니다. 구체적인 메뉴 위치와 표시 항목은 현재 화면을 기준으로 확인하세요. 기록의 목적은 숫자를 계속 늘리는 것이 아니라 특정 실패를 당시의 대상, 정책과 오류 단계에 연결하는 것입니다. 문제를 확인하기 전에 명확한 질문 하나를 정하고 관련 기록을 살펴보세요. 과거 항목을 무작정 많이 보면 백그라운드 앱의 요청을 현재 페이지 실패 원인으로 오해하기 쉽습니다.

요청 하나를 기준으로 시간 순서 구성하기

시작 전에 기기의 시간, 네트워크 유형, Global Routing, 현재 Config와 선택된 서버를 기록하세요. 그런 다음 지정한 페이지를 여는 것처럼 대상 작업을 한 번만 재현하고 같은 시간대의 기록을 바로 확인하세요. 대상 도메인이 나타났는지, 조회 결과를 얻었는지, 어떤 규칙이 적용됐는지, 어떤 정책을 사용했는지, 최종 오류가 무엇인지 차례로 확인하세요. 여러 앱이 동시에 여러 도메인에 요청할 수 있으므로 페이지의 주 도메인에 연결됐다고 모든 리소스까지 성공한 것은 아닙니다.

로그 수준, 기록 스위치와 보관 방식의 초기값이 기기마다 같다고 가정하지 마세요. 일상적으로 사용할 때는 현재 목적에 맞는 기록 범위를 유지하고, 문제를 확인할 때만 상세 정보를 잠시 늘리는 것이 좋습니다. 상세 기록은 저장 공간과 처리 부담을 늘리고 더 많은 접속 정보를 포함할 수 있습니다. 기록 기능을 켠 뒤에는 실제 대상 작업과 관련된 내용이 생성되는지 확인하세요. 스위치를 켠 것만으로 진단이 끝난다고 볼 수 없습니다.

현재 화면에서 기록을 지울 수 있다면 오류 전후의 맥락을 보관해야 하는지 먼저 판단하세요. 필요한 정보를 저장한 뒤 깨끗한 재현 구간을 만들 수 있습니다. 로그를 지우면서 계속 재연결하지 마세요. 처음 발생한 오류가 이후 재시도에 묻힐 수 있습니다. 간헐적인 문제라면 오류 한 줄만 캡처하는 것보다 네트워크를 전환하기 전후의 기록을 조금 보관하는 편이 도움이 됩니다. 단일 오류는 앞선 실패로 인해 연쇄적으로 발생했을 수도 있습니다.

오류를 발생 단계별로 해석하기

DNS 오류는 먼저 DNS를 확인하세요. 연결이 거부되면 대상 포트와 서비스 상태를 살펴보세요. 시간 초과는 네트워크 경로, 대기 시간과 상대방의 응답을 확인해야 합니다. TLS 또는 인증서 오류는 SNI, 시스템 시간과 인증서 조건을 점검하세요. 오류 문구는 발생 단계 정보가 사라지지 않도록 가능한 한 원문 그대로 보관하세요. 같은 증상에도 원인이 다를 수 있습니다. timeout만 보고 DNS, 포트와 규칙을 한꺼번에 바꾸면 다음 기록과 비교하기 어려워집니다.

규칙 문제를 진단할 때는 ‘예상한 규칙’과 ‘실제로 적용된 규칙’을 구분해야 합니다. 예를 들어 특정 도메인에 DIRECT가 적용될 것으로 예상했는데 기록에 FINAL이 표시됐다면 규칙 대상이 맞지 않거나 순서가 잘못됐을 수 있습니다. 실제 요청에서 다른 하위 도메인을 사용했을 가능성도 있습니다. 추측한 도메인에 규칙을 계속 추가하지 말고 실제 대상을 복사해 비교하세요. 위에서 아래로 적용되는 순서와 기본 처리 규칙의 위치는 사용자 지정 규칙 우선순위 안내에서 확인한 다음 현재 Config에서 검증하세요.

트래픽 수치와 기록 범위

Data의 트래픽 통계는 집계 대상과 기간을 함께 고려해야 합니다. 앱에서 기록한 전송량은 서비스 제공업체의 청구량과 정확히 일치하지 않을 수 있습니다. 프로토콜 오버헤드, 과금 기준, 재전송과 통계 초기화도 차이를 일으킵니다. 누적 수치를 이번 달 남은 데이터로 바로 해석하지 마세요. 사용량을 확인하려면 서비스 제공업체의 과금 안내를 기준으로 삼고, 기기 통계가 언제부터 집계됐는지 기록하세요. 수치를 반복해서 초기화해 요금 차감 내역을 추측하지 마세요.

요청 기록에도 확인할 수 있는 범위가 있습니다. 앱 캐시, 기존의 장시간 연결, 시스템 동작과 기록 수준에 따라 표시 내용이 달라집니다. 특정 기록이 보이지 않는다고 요청이 없었다고 단정할 수는 없습니다. 연결 항목이 보여도 실제 서비스 통신까지 성공했다는 뜻은 아닙니다. 클라이언트 기록과 대상 앱의 실제 결과를 함께 판단하고 필요하면 새 연결을 설정해 다시 확인하세요. 암호화 통신에서는 기록으로 확인할 수 있는 범위가 앱의 전체 통신 내용과 같지 않습니다.

문제 확인이 끝나면 일시적으로 높였던 로그 수준을 복구하고 민감 정보가 포함된 사본은 필요한 범위에서 정리하세요. 어떤 오류가 발생했는지, 어느 항목을 변경했는지, 어떻게 다시 확인했는지, 기존 값으로 복구했는지를 짧게 기록해 두세요. 정리하지 않은 로그를 오래 보관하거나 Config 전체와 모든 접속 기록을 한꺼번에 보내지 마세요. 재사용할 수 있는 문제 해결 메모에는 작업과 결과를 남기고 비밀 정보는 저장하지 마세요. 다음에 비슷한 문제가 생겼을 때 기존 인증 정보를 노출하지 않고도 같은 방법을 재현할 수 있습니다.

Widget은 시스템이 제공하는 위치에서 상태를 확인하거나 작업으로 이동하는 빠른 접근 기능이며, 독립적인 연결 서비스가 아닙니다. 앱 설정, 시스템 권한과 시스템이 정하는 새로고침 시점에 따라 작동합니다. 사용하기 전에 Shadowrocket에서 수동 연결을 한 번 완료한 다음 Widget을 추가하거나 설정하세요. 최초 권한 부여를 마치지 않았다면 빠른 접근 기능에서 작업을 시작해도 앱이나 시스템 안내에서 확인이 필요할 수 있습니다. 이는 서버 매개변수의 유효성 여부와는 별개의 문제입니다.

먼저 앱을 설정하고 빠른 접근 추가하기

먼저 표시하거나 조작할 내용을 정하세요. 현재 상태를 확인할 것인지, 연결을 관리하기 위해 앱으로 빠르게 이동할 것인지 선택합니다. 시스템에서 제공하는 Widget의 크기, 배치 위치와 상호작용 방식은 기기 환경에 따라 달라질 수 있으므로 현재 기기의 추가 화면에서 확인하세요. 특정 크기, 버튼이나 고정된 배치가 모든 기기에서 지원된다고 안내하지 않습니다. 현재 시스템에 특정 항목이 표시되지 않으면 앱과 시스템의 지원 여부를 확인하세요. 해당 빠른 접근 기능을 찾으려고 서버 매개변수를 반복해서 바꾸지 마세요.

Widget의 초기 표시 상태도 연결 기본값으로 볼 수 없습니다. 추가 직후에는 캐시된 정보, 아직 로드되지 않은 내용 또는 이전 세션 정보가 표시될 수 있습니다. 추가한 뒤 주 앱을 한 번 열어 현재 서버와 연결 상태를 확인한 다음 다시 돌아와 표시 내용을 살펴보세요. 표시 항목을 선택할 수 있다면 가장 단순한 레이아웃부터 비교 기준을 만드세요. 복잡한 표시의 일부가 늦게 갱신된다고 연결 전체가 끊겼다고 판단하거나 서버 자동 전환의 유일한 근거로 삼지 마세요.

기기 홈 화면을 정리할 때 다른 사람에게 바로 보이는 정보가 무엇인지 고려하세요. 서버 메모에 용도, 조직이나 개인 식별 정보가 포함되면 암호가 없더라도 사용 습관이 드러날 수 있습니다. 민감한 내용을 포함하지 않는 메모를 사용하고 기기 공유 여부와 잠금 화면 표시 상황에 따라 배치 위치를 정하세요. Widget의 편리함과 정보 노출 가능성을 함께 고려해야 합니다. 잠금 화면에서 접근하거나 표시할 수 있는지는 시스템에서 실제로 제공하는 제어 항목으로 확인하고 다른 기기의 스크린샷을 기준으로 추측하지 마세요.

표시 갱신과 연결 상태는 따로 확인하기

시스템에서 Widget의 새로고침 시점을 관리하므로 표시가 주 앱의 실제 상태보다 늦게 바뀔 수 있습니다. 두 곳의 표시가 다르면 먼저 Shadowrocket을 열어 현재 연결을 확인하고 시스템 VPN 상태를 살펴본 뒤 실제 요청을 보내세요. Widget을 계속 눌러 강제로 동기화하지 마세요. 짧은 시간 안에 반복 조작하면 연결과 해제가 번갈아 발생해 새로운 오류가 생길 수 있습니다. 텍스트 갱신만 늦는 문제라면 전체 Config를 다시 설정하지 말고 표시 문제로 다루세요.

빠른 조작을 실행한 뒤에는 연결 절차가 끝날 때까지 기다린 다음 결과를 판단하세요. 서버 인증, DNS 조회와 터널 설정에는 시간이 걸립니다. Widget을 한 번 눌렀다고 대상 웹사이트에 연결된 것은 아닙니다. 조작 후 앱으로 이동했다면 시스템 권한이나 오류 안내가 있는지 확인하고 관련 Log를 살펴보세요. 빠른 접근 기능이 예상한 동작을 실행했는지 고정된 대상으로 한 번 확인하는 것이 좋습니다. 아이콘 모양이 바뀌었다고 전체 네트워크 테스트가 끝난 것은 아닙니다. 아이콘은 제한적인 상태 정보만 제공합니다.

On Demand와 함께 사용할 때

On Demand를 활성화한 상태에서는 Widget에서 수동으로 연결을 끊어도 이후 계속 끊어진 상태로 유지되지 않을 수 있습니다. 트리거 조건이 충족되면 시스템이 다시 연결을 시도할 수 있습니다. 자동 연결을 잠시 멈추려면 빠른 접근 기능을 조작하기 전에 On Demand 조건부터 확인하세요. Widget에서 반복해서 끄기만 하면 버튼이 작동하지 않는다고 오해할 수 있습니다. 테스트할 때는 ‘누른 동작이 실행됐는지’와 ‘이후 자동 연결이 발생했는지’를 따로 기록하세요. 두 단계를 하나의 결론으로 합치지 마세요.

서버 교체, Config 수정 또는 백업 복원 후에는 Widget에 표시되는 정보도 다시 확인해야 합니다. 이전 메모나 상태가 잠시 남을 수 있으므로 실제 요청에서 이전 서버를 사용한다고 단정하지 마세요. 주 앱을 열어 선택 항목을 확인한 뒤 새 요청을 보내고 기록으로 처리 경로를 살펴보세요. 주 앱의 실제 동작은 정상이지만 Widget이 계속 갱신되지 않는다면 시스템 절차에 따라 해당 빠른 접근 기능을 제거한 뒤 다시 추가할 수 있습니다. 이 작업은 표시를 위한 것으로 앱 내 Config까지 삭제해서는 안 됩니다.

일상적으로는 Widget을 앱을 여는 단계를 줄이는 보조 도구로 사용하고 중요한 변경은 주 앱에서 처리하는 것이 좋습니다. 구독 업데이트, 규칙 편집이나 프로토콜 매개변수 조정은 전체 화면과 필요한 안내를 확인하세요. 문제 해결 후에는 적절한 표시 방식으로 되돌리고 알아보기 쉬운 메모를 유지하며 시스템 개인정보 설정이 사용 환경에 맞는지 확인하세요. 빠른 접근의 편리함을 활용하면서 새로고침이 늦을 수 있는 작은 영역에 전체 진단과 연결 상태 증명을 맡기지 않을 수 있습니다.

iCloud 기능은 지원되는 범위에서 앱 데이터를 저장하거나 동기화하는 데 사용됩니다. 하지만 iCloud를 켰다고 서버, Config, 기록과 시스템 권한이 모두 완전히 동기화되는 것은 아닙니다. 실제로 동기화되는 항목은 현재 화면과 복원 결과를 확인해야 합니다. 구매 내역, 앱 데이터 동기화와 시스템 VPN 설정은 서로 별개입니다. App Store에서 구입한 앱을 다시 받을 수 있어도 연결 정보가 복원된 것은 아니며, 데이터가 나타나도 시스템 권한 확인을 건너뛸 수 있다는 뜻은 아닙니다.

동기화 전에 범위와 원본 사본 확인하기

동기화를 시작하기 전에 기기에 로그인된 iCloud 계정, 시스템에서 해당 앱의 iCloud 사용을 허용했는지, 클라우드 저장 공간과 네트워크 상태를 확인하세요. App Store에서 구매에 사용하는 계정과 iCloud 데이터 계정을 같은 것으로 간주하지 마세요. 두 계정의 역할은 다릅니다. 앱이 정상적으로 설치됐다고 동기화 계정도 같다는 뜻은 아닙니다. 먼저 민감 정보가 없고 쉽게 알아볼 수 있는 Config 메모로 동기화 경로를 확인한 다음 중요한 데이터를 처리하세요. 검증되지 않은 전체 복원에 처음부터 의존하지 않는 것이 좋습니다.

동기화 스위치의 초기값과 동기화 대상은 현재 기기에서 확인해야 하며, 이 매뉴얼에서는 모두 켜져 있거나 꺼져 있다고 가정하지 않습니다. 활성화하기 전에 직접 관리할 수 있는 Config 백업을 보관하고 사본을 실제로 읽을 수 있는지 확인하세요. 백업에 서버 인증 정보가 포함될 수 있으므로 저장 위치와 접근 권한을 신중하게 관리해야 합니다. 기기에 저장된 모든 파일이 안전한 백업인 것은 아닙니다. 편집 중인 파일과 같은 파일이라면 실수로 수정했을 때 독립적인 복원 지점이 될 수 없습니다.

주로 편집할 기기를 먼저 정하는 것이 좋습니다. 여러 기기에서 이름이 같은 Config를 동시에 수정하면 내용 차이, 지연 또는 충돌이 발생할 수 있으며 실제 결과는 동기화 방식에 따라 달라집니다. 앱을 마지막으로 연 기기의 내용이 올바른 버전이 된다고 가정하지 마세요. 한 기기에서 수정한 다음 다른 기기에 해당 내용이 표시될 때까지 기다리고 중요한 규칙을 하나씩 비교하세요. 파일 이름이 같다는 것은 이름만 같다는 뜻입니다. 규칙 내용, 서버 참조와 수정 결과까지 같다는 보장은 없습니다.

기기 교체 후 단계별 복원

복원할 때는 네 단계를 확인할 수 있습니다. 먼저 App Store에서 구입한 앱을 다시 받고, 앱 데이터가 나타나는지 확인한 다음 현재 서버와 Config를 점검하고, 마지막으로 시스템 안내에 따라 연결 권한을 부여하세요. 각 단계는 따로 확인해야 합니다. 데이터가 동기화됐는데도 연결이 실패하면 클라우드 데이터를 바로 지우기보다 매개변수와 권한을 확인하세요. 구입한 앱 복원과 호환성에 관한 내용은 기기 교체 및 재설치 안내를 참고하세요. 시스템 요구 사항은 App Store 페이지 표기를 기준으로 합니다.

구독 목록을 복원한 뒤에도 업데이트에 성공했는지, 서버 메모와 매개변수가 서비스 제공업체의 최신 안내와 일치하는지 확인해야 합니다. 동기화로 이전 목록이 복원됐더라도 구독 내용은 이미 변경됐을 수 있습니다. 구독 링크는 서비스 제공업체에서 받아 인증 정보로 안전하게 관리하세요. 공개 메모, 스크린샷이나 공유 문서에 링크를 넣지 마세요. 특정 서버에만 매개변수가 없으면 해당 항목의 출처를 확인하세요. 프로토콜 설정을 고치려고 iCloud를 반복해서 켜고 끄지 마세요.

동기화 불일치 문제 해결 순서

두 기기의 내용이 다르면 계정, 앱의 iCloud 권한, 네트워크와 사용 가능한 저장 공간을 먼저 확인한 다음 같은 항목을 비교 중인지 살펴보세요. 적절한 동기화 시간을 기다린 뒤 앱을 다시 열어 오류나 충돌 안내가 있는지 확인하세요. 양쪽에서 파일을 계속 수정, 삭제하고 같은 이름으로 다시 만들지 마세요. 차이가 생긴 이유를 파악하기 어려워집니다. 먼저 편집을 멈추고 양쪽의 내용을 각각 저장한 다음, 파일 이름보다 실제 내용을 기준으로 유지할 버전을 정하세요.

오프라인 기기를 다시 네트워크에 연결하면 오래된 내용이 동기화에 다시 참여할 수 있습니다. 중요한 Config를 복원하기 전에 어떤 기기에 이전 사본이 남아 있는지 파악하고 해당 기기를 연결한 뒤 결과를 확인하세요. 현재 화면에서 범위를 명확히 안내하지 않는 한 한 기기의 데이터를 삭제하면 ‘이 기기에서만 정리된다’고 가정하지 마세요. 민감한 데이터는 로컬 파일 삭제와 클라우드 사본 처리를 각각 확인해야 합니다. 한 화면을 지우면 모든 사본이 삭제된다고 오해하지 마세요.

일상적으로는 ‘동기화로 편리하게 사용하고 별도 백업으로 복원하는’ 이중 방식을 권장합니다. 백업에는 필요한 Config와 복원 안내만 보관하고 관련 없는 과거 기록은 제외하세요. 새 기기에서 다시 확인해야 하는 권한도 기록해 두세요. 복원 테스트는 중단해도 괜찮은 시간에 진행하고 성공한 뒤 임시 사본을 정리하세요. iPad의 화면 구성과 설정 이전에 관해서는 iPad 사용 안내를 참고할 수 있습니다. 어떤 기기든 실제 복원 결과를 기준으로 판단하세요.

Proxy 포트를 살펴볼 때는 먼저 원격 서버 포트와 로컬 프록시 수신 포트를 구분해야 합니다. Add Server에 입력하는 포트는 서비스 제공업체의 원격 서버에 연결할 때 사용합니다. 로컬 수신 포트는 해당 프록시 방식에 맞는 연결 요청을 받습니다. 서로 다른 항목이므로 ‘같은 값으로 맞추기’ 위해 동일한 숫자를 설정할 필요가 없습니다. 로컬 포트를 바꿔도 원격 서비스가 수신하는 위치는 바뀌지 않으며, 원격 포트를 바꿔도 기기 로컬의 포트 충돌은 해결되지 않습니다.

포트와 프로토콜은 일치해야 합니다

HTTP와 SOCKS5는 서로 다른 프록시 통신 방식이므로 요청을 보내는 쪽과 받는 쪽이 같은 방식을 지원해야 합니다. 숫자 하나만 입력한다고 연결이 올바르게 설정되는 것은 아닙니다. 올바른 주소와 프로토콜, 필요한 인증 정보도 있어야 합니다. 관련 기능을 사용할 수 있는지, 로컬 네트워크 접근이 허용되는지, 구체적인 항목 이름은 현재 Settings 화면에서 확인하세요. 화면에서 특정 수신 기능을 제공하지 않는다면 다른 앱의 사용 방식만 보고 Shadowrocket에도 같은 옵션이 있다고 가정하지 마세요.

로컬 포트의 초기값은 일반적으로 많이 쓰는 숫자가 아니라 현재 기기의 화면에서 직접 확인해야 합니다. 연결할 이유가 없다면 현재 값을 유지하는 것이 좋습니다. 필요한 경우 사용 중이 아닌 유효한 포트를 선택하고 요청을 보내는 쪽에도 똑같은 값을 입력하세요. 변경 후에는 설정이 저장됐는지만 확인하지 말고 실제로 수신 대기 중인지 확인해야 합니다. 포트가 이미 사용 중이라면 기존 용도를 먼저 확인하고 다른 포트를 사용하세요. 계속되는 충돌을 숨기려고 반복해서 앱을 재시작하지 마세요.

루프백 주소와 로컬 네트워크 주소도 구분해야 합니다. 한 기기에서 루프백 주소는 그 기기 자신을 가리키므로 다른 기기에서 자기 자신의 루프백 주소를 입력해 해당 기기에 접근할 수 없습니다. 로컬 네트워크에서 접근하려면 네트워크 연결, 올바른 기기 주소와 허용된 수신 범위가 필요합니다. 네트워크가 바뀌면 기기 주소도 달라질 수 있으므로 한 번 작동한 설정이 새 네트워크에서도 유효하다고 볼 수 없습니다. 이전 주소를 그대로 복사하지 말고 양쪽 기기가 서로 연결 가능한 네트워크에 있는지 확인한 뒤 포트를 테스트하세요.

수신 범위는 접근 경계입니다

현재 기능에서 로컬 네트워크에 공개할 수 있다면 일반적인 성능 스위치가 아니라 새로운 접근 지점으로 취급해야 합니다. 필요한 경우에만 활성화하고 이용 가능한 인증과 접근 제한을 확인하세요. 공용 네트워크에서 수신 범위를 함부로 넓히지 마세요. 사용이 끝나면 임시 접근 지점을 닫으세요. 네트워크의 다른 기기가 접근할 수 있는지는 네트워크 격리와 시스템 동작에도 영향을 받습니다. 한 번의 테스트가 실패했다고 접근 지점이 노출되지 않았다고 단정하지 말고 설정 범위 자체의 위험을 검토하세요.

테스트할 때는 먼저 이 기기의 연결이 정상인지 확인하세요. 그다음 요청을 보내는 기기에서 수신 주소에 접근할 수 있는지 확인하고, 프록시 유형과 인증을 점검한 뒤 대상 요청이 기록에 나타나는지 살펴보세요. 이 기기에서 접속이 이미 실패한다면 수신 포트를 계속 바꿔도 도움이 되지 않습니다. 이 기기는 정상인데 요청을 보내는 쪽의 기록이 전혀 없다면 주소, 포트와 네트워크 격리를 먼저 확인하세요. 요청은 기록에 나타나지만 오류가 반환되면 Log를 확인해 인증, DNS, 규칙과 원격 연결 문제를 구분하세요. 문제 해결 순서를 유지하는 것이 중요합니다.

최소 변경 기록으로 마무리하기

이 페이지의 설정을 변경했다면 마지막으로 전체 흐름을 확인하세요. 대상 요청을 새로 보내 실제 처리 정책을 확인하고 새로운 오류가 생겼는지, 다른 자주 사용하는 작업에는 영향이 없는지 살펴보세요. 포트나 수신 범위를 변경했다면 임시 접근 지점을 계획대로 닫았는지도 확인해야 합니다. ‘문제 해결’이라는 결론만 남기지 말고 기존 값, 새 값과 확인 조건을 함께 기록하세요. 네트워크 환경이 바뀌었을 때 복구가 필요한지 판단할 수 있어야 하며 예외 설정을 계속 추가해서는 안 됩니다.

아래는 개인 문제 해결 노트에 적합한 형식이며 가져올 수 있는 Config가 아닙니다. 암호, 구독 링크나 키는 기록하지 마세요. WireGuard 등의 프로토콜 항목에 관한 내용은 WireGuard 매개변수 안내에서 확인할 수 있습니다. 먼저 매개변수가 서버 프로토콜, 터널 주소 또는 로컬 수신 중 어느 단계에 속하는지 파악한 다음 해당 단계만 변경하세요. 이름이 비슷하지만 역할이 다른 옵션을 같은 테스트에서 함께 바꾸지 마세요.

관찰 대상: example.com
네트워크 조건: 현재 Wi-Fi
Global Routing：Config
변경 범위: 설정 항목 하나
기존 값 기록: 변경 전에 기기에 저장
확인 방법: 새 요청을 보내고 Log 확인
복원 방법: 이번 변경을 되돌린 뒤 재시험

문제를 계속 찾지 못한다면 최소 기준으로 돌아가세요. 유효한 서버, 명확한 Config, 사용 가능한 네트워크, 필요한 시스템 권한과 최소한의 사용자 지정 설정을 준비합니다. 모든 데이터를 초기화하기보다 DNS, 연결, 규칙, 앱 통신 순서로 조건을 하나씩 추가하세요. 구매 관련 문의는 가격 및 일회성 구매 안내를, 처음 연결하는 방법은 빠른 시작 가이드를 참고하세요. 이 페이지에서는 설정과 확인 방법을 안내하며 연결 서비스를 제공하지 않습니다. 서버 상태와 매개변수는 서비스 제공업체에 확인해야 합니다.