Shadowrocket 설정 항목 안내

ENTRY 01 / SCOPE & BASELINE

설정 범위와 변경 전 기준

Settings, Config 및 서버 매개변수

Settings는 앱 수준 옵션을 설정하는 곳으로, 주로 테스트, 기록, 자동 연결 및 보조 기능을 다룹니다. Config는 구성 파일을 관리하며 규칙과 파일 내 관련 매개변수를 설정합니다. Home의 서버 편집 페이지에서는 개별 연결 항목의 주소, 포트 및 프로토콜 정보를 관리합니다. 세 항목은 하나의 요청에 모두 영향을 줄 수 있지만 적용 범위는 서로 다릅니다. 기본 상태는 현재 앱에 표시된 값을 기준으로 합니다. 먼저 문제가 어느 영역에 해당하는지 확인한 뒤 관련 항목만 변경하세요. 이름이 비슷하다는 이유로 여러 항목을 한꺼번에 조정하지 마세요.

전체 동작과 개별 서버의 동작도 구분해야 합니다. 한 서버의 TLS 매개변수를 바꿔도 다른 서버의 문제는 대개 해결되지 않습니다. 현재 Config의 규칙을 변경하면 해당 파일을 사용하는 요청의 선택 결과가 달라집니다. 구독을 업데이트하면 구독에 포함된 일부 항목이 교체될 수 있으며, 원격 구성 업데이트로 파일 내용이 다시 적용될 수도 있습니다. 변경하기 전에 항목 이름과 출처, 현재 선택한 구성을 기록해 두세요. 그래야 방금 수정한 항목과 실제 사용 중인 항목을 혼동하지 않습니다.

먼저 Global Routing 기록하기

Global Routing은 전체 요청 처리 방식을 결정합니다. Config는 현재 Config에 따라 요청을 처리하고, Proxy는 요청을 프록시 경로로 보내며, Direct는 직접 연결합니다. 구체적인 예외는 앱 안내와 실제 기록을 함께 확인해야 합니다. 일반적으로 검증된 Config를 사용하고, 비교를 위해 Proxy 또는 Direct로 잠시 전환했다면 테스트 후 원래 값으로 되돌리세요. 문제 확인용 설정을 장기간 유지하지 않도록 주의하세요.

재현 가능한 기준 만들기

기준은 변경 전 조건을 기록한 것으로, 특정 속도 수치를 뜻하지 않습니다. 최소한 현재 네트워크가 Wi-Fi인지 셀룰러인지, Home에서 선택한 서버, Global Routing, 현재 Config, DNS의 기존 값과 On Demand 상태를 기록하세요. 그런 다음 접근이 허용되고 반복 요청이 쉬운 대상을 선택해, 실패가 이름 확인, 연결 수립, 콘텐츠 로드 중 어느 단계에서 발생하는지 적어 둡니다. 원인을 구분하기 어렵지 않도록 같은 네트워크와 같은 대상으로 변경 전후를 비교하세요. 네트워크, 서버, 규칙을 한꺼번에 바꾸면 원인을 파악할 수 없습니다.

매번 변수 하나만 변경하세요. 편집할 구성을 복사하거나 개인이 관리하는 안전한 위치에 기존 값을 기록한 뒤 한 가지 항목을 수정하고, 연결을 새로 수립해 같은 대상을 요청하세요. 일부 설정은 이미 수립된 연결에 바로 반영되지 않을 수 있고, 이전 페이지에는 캐시된 결과가 표시될 수 있으므로 새 요청으로 확인해야 합니다. 문제가 해결되지 않으면 먼저 기존 값으로 되돌린 뒤 다음 항목을 확인하세요. 검증하지 않은 변경을 연이어 적용하면 복구 가능한 단일 문제가 추적하기 어려운 복합 문제로 바뀔 수 있습니다.

시스템 권한 및 App Store 안내

처음 연결을 설정할 때 시스템에서 VPN 구성을 추가하도록 허용하라는 메시지가 표시될 수 있습니다. 이는 네트워크 구성을 관리하기 위한 시스템 권한 요청이며 서버 계정 확인 절차가 아닙니다. 허용하지 않았다면 프로토콜을 확인하기 전에 시스템 안내에 따라 권한을 완료하세요. 시스템 요구 사항은 App Store 페이지를 기준으로 확인하세요. 이 문서는 주로 iPhone과 iPad를 대상으로 합니다. 다른 Apple 기기의 호환성과 일반적인 구매 적용 범위는 App Store 안내를 확인하고, 한 기기의 화면 배치를 다른 기기에 그대로 적용하지 마세요.

앱을 확인할 때는 공식 아이콘, 개발자 이름 Shadow Launch Technology Limited, 앱 ID 932747118을 확인하세요. 앱을 구매하면 클라이언트를 사용할 수 있지만 연결에 필요한 구독 또는 서버 정보는 사용자가 별도로 준비해야 합니다. 설치와 첫 연결을 아직 완료하지 않았다면 튜토리얼의 순서에 따라 진행하세요. 이 페이지의 설정 변경 안내는 기본 구성을 식별할 수 있고 출처를 확인한 상태를 전제로 하며, 계정이나 매개변수 확인을 대신하지 않습니다.

ENTRY 02 / NAME RESOLUTION

DNS 설정과 이름 확인 경로

DNS의 역할

DNS는 도메인 이름을 주소로 변환합니다. 앱이 도메인에 요청을 보내면 먼저 주소를 조회한 뒤 연결할 수 있으며, 프록시 경로에서는 일부 이름 확인을 원격에서 처리할 수도 있습니다. 따라서 도메인이 열리지 않는다고 반드시 DNS에 문제가 있는 것은 아니며, DNS 응답이 있다고 이후 연결까지 정상이라는 뜻도 아닙니다. 기본 이름 확인 설정은 현재 앱과 Config에 표시된 값을 기준으로 합니다. 정상 작동하는 경로는 우선 유지하고, 원인이 분명한 대상부터 확인하세요. DNS 서버 변경을 모든 문제의 첫 조치로 삼지 마세요.

Settings의 DNS 관련 옵션과 Config의 DNS 매개변수를 함께 확인해야 합니다. 실제 적용되는 설정은 현재 파일과 기능 스위치의 영향을 받을 수 있으므로 한 화면만 확인해서는 안 됩니다. 먼저 사용 중인 Config를 확인하고, 그 안에 있는 이름 확인 항목을 기록한 다음 앱의 DNS 설정을 살펴보세요. 두 곳에 모두 설정이 있다면 현재 화면에 안내된 적용 범위에 따라 하나씩 검증하세요. 항목이 표시된 위치만 보고 고정된 우선순위를 추측하거나, 확인되지 않은 주소를 여러 개 한꺼번에 입력하지 마세요.

일반 DNS와 암호화 DNS

일반 DNS와 암호화 DNS는 주로 조회 데이터를 전송하는 방식이 다릅니다. DoH는 보통 HTTPS URL로 조회 엔드포인트를 지정하고, DoT는 일반적으로 TLS 연결을 통해 DNS 서비스에 접속합니다. 두 방식 모두 클라이언트가 해당 엔드포인트에 먼저 연결할 수 있어야 합니다. 암호화된 전송이 출구 정책을 자동으로 결정하는 것은 아니며 인증서 검증을 대신하지도 않습니다. 사용법을 알고 있고 현재 네트워크에서 연결 가능한 DNS 서비스만 사용하고, 입력란이 지원하는 형식에 맞춰 입력하세요. 일반 주소 입력란과 전체 URL 입력란은 서로 바꿔 쓸 수 없습니다. 문자열이 비슷해 보여도 그대로 복사하지 마세요.

암호화 DNS 엔드포인트 자체가 도메인 이름으로 지정된 경우에는 해당 엔드포인트의 주소를 어떻게 조회할지도 고려해야 합니다. 기본 이름 확인이 작동하지 않으면 도메인 형태의 엔드포인트만 입력해도 첫 연결을 수립하지 못할 수 있습니다. 엔드포인트에 연결할 수 있는지, 시스템 시간이 정확한지, 현재 네트워크에서 먼저 로그인이 필요한지, 앱의 관련 이름 확인 경로를 사용할 수 있는지 확인하세요. 오류를 우회하려고 여러 검증을 동시에 끄기보다, 기존에 작동하던 DNS로 되돌려 비교한 뒤 해당 엔드포인트를 계속 확인할지 결정하세요.

도메인 규칙과 주소 규칙

도메인 규칙은 요청에 포함된 도메인을 기준으로 일치 여부를 판단할 수 있고, 주소 규칙은 대상 주소를 기준으로 처리합니다. 주소 정보를 확인해야 하는 경우에는 이름 확인 결과가 이후 선택에 영향을 줄 수 있습니다. 아래 내용은 Config에서 흔히 볼 수 있는 작성 예시이며 DNS 서버 주소가 아니므로 DNS 입력란에 붙여 넣지 마세요. example.com은 설명을 위한 예시이고 GEOIP 결과는 앱에서 사용하는 데이터에 따라 달라집니다. 기록을 볼 때 ‘어떤 주소로 확인됐는지’와 ‘어떤 규칙이 선택됐는지’는 별개의 문제임을 구분하세요.

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

no-resolve를 주소 규칙에 사용하면 해당 규칙을 적용하기 위해서만 도메인 조회를 별도로 시작하는 동작을 막을 수 있습니다. 그렇다고 요청 과정 전체에서 DNS를 더 이상 사용하지 않는다는 뜻은 아닙니다. 일치 조건을 이해한 경우에만 추가하세요. 직접 연결되어야 할 도메인이 프록시 경로로 갔다면 이름 확인 오류라고 단정하지 말고 앞에 있는 규칙과 최종 정책을 확인하세요. 반환된 주소가 예상과 다르면 캐시, 네트워크 변경, 실제 사용 중인 DNS 서비스를 함께 살펴보세요.

확인 및 되돌리기 순서

DNS를 확인할 때는 같은 네트워크에서 같은 도메인을 반복 요청해 실패가 재현되는지 먼저 살펴보고, Log에서 확인 가능한 이름 확인 또는 연결 정보를 확인하세요. 주소를 얻었지만 연결 수립이 시간 초과되면 라우팅과 서버를 계속 확인하세요. 이름 확인 자체가 시간 초과되면 DNS 서비스의 연결 가능 여부와 입력 형식을 먼저 확인해야 합니다. 특정 앱에서만 문제가 발생한다면 해당 앱의 캐시나 이름 확인 방식도 고려하세요. 한 앱의 결과를 모든 시스템 요청에 공통으로 적용하지 마세요.

DNS를 변경한 뒤에는 앱에서 제공하는 방법으로 연결을 다시 수립하세요. 캐시 삭제가 필요하다면 현재 화면에서 명확히 제공하는 기능만 사용하세요. 그런 다음 대상을 다시 요청하고 기록을 비교하세요. 원래 값으로 되돌렸을 때 문제가 사라져야 변경과 현상이 관련 있다고 볼 수 있습니다. 문제가 계속되면 현재 네트워크, Config, 프로토콜 항목을 확인하세요. 검증된 기준 설정을 유지하고, 네트워크가 바뀔 때마다 새 DNS 항목을 추가해 어떤 설정이 필요한지 모르게 되는 상황을 피하세요.

ENTRY 03 / AUTOMATION

On Demand 연결

연결 조건과 정책 선택

On Demand는 조건에 따라 시스템에 VPN 연결을 설정하거나 처리하도록 요청하는 기능이며, 규칙 라우팅을 다른 방식으로 작성하는 기능은 아닙니다. On Demand는 언제 연결할지를 정하고, Config는 연결한 뒤 요청을 어떻게 처리할지를 정합니다. 기본 스위치와 기존 조건은 현재 앱에 표시된 값을 기준으로 합니다. 자동 연결 조건을 켜기 전에 수동 연결이 안정적으로 되는지 확인하고, 필요한 최소 조건만 설정하세요. 수동 연결부터 실패한다면 자동 연결은 실패를 반복할 뿐 서버에 빠진 매개변수를 채워주지 않습니다.

설정하기 전에 원하는 동작을 먼저 정하세요. 특정 Wi-Fi에서 연결할지, 셀룰러 네트워크에서 연결할지, 특정 도메인 조건에서만 실행할지 구체화합니다. 조건에 따라 연결, 무시 또는 다른 시스템 동작이 지정될 수 있으며 실제 선택지는 화면에 표시된 내용을 기준으로 확인하세요. ‘새 연결을 시작하지 않음’을 ‘기존 연결을 즉시 끊음’으로 해석하지 말고, 수동으로 끈 뒤 잠시 연결이 끊긴 것을 규칙이 비활성화된 증거로 보지 마세요. 다음 네트워크 변경 때 다시 실행될 수 있습니다.

Wi-Fi 및 SSID 조건

SSID는 무선 네트워크 이름이며 라우터 관리 주소가 아닙니다. 입력할 때는 화면의 안내에 따라 실제 이름의 대소문자, 공백과 기호를 그대로 유지하고 줄바꿈이 섞이지 않도록 하세요. 현장에서 확인할 수 있는 네트워크 조건을 하나 추가한 뒤, 해당 네트워크에 연결했을 때 시스템 VPN 상태를 확인하고 네트워크에서 벗어난 뒤 변화를 살펴보세요. 집 안의 여러 액세스 포인트가 같은 SSID를 사용할 수 있습니다. 이름이 같다고 동일한 네트워크 환경인 것은 아니며 특정 서비스에 접근하기 위한 신뢰 자격 증명도 아닙니다.

특정 Wi-Fi를 제외하는 조건을 설정했다면 더 넓은 범위의 Wi-Fi 조건이 함께 적용되는지도 확인하세요. 조건의 순서, 일치 범위와 동작이 결과에 영향을 줄 수 있으므로 현재 편집 화면의 순서와 설명을 기준으로 해석해야 합니다. 제외한 네트워크에서도 연결되는 것처럼 보이면 이미 연결이 수립되어 있었는지 먼저 확인하고, 다른 조건이 일치하는지 살펴본 뒤 시스템 구성이 저장됐는지 확인하세요. 조건 하나만 삭제했다고 모든 자동 연결이 중지됐다고 판단하지 마세요.

셀룰러 전환 및 도메인 조건

셀룰러 조건은 기기가 모바일 네트워크를 사용할 때의 On Demand 동작을 지정하며 특정 SSID 조건과 같지 않습니다. 테스트할 때 기기가 실제로 Wi-Fi에서 벗어났는지 확인하고, 앱에 셀룰러 데이터 사용 권한이 있는지도 살펴보세요. ‘새 연결 설정’과 ‘기존 연결을 유지한 채 네트워크 전환’은 세션 재수립 여부가 다를 수 있으므로 각각 테스트하는 것이 좋습니다. 네트워크 전환 중 잠시 연결이 끊기는 현상만으로 규칙 오류라고 단정하지 말고, 트리거 시점과 연결 기록을 함께 확인하세요.

도메인 조건은 특정 도메인과 관련된 트리거를 판단합니다. 그렇다고 해당 도메인의 모든 요청이 특정 프록시 정책을 반드시 따른다는 뜻은 아닙니다. 시스템 캐시, 기존 연결, 앱의 요청 방식에 따라 관찰되는 결과가 달라질 수 있습니다. 입력란에서 허용하는 도메인 형식에 맞춰 작성하고 전체 웹 주소나 경로를 도메인 조건으로 사용하지 마세요. 접근이 허용되고 반복 요청이 가능한 도메인으로 테스트한 뒤 연결이 수립되면 Config에서 예상한 정책이 선택됐는지도 별도로 확인하세요.

자동 재연결과 일시 중지 확인

수동으로 연결을 껐는데 다시 자동 연결되면 먼저 On Demand와 해당 조건을 확인한 다음 시스템의 VPN 구성 상태를 살펴보세요. 확인하는 동안 앱의 On Demand 기능을 잠시 끄고 저장한 뒤 수동으로 연결을 끊어, 다시 연결되는지 관찰하는 것이 좋습니다. 시스템 구성을 반복해서 삭제하거나 구독을 다시 가져오고 규칙까지 동시에 변경하지 마세요. 이런 작업은 트리거 전후의 비교를 어렵게 만들어 시스템이 다시 연결했는지 사용자가 구성을 다시 설치했는지 구분할 수 없게 합니다.

자동 연결을 다시 켜기 전에 테스트 중 추가한 중복 조건을 정리하고 각 조건의 용도를 확인하세요. Wi-Fi, 셀룰러, 화면 잠금 후 다시 사용할 때의 동작도 검증합니다. 백그라운드 동작은 시스템이 실제로 허용하는 실행 방식에 따라 다르므로, 한 번의 테스트 결과를 지속적인 실행 보장으로 여기지 마세요. 구체적인 상황은 Wi-Fi, 셀룰러 및 도메인 조건에 따른 On Demand 안내를 참고하세요. 평소 수동 연결만 필요하다면 검증된 수동 연결 절차를 유지해도 됩니다.

ENTRY 04 / CONNECTIVITY TEST

Ping 및 Connectivity Test

테스트 결과가 의미하는 범위

Ping과 Connectivity Test는 특정 탐지 방식에서의 도달 가능성이나 응답 시간을 확인하는 기능이며, 실제 서비스 요청이 성공한다는 보장은 아닙니다. 현재 선택한 테스트 방식에 따라 서버 입구를 확인하거나 지정된 경로를 통해 테스트 대상에 접근할 수 있습니다. 기본 방식, 대상과 시간 제한은 현재 앱에 표시된 값을 기준으로 합니다. 먼저 테스트 항목 설명을 읽고 어떤 구간을 측정하는지 확인한 뒤 수치를 비교하세요. 서로 다른 테스트 방식의 결과를 같은 기준으로 순위를 매기지 마세요.

서버 입구에 연결할 수 있다는 것은 당시 탐지 대상 주소와 포트가 응답했다는 뜻일 뿐입니다. 프로토콜 인증, TLS 협상, 원격 이름 확인, 대상 서비스는 여전히 실패할 수 있습니다. 반대로 특정 탐지 방식에 응답이 없다고 정상적인 요청까지 실패한다고 단정할 수 없습니다. 서버가 해당 탐지를 제한할 수 있기 때문입니다. 테스트 결과는 문제 범위를 좁히는 단서로 활용하고, 접근이 허용된 실제 대상으로 새 요청을 보내 확인하세요. 한 번의 성공 표시나 시간 초과만으로 결론을 내리지 마세요.

테스트 대상과 시간 제한

테스트 대상은 사용이 허용되고 응답이 안정적이며 용도가 분명한 주소를 선택하세요. 앱에서 전체 URL을 요구한다면 해당 형식으로 입력하고, 호스트나 포트만 요구한다면 전체 웹 주소를 붙여 넣지 마세요. 대상에서 리디렉션이 발생하거나 로그인이 필요하거나 요청 빈도가 제한되면 결과가 실제 사용 상황과 다를 수 있습니다. 먼저 대상 자체가 정상인지 확인한 다음 서버를 비교하세요. 모든 대상에서 시간 초과가 발생했다고 각 항목의 프로토콜 암호를 하나씩 바꾸지 마세요.

시간 제한은 결과를 기다리는 최대 시간을 지정하며 네트워크 성능을 직접 높이지 않습니다. 너무 짧으면 느리지만 사용할 수 있는 연결을 실패로 판단할 수 있고, 너무 길면 여러 항목을 검사하는 데 더 오래 걸립니다. 기존 값을 유지하다가 네트워크가 느려도 요청이 결국 완료되는 것을 확인한 경우에만 신중하게 조정하세요. 변경한 뒤에는 새 값을 기록하고 같은 항목의 결과를 여러 번 비교하세요. ‘성공’ 표시를 얻으려고 대기 시간을 계속 늘리면 이상을 찾아내는 의미가 없어집니다.

비교 조건을 동일하게 유지하기

대상을 비교하려면 최소한 네트워크, 테스트 방식, 테스트 대상과 대략적인 테스트 시간이 같아야 합니다. Wi-Fi와 셀룰러 결과, 정상 사용 중의 결과와 네트워크 전환 중의 결과를 한데 놓고 비교하지 마세요. 먼저 실제로 사용할 서버를 확인한 뒤 다른 기존 항목과 비교하세요. 여러 항목을 동시에 테스트하면 요청이 겹쳐 순간적인 혼잡과 기기 상태가 결과에 영향을 줄 수 있습니다. 한 번 순서가 달라졌다고 자동으로 계속 전환하면 오히려 연결을 더 자주 다시 수립하게 됩니다.

응답 시간이 짧다고 처리량이 높거나 앱 사용 경험이 반드시 더 좋다는 뜻은 아닙니다. 작은 요청 테스트는 연결 수립이나 응답 수신의 일부 단계만 반영하는 반면, 대용량 전송, 동영상 버퍼링, 지속적인 세션에는 다른 요인이 작용합니다. 일상적인 사용 가능성을 판단하려면 실제 요청이 완료되는지, 실패가 반복되는지, 네트워크 전환 후 복구되는지를 함께 확인하세요. 높은 빈도로 탐지해 변하지 않는 수치를 얻으려 하기보다 적절한 횟수로 반복해 일시적인 값을 걸러내세요.

실패 단계별 확인

모든 기존 항목이 같은 시점에 실패하면 로컬 네트워크, 테스트 대상, 시스템 시간, 네트워크 로그인이 필요한지부터 확인하세요. 특정 항목만 실패하는 경우에는 해당 항목이 만료됐는지, 주소를 확인할 수 있는지, 포트가 올바른지, 프로토콜 정보가 완전한지 살펴보세요. 테스트는 성공하지만 브라우저에서 실패한다면 같은 테스트를 반복해 서비스가 저절로 복구되길 기다리지 말고 현재 Global Routing, Config, DNS와 대상 자체를 확인하세요.

프로토콜 항목은 사용자가 보유한 서버 정보를 기준으로 확인해야 합니다. Shadowsocks의 암호화 방식과 비밀번호, VMess 또는 VLESS의 ID 항목, Trojan의 인증 및 TLS 정보, WireGuard의 키와 주소 범위는 각각 의미가 다릅니다. 화면에 모두 ‘포트’가 표시된다고 해서 서로 바꿔 입력할 수는 없습니다. 테스트 결과만으로 특정 항목이 올바르다고 입증되지 않았다면 지연 시간만 보고 값을 추측하지 마세요. 기존 정보를 유지하면서 각 항목을 원본과 하나씩 대조하세요.

조정이 끝나면 불필요한 일괄 테스트를 중지하고 다시 연결한 뒤 실제 대상을 방문하세요. 탐지 트래픽이 확인에 영향을 주지 않도록 하기 위한 절차입니다. 문제가 계속되면 테스트 방식, 실패 시간대, 네트워크 유형과 민감 정보를 제거한 오류 유형을 기록하세요. 연결 시간 초과 문제 해결 순서에 따라 계속 확인할 수 있습니다. 자료를 공유할 때는 전체 구독 URL, 인증 정보, 구성 전체를 첨부할 필요가 없습니다. 실패 단계만 설명하면 충분합니다.

ENTRY 05 / OBSERVABILITY

Log 및 Data 진단 기록

Log와 트래픽 통계의 차이

Log에서는 앱에 기록된 연결 이벤트, 오류와 요청 처리 단서를 확인할 수 있고 Data에서는 앱이 제공하는 트래픽 통계를 볼 수 있습니다. 둘 다 완전한 네트워크 감사 자료가 아니며 대상 서비스의 응답을 대신하지 않습니다. 기본 기록 상태, 보관 범위와 통계 기간은 현재 앱에 표시된 값을 기준으로 합니다. 문제를 재현하기 전에 관련 옵션을 확인하고 필요한 진단 범위만 활성화하세요. 관찰을 시작한 시간도 기록해 두면 관련 없는 과거 기록을 뒤지는 일을 줄일 수 있습니다.

통계 수치는 먼저 집계 범위를 확인해야 합니다. 화면에 현재 세션, 특정 서버 또는 누적 데이터가 표시될 수 있으므로 범위가 다른 값을 더해 통신사 청구 금액으로 해석하면 안 됩니다. 재시작, 초기화, 항목 전환 및 동기화로 기준이 달라질 수도 있습니다. 통계 기준을 확인하려면 제어된 요청 전후에 같은 통계 화면의 변화를 비교하세요. 기기 전체 사용량을 확인할 때는 시스템이 제공하는 통계를 별도로 참고하세요. 앱의 특정 수치 하나로 모든 네트워크 활동을 추정하지 마세요.

한 번의 재현으로 시간 흐름 확인하기

효과적인 재현은 가능한 한 짧아야 합니다. 현재 네트워크, 서버, Global Routing과 Config를 확인한 뒤 진단 화면을 열고 시각을 기록합니다. 그런 다음 실패 동작 하나만 수행하세요. Log로 돌아와 해당 시각 전후의 이벤트를 먼저 찾아 이름 확인, 연결, 협상, 응답 단계에 따라 살펴봅니다. 여러 앱을 동시에 열거나 구독을 업데이트하고 일괄 테스트까지 하면 관련 없는 요청이 기록에 섞여 방금 발생한 문제와 어떤 오류가 연결되는지 확인하기 어렵습니다.

오류를 읽을 때는 앞뒤 상황을 함께 살펴보세요. 연결 시간 초과는 특정 단계가 제한 시간 안에 완료되지 않았다는 뜻이며 원격 서버를 영구적으로 사용할 수 없다는 증거는 아닙니다. 연결 거부는 일반적으로 대상 포트와 서비스 상태를 확인해야 합니다. 인증서 오류가 발생하면 검증을 바로 끄지 말고 시간, 도메인, TLS 매개변수를 확인하세요. 프로토콜과 요청에 따라 구체적인 문구가 달라질 수 있으므로 현재 기록에 표시된 원문을 바탕으로 판단하세요. 이 페이지의 오류 유형이 화면에 반드시 똑같이 표시된다고 가정하지 마세요.

기록에서 규칙 선택 확인하기

현재 화면에서 관련 정보를 제공한다면 요청 도메인, 대상 주소, 일치한 규칙과 적용된 정책을 확인할 수 있습니다. 요청이 예상과 다른 경로로 갔다면 먼저 현재 Config를 실제로 사용했는지 확인한 다음 앞쪽 규칙이 먼저 일치했는지 살펴보세요. Log에 주소만 표시되고 도메인이 없다면 도메인 규칙이 적용됐다고 단정하지 마세요. 앱에서 이미 주소를 확인했거나 다른 연결 방식이 사용됐을 수 있으므로 화면에 표시된 근거에 따라 결론의 범위를 정하세요.

기록에 포함된 민감 정보

Log, 구독 주소와 구성에는 접근한 도메인, 서버 주소, 사용자 식별 정보와 인증 정보가 포함될 수 있습니다. 내보내거나 스크린샷을 찍기 전에 개인이 관리하는 안전한 위치에서 내용을 확인하고 민감 정보를 가리세요. 특히 URL의 쿼리 매개변수와 인증 정보가 포함된 한 줄 전체에 주의하세요. 오류 주변에 필요한 내용만 남기고 계정을 식별할 수 있는 정보는 숨기는 것이 좋습니다. 다만 정보를 가리더라도 이벤트 순서와 오류 유형은 남겨야 문제 해결 근거를 유지할 수 있습니다.

진단을 마친 뒤에는 현재 앱에서 제공하는 기능을 사용해 임시로 활성화한 상세 기록을 끄고, 더 이상 필요하지 않은 로컬 기록은 필요한 경우 정리하세요. 오래된 기록을 많이 보관하면 검색이 어려워지고 추가 접근 기록이 남을 수 있습니다. Log를 끈다고 기존 기록까지 삭제되는 것은 아니며, Data를 정리한다고 구독이나 서버 항목이 삭제되는 것도 아닙니다. 각 기능이 다루는 대상이 다르므로 확인 메시지를 읽고 실행해 구성을 실수로 삭제하지 않도록 하세요.

최종 결론은 하나의 근거 흐름으로 설명할 수 있어야 합니다. 어떤 네트워크에서 어떤 항목으로 어떤 요청을 했는지, 어떤 기록이 나타났는지, 무엇을 변경한 뒤 결과가 달라졌는지를 연결하세요. 이 관계를 확인할 수 없다면 기록 범위를 계속 넓히기보다 최소한의 재현 단계로 돌아가 다시 관찰하세요. 시스템 설정, 현재 구성과 요청 자체가 함께 영향을 주는 문제라면 이 장을 DNS 및 Config 장과 함께 살펴보세요. 오류 유형을 이미 알고 있다면 문서 끝의 문제 해결 문답에서 빠르게 확인할 수 있습니다.

ENTRY 06 / WIDGET & ICLOUD

Widget, iCloud 동기화 및 구성 저장

Widget의 역할과 범위

Widget은 시스템에서 앱 정보를 표시하거나 빠른 작업을 실행하는 진입점입니다. 표시 내용과 조작 기능은 기기 시스템과 현재 앱의 구현에 따라 달라집니다. 기본적으로 Widget을 추가해야 하는지, 어떤 항목을 표시하는지는 현재 시스템과 앱 화면을 기준으로 확인하세요. 먼저 앱에서 정상 연결을 확인한 뒤 필요한 Widget을 추가하세요. 홈 화면에 Widget이 있다고 VPN이 연결된 것은 아니며, Widget 표시가 갱신되지 않았다고 서버 연결이 끊긴 것도 아닙니다.

추가할 때는 시스템의 Widget 편집 화면에서 Shadowrocket을 찾아 현재 제공되는 스타일을 선택하세요. Settings에 관련 표시 옵션이 있다면 용도에 맞춰 조정할 수 있습니다. Widget 갱신 시점은 시스템 스케줄에 영향을 받으므로 앱과 홈 화면의 상태가 동시에 바뀌지 않을 수 있습니다. 중요한 작업 후에는 Home을 열어 연결 상태와 현재 서버를 확인하세요. 특히 네트워크 전환, 구성 변경 또는 테스트 종료 직후에는 갱신되지 않았을 수 있는 빠른 표시만으로 판단하지 마세요.

빠른 동작과 자동 연결의 관계

Widget은 동작을 시작하는 진입점일 뿐 서버 인증이나 Config의 기본 요건을 바꾸지 않습니다. 첫 시스템 권한 설정이 끝나지 않았거나 선택한 항목의 매개변수가 부족하거나 On Demand 조건이 남아 있으면 빠른 동작이 예상과 다르게 실행될 수 있습니다. 먼저 앱 안에서 이러한 문제를 확인한 뒤 Widget을 테스트하세요. 눌렀을 때 상태가 반복해서 바뀐다면 연결 문제를 해결하려고 Widget을 계속 다시 추가하지 말고 On Demand 조건도 함께 확인하세요.

iCloud 동기화는 구독 업데이트와 다릅니다

iCloud 동기화는 현재 기능에서 명시적으로 지원하는 데이터를 동기화합니다. 사용자의 서비스 제공자에게 새 구독 내용을 요청하는 기능이 아니며, 시스템 권한이나 임시 상태까지 모든 기기에 복제한다고 보장하지 않습니다. 기본 스위치와 동기화 항목은 현재 앱 안내를 기준으로 확인하세요. 두 기기의 계정, iCloud 사용 권한과 네트워크 상태를 확인한 뒤 앱이 동기화를 지원하는 항목을 살펴보세요. 다른 기기에 앱을 설치했다고 모든 연결 항목이 자동으로 준비됐다고 가정하지 마세요.

구독 업데이트, 원격 Config 업데이트, iCloud 동기화는 각각 다른 작업입니다. 구독을 업데이트하면 구독에 포함된 서버 목록이 바뀔 수 있고, 구성을 업데이트하면 규칙 내용이 교체될 수 있습니다. 동기화는 저장된 데이터를 다른 기기에 전달할 수 있습니다. ‘수정한 내용이 다시 원래대로 돌아감’ 현상이 발생하면 모든 변화를 동기화 문제로 단정하지 말고 어떤 작업이 실행됐는지 먼저 확인하세요. 항목의 출처를 기록하고 여러 기기에서 같은 항목을 동시에 편집하지 않는 것이 좋습니다. 특히 원격 콘텐츠를 업데이트하면서 로컬 사본을 덮어쓰지 않도록 주의하세요.

동기화 충돌과 삭제 전파

동기화 충돌은 여러 기기에서 같은 데이터가 서로 다르게 수정된 상태입니다. 실제로 어떤 내용이 유지되는지는 현재 앱의 동작에 따라 달라지므로 최근에 확인한 내용이 유일한 정답이라고 가정하지 마세요. 처리하기 전에 개인이 관리하는 안전한 위치에 양쪽 기기의 중요한 구성을 저장하고 유지할 사본을 정한 다음 항목별로 병합하거나 다시 가져오세요. 동기화 방향이 분명하지 않은 상태에서 기능을 반복해서 켜고 끄거나, 새로고침을 강제로 시도하려고 항목을 연달아 삭제하지 마세요. 삭제도 다른 기기에 전파될 수 있습니다.

사본을 저장할 때는 서버 정보, 구독 출처와 Config 파일을 구분하세요. 세 가지를 알아볼 수 없는 하나의 내보내기 파일로 합치지 마세요. 파일 이름에는 용도와 개인적인 변경 설명을 기록할 수 있지만 비밀번호나 전체 구독 주소는 넣지 마세요. 인증 정보가 포함된 자료는 개인이 관리하는 안전한 저장소에 보관하고, 가져온 뒤 항목 수와 주요 필드가 온전한지 확인하세요. 백업이 성공했다는 기준은 파일이 만들어졌다는 사실이 아니라 실제로 복구해 검증할 수 있는지입니다.

기기 변경 후 확인 순서

기기를 바꿀 때는 먼저 App Store에서 Shadowrocket을 받으세요. 앱 구매 복원과 구매 적용 범위는 기기 변경 및 재설치 안내를 참고하세요. 그다음 동기화하거나 가져온 데이터를 확인하고 새 기기에서 필요한 시스템 권한을 설정합니다. VPN 권한, Widget 배치와 현재 네트워크 환경은 다른 기기의 상태가 그대로 복제된다고 볼 수 없습니다. 매개변수가 모두 확인된 서버 하나로 수동 연결을 먼저 테스트하고, 성공한 뒤 On Demand와 보조 표시 설정을 복원하세요.

마지막으로 두 기기에서 예상한 Config를 사용 중인지 확인하고 구독 업데이트 후 로컬 수정 사항이 남아 있는지 살펴보세요. 중요한 규칙을 수정했다면 변경 이유를 기록해 업데이트 후 다시 확인할 수 있도록 하세요. 한 기기에서만 문제가 발생한다면 다른 기기의 정상 구성을 바로 삭제하지 말고 해당 기기의 권한, 네트워크와 현재 선택 항목부터 비교하세요. ‘앱 받기, 데이터 복원, 수동 확인, 자동화 복원’ 순서로 진행하면 사용할 수 있는 기준 상태를 유지하기 쉽습니다.

ENTRY 07 / PROXY & PROTOCOL

Proxy 포트 및 서버 프로토콜 매개변수

로컬 포트와 원격 포트

Proxy 관련 포트는 먼저 방향을 구분해야 합니다. 로컬 수신 포트는 해당 진입점을 사용하도록 명확히 설정된 요청이 연결하는 포트이고, 서버 포트는 사용자가 보유한 원격 서비스의 진입점입니다. 둘은 서로 다른 값이며 대신 사용할 수 없습니다. 기본 포트, 수신 범위와 기능 상태는 현재 앱에 표시된 값을 기준으로 합니다. 용도가 분명하지 않으면 기존 값을 유지하세요. 로컬 프록시 진입점이 실제로 필요하고 요청이 해당 지점에 도달하는 방식을 이해한 경우에만 관련 설정을 변경하세요.

로컬 포트를 변경할 때는 입력 가능한 범위와 해당 기능의 활성화 여부를 확인하고 다른 수신 서비스와 충돌하지 않도록 하세요. 포트를 바꾸면 이전 포트를 명시적으로 가리키던 요청은 새 값을 자동으로 알 수 없으므로 연결 설정도 함께 수정해야 합니다. 화면에 다른 기기의 접근을 허용하는 옵션이 있다면 수신 범위와 현재 네트워크의 접근 조건도 확인하세요. 꼭 필요한 범위만 허용하세요. 접근 허용을 속도를 높이는 스위치로 여기지 말고, 앱을 백그라운드로 보냈다고 진입점이 계속 사용 가능하다고 가정하지 마세요.

프로토콜 필드를 서로 바꿔 적용하지 않기

원격 서버를 편집할 때는 사용자가 보유한 완전한 매개변수를 기준으로 해야 합니다. Shadowsocks에는 보통 암호화 방식과 비밀번호가 필요합니다. VMess와 VLESS에는 해당 ID 필드와 전송 설정이 있습니다. Trojan은 일반적으로 인증과 TLS 관련 정보가 필요하며 Hysteria2와 WireGuard도 각각 자체 인증 또는 키, 주소 등의 항목을 사용합니다. 먼저 프로토콜 종류를 확인하고 현재 화면의 필수 항목을 하나씩 대조하세요. 다른 프로토콜의 비밀번호를 ID 항목에 입력해 보며 테스트하지 마세요.

Subscribe로 가져온 항목에도 누락된 필드, 형식 불일치, 변경된 정보가 있을 수 있습니다. 가져오기에 성공했다는 것은 앱이 어떤 내용을 인식해 저장했다는 뜻이지 원격 인증까지 성공했다는 증거는 아닙니다. 구독에 포함된 항목을 직접 수정했다면 다음 업데이트에서 덮어쓰이는지도 확인하세요. 비교에 필요한 원본 정보를 먼저 보관하고 사용 권한이 있는 구성을 전제로 각 필드를 대조하세요. 서버를 시험해 보려고 프로토콜 종류를 임의로 바꾸지 마세요.

TLS, SNI 및 시스템 시간

TLS는 인증서 검증을 거치는 암호화 연결을 설정하는 데 사용되며, SNI는 일반적으로 핸드셰이크에서 서버 이름을 지정합니다. 주소, 인증서 도메인과 앱의 관련 필드가 서로 다를 수 있으므로 입력 방법은 사용자가 보유한 서버 정보를 따라야 합니다. 인증서 검증은 유지하고 도메인 철자, 기기 시간과 필요한 중간 설정을 확인하세요. 인증서 오류를 관련 없는 도메인을 입력하거나 검증을 꺼서 감추면 연결 검증 조건이 달라지므로 그렇게 처리하지 마세요.

전송 계층 필드도 정확하게 입력해야 합니다. 경로는 대소문자를 구분할 수 있고 Host는 연결 주소와 다른 역할을 할 수 있으며 여분의 공백도 요청이 일치하지 않는 원인이 됩니다. 수정하기 전에 기존 값을 복사해 비교하고, 변경 후 연결을 다시 수립해 오류가 입구 연결 단계에서 프로토콜 협상 또는 응답 단계로 진행하는지 확인하세요. 더 명확한 근거 없이 오류가 그대로라면 원래 값으로 되돌리세요. 여러 필드를 반복해서 바꾸면 원래 사용할 수 있었던 정보만 잃을 수 있습니다.

원격 구성과 로컬 기능의 범위

일부 기능은 원격 서버의 지원이 필요하므로 로컬 스위치만으로 추가할 수 없습니다. 포트에 연결할 수 있다고 원격 서버에서 선택한 프로토콜을 사용하도록 설정했다는 뜻은 아니며, 테스트 성공이 모든 전송 방식을 지원한다는 뜻도 아닙니다. WireGuard에서는 주소 범위와 라우팅 의도가 기존 구성에 맞아야 합니다. 다른 프로토콜도 인증과 전송 설정이 서로 맞아야 합니다. 서버에서 받은 정보를 서로 연관된 매개변수의 집합으로 보고, 무작위로 조합할 수 있는 독립된 후보 값으로 취급하지 마세요.

확인이 끝나면 규칙을 변경하지 않은 상태에서 서버 하나를 먼저 테스트하고, Config로 돌아와 대상 요청에 적용할 정책을 확인하세요. 대상에서 계속 실패한다면 요청이 선택한 서버를 거치지 않은 것인지, 서버를 거친 뒤 응답을 완료하지 못한 것인지 구분해야 합니다. 로컬 Proxy 진입점, 원격 연결, 대상 요청은 연속된 과정이지만 각각 별도의 단계이며 단계마다 근거를 확인해야 합니다. 로컬 수신 기능이 필요하지 않다면 원격 인증 문제를 확인하려고 로컬 포트를 바꿀 필요가 없습니다.

ENTRY 08 / CONFIG & VERIFICATION

Config 규칙, 변경 검증 및 되돌리기

규칙 순서와 최종 정책

Config에는 요청 처리에 사용할 설정 내용이 저장됩니다. 규칙은 순서대로 일치 여부를 확인하며 먼저 일치한 적용 규칙이 해당 정책을 결정하고, FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 기본 규칙 집합은 현재 선택된 파일을 기준으로 합니다. 먼저 기존 파일의 의도를 파악한 뒤 필요한 규칙만 추가하세요. 선택되지 않은 파일만 편집해도 현재 요청에는 변경 내용이 적용되지 않습니다. 검증 전에 Config로 돌아가 사용 중인 파일을 확인하고 Global Routing이 Config인지 살펴보세요.

규칙 키워드는 일치 조건을 정하고 정책은 규칙이 일치한 뒤의 처리 방식을 정합니다. DOMAIN은 정확한 도메인, DOMAIN-SUFFIX는 도메인 접미사, DOMAIN-KEYWORD는 지정 키워드가 포함된 도메인에 사용합니다. IP-CIDR과 IP-CIDR6은 주소 범위에, GEOIP는 지리적 주소 데이터에 사용됩니다. PROXY, DIRECT, REJECT는 서로 다른 정책을 나타내므로 규칙 키워드와 정책 위치를 바꿔 쓸 수 없습니다. 관련 없는 요청까지 잘못 일치하지 않도록 범위가 분명한 조건을 우선 사용하세요.

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

이 예시에서는 api.example.com이 정확한 규칙에 먼저 일치하고, 그 밖에 example.com 접미사에 해당하는 도메인은 다음 정책을 적용합니다. 주소 범위 규칙은 예시의 직접 연결 의도를 나타내지만 모든 네트워크에서 같은 로컬 주소 구성을 사용한다는 뜻은 아닙니다. 이 내용은 문법과 순서를 이해하기 위한 예시이며 누구에게나 적합한 완성된 구성은 아닙니다. 자신의 구성을 통째로 이 몇 줄로 덮어쓰지 말고, 필요한 규칙을 백업해 둔 파일에 넣어 하나씩 테스트하세요.

원격 업데이트와 사용자 지정 변경

원격 Config를 업데이트하면 새로운 규칙 내용이 포함될 수 있으며 로컬 수정이 유지되는지는 현재 앱의 저장 및 업데이트 방식에 따라 확인해야 합니다. 원격 원본 파일과 테스트용 사본을 구분하고 변경 기록에 ‘추가한 이유’와 ‘검증한 대상’을 적어 두세요. 구독의 서버 목록과 Config 규칙의 출처도 따로 기록해야 합니다. 서버 목록 업데이트가 규칙 업데이트를 뜻하지는 않습니다. 내용이 달라졌다면 실제로 어떤 항목을 업데이트했는지 먼저 확인해 서버 이름 변경을 규칙 순서 변경으로 오해하지 마세요.

요청이 예상한 규칙에 일치하지 않으면 다음 순서로 확인하세요. Global Routing이 Config 모드인지, 현재 파일이 올바른지, 앞에 더 넓은 범위의 규칙이 있는지, 실제 요청에서 원래 도메인을 사용했는지, FINAL이 앞서 기본 처리했는지 살펴봅니다. 일부 앱 요청에는 주소만 표시되거나 리디렉션으로 다른 도메인에 접근할 수 있으므로 처음 확인한 도메인 하나가 전체 과정을 설명하지 않을 수 있습니다. Log에서 확인 가능한 정보를 토대로 일치 대상을 파악한 뒤 도메인 규칙과 주소 규칙 중 무엇을 추가할지 결정하세요.

변경 사항 전체 검증하기

완전한 변경 검증에는 변경 전 기준, 단일 항목 변경, 연결 재수립, 같은 대상에 대한 요청과 결과 기록이 포함되어야 합니다. 스위치가 켜진 상태를 유지하는 것이 성공의 기준은 아닙니다. 예상한 대상이 예상한 경로를 통해 완료되고 다른 필수 요청에도 문제가 없어야 합니다. 먼저 같은 네트워크에서 확인한 뒤 평소 사용하는 다른 네트워크 조건에서도 살펴보세요. On Demand를 함께 사용한다면 자동 연결이 실행된 뒤에도 예상한 Config가 적용되는지 확인하세요. 수동 연결 결과만 검증해서는 충분하지 않습니다.

되돌릴 때는 방금 변경한 항목만 원래대로 복원하면 되며 앱 전체를 바로 초기화할 필요는 없습니다. 규칙 오류라면 파일을, DNS 오류라면 이름 확인 설정을, 프로토콜 오류라면 해당 서버 필드를 복구하세요. 현재 상태를 파악할 수 없고 중요한 데이터를 저장해 둔 경우에만 더 넓은 범위의 재구성을 고려합니다. 복원 후에도 같은 요청을 반복해 기준 상태가 실제로 돌아왔는지 확인하세요. 계속 실패한다면 네트워크나 원격 상태가 바뀌었을 수 있으므로 현재 조건에서 기준을 다시 설정해야 합니다.

자주 묻는 문제 해결 질문

처음 가져오기를 아직 완료하지 않았다면 빠른 시작 튜토리얼로 돌아가 순서에 따라 진행하세요. 규칙 적용 범위와 FINAL의 위치를 확인하려면 사용자 지정 규칙 및 최종 정책 안내를 이어서 읽어보세요. 이 페이지의 설정 방법은 실패 단계에 맞는 장을 찾아 기존 값을 보존하고 필요한 부분만 변경한 뒤 기록으로 확인하는 것입니다. 모든 설정을 한꺼번에 켜지 마세요.