Shadowrocket 프록시 모드및 주요 설정

무엇인가요: Global Routing은 요청에 적용할 라우팅 방식을 결정합니다. 연결 스위치, SERVER에서 선택한 서버와는 서로 다른 항목입니다. 스위치는 연결 활성화 여부를, 모드는 경로 선택 방식을, 서버는 프록시 연결에 사용할 수 있는 대상을 결정합니다. SERVER만 변경해도 Config가 Proxy로 바뀌지 않으며, 기존에 DIRECT 규칙에 일치한 요청이 프록시를 거치게 되는 것도 아닙니다.

어디에서 설정하나요: Home으로 이동해 Global Routing을 열고 Config, Proxy, Direct 중 현재 선택된 항목을 확인합니다. Config는 라우팅 모드이자 설정 관리 페이지의 이름이기도 합니다. 사용 안내를 읽을 때는 라우팅 모드와 페이지 메뉴를 구분하세요.

설정 방법: ① Home에서 사용할 서버를 선택합니다. ② Global Routing을 Config로 설정합니다. ③ Config 페이지에서 원하는 설정이 활성화되어 있는지 확인합니다. ④ 연결을 켜고 접속 여부를 확인할 수 있는 대상을 엽니다. 문제를 점검할 때는 Proxy 또는 Direct로 잠시 바꾼 뒤 같은 대상을 다시 테스트하고, 테스트가 끝나면 원래 모드로 되돌립니다.

주의 사항: 모드 전환은 원인을 비교하는 데 도움이 될 뿐, 한 번 성공했다는 이유만으로 원인을 확정할 수는 없습니다. 앱 캐시, 기존 연결 및 DNS 캐시에 이전 결과가 남아 있을 수 있습니다. 모드를 바꾼 뒤 새 요청을 보내고 네트워크 환경을 기록하세요. Proxy에서는 접속되지만 Config에서는 되지 않는다면 모든 서버를 다시 만들기보다 규칙 일치 여부와 정책 참조를 먼저 확인하세요.

무엇인가요: 규칙별 트래픽 분기는 대상마다 다른 정책을 적용합니다. DOMAIN은 전체 도메인, DOMAIN-SUFFIX는 도메인 접미사, DOMAIN-KEYWORD는 도메인 키워드에 따라 일치 여부를 판단합니다. IP-CIDR과 IP-CIDR6은 각각 IPv4 및 IPv6 주소 대역에, GEOIP는 IP의 지역 정보에 따라 적용됩니다. 규칙은 대개 위에서 아래로 확인하며, 먼저 일치한 규칙이 후속 처리를 결정합니다. 따라서 범위가 넓은 규칙을 구체적인 규칙보다 앞에 두지 않는 것이 좋습니다.

어디에서 확인하나요: Config에서 현재 설정을 열고 [Rule] 섹션과 참조된 정책을 확인합니다. 수정 전에 복구할 수 있는 사본을 보관하세요. 특히 이름이 비슷한 다른 설정 파일이 아니라 현재 활성화된 파일을 수정하는지 확인해야 합니다. 원격 설정은 업데이트 후 로컬 수정 사항을 덮어쓸 수 있으므로, 장기간 사용하기 전에 설정의 관리 출처를 확인하세요.

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

설정 방법: ① 개별 처리할 대상을 정리합니다. ② 구체적인 규칙을 먼저 작성하고 범위 규칙을 추가합니다. ③ 각 규칙에 실제로 존재하는 정책을 지정합니다. ④ 마지막에 FINAL을 두어 나머지 요청을 처리합니다. ⑤ 설정을 저장하고 활성화한 뒤 다시 테스트합니다. 위 내용은 규칙 구문 예시이며, 모든 네트워크에 적합한 완성 설정이나 서버 정보가 아닙니다.

주의 사항: PROXY, DIRECT, REJECT는 각각 프록시, 직접 연결, 거부 처리를 뜻하는 정책 키워드입니다. 번역해서 규칙에 입력하지 마세요. 도메인 규칙과 IP 규칙은 서로 다른 정보에 의존하므로, IP 주소로 접속한다고 해서 특정 도메인에 접속한 것과 같은 것은 아닙니다. USER-AGENT처럼 요청 정보에 의존하는 규칙은 적용 조건이 있으므로 암호화된 모든 요청을 식별한다고 가정할 수 없습니다. 규칙이 일치하지 않으면 실제 요청 대상을 먼저 확인한 뒤 규칙 순서를 조정하세요. 자세한 설명은 용어 설명을 참고하세요.

무엇인가요: 서버 항목에는 프로토콜, 주소, 포트와 인증 정보가 저장됩니다. 구독은 여러 서버 항목을 가져오고 업데이트하는 데 사용하며, 설정 파일은 라우팅과 DNS 등의 동작을 구성합니다. 서버를 가져와도 관련 규칙이 활성화되는 것은 아니며, 구독을 업데이트해도 Config의 규칙 파일이 함께 업데이트되는 것은 아닙니다. 이 세 가지를 구분해 확인하면 목록에 항목이 있는데도 연결되지 않는 상황을 잘못 판단하는 일을 줄일 수 있습니다.

어디에서 확인하나요: Home의 SERVER 영역에서 서버를 확인하고 선택할 수 있습니다. Add Server는 서버 항목을 추가하고 Subscribe는 해당 구독 메뉴를 엽니다. Config에서는 설정 파일을 관리합니다. 구독 메뉴에서 서버 목록이 아니라 설정 파일을 구독할 수도 있으므로 제목과 가져오기 결과를 먼저 확인하세요. Scan QR Code와 클립보드 인식은 정보를 입력하는 방법일 뿐, 원본 정보의 유형을 바꾸지는 않습니다.

설정 방법: ① 본인이 보유한 구독 링크나 서버 매개변수를 준비합니다. ② 해당 메뉴에서 가져오고, 직접 입력할 경우 먼저 올바른 Type을 선택합니다. ③ 주소, 포트와 프로토콜에 필요한 인증 항목을 확인합니다. ④ Home으로 돌아가 가져온 그룹과 실제 선택된 서버를 확인합니다. ⑤ Connectivity Test로 기본 연결을 확인한 뒤 실제 대상을 방문합니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard, HTTP, SOCKS5는 입력 항목이 서로 다르므로 다른 프로토콜의 입력 방법을 그대로 적용하지 마세요.

주의 사항: 구독 링크에는 접속 자격 정보가 포함되는 경우가 많습니다. 스크린샷이나 진단 자료를 공유하기 전에 전체 링크와 인증 정보를 가리세요. 구독 업데이트 후 항목의 이름, 개수 또는 그룹이 달라질 수 있으므로 현재 선택 항목을 다시 확인하세요. 구독으로 생성된 항목을 직접 수정하면 이후 업데이트 과정에서 변경 내용이 대체될 수도 있습니다. 실패 원인이 ‘구독 다운로드 실패’, ‘내용 인식 실패’, ‘가져온 뒤 연결 실패’ 중 무엇인지 먼저 구분한 다음 문제 해결 매뉴얼에서 증상에 따라 확인하세요. 정상적인 항목을 반복해서 삭제하지 마세요.

무엇인가요: On Demand는 시스템에서 지원하는 조건에 따라 연결 여부를 결정합니다. 이는 ‘언제 연결할지’를 정하는 기능이지, ‘특정 도메인에 어떤 정책을 적용할지’를 정하는 기능은 아닙니다. 도메인과 IP의 경로 선택은 Global Routing 및 설정 규칙에서 확인해야 합니다. 서버가 작동하지 않거나 인증 정보가 잘못되었거나 구독에 접근할 수 없는 문제도 해결하지 못합니다.

어디에서 확인하나요: Settings에서 On Demand를 찾아 활성화된 조건과 적용 네트워크를 확인합니다. 관련 옵션은 플랫폼, 시스템 및 앱의 실제 화면에 따라 달라집니다. 현재 기기에 특정 항목이 표시되지 않는다면 다른 플랫폼의 설정 경로를 그대로 적용하거나 관계없는 스위치를 바꿔 대신하지 마세요.

설정 방법: ① On Demand를 잠시 끄고 수동으로 연결했을 때 대상에 정상적으로 접속되는지 확인합니다. ② 현재 규칙과 서버 선택을 기록합니다. ③ 필요한 조건을 켜고 한 번에 하나씩 조정합니다. ④ Wi-Fi와 셀룰러 네트워크를 전환하며 연결 상태를 확인합니다. ⑤ 원래 네트워크로 돌아가 결과가 반복되는지 확인합니다.

주의 사항: 수동으로 연결을 끊은 뒤 다시 연결된다면 스위치 고장으로 단정하지 말고 On Demand 조건을 먼저 확인하세요. 조건부 연결과 백그라운드 새로 고침은 서로 다른 설정이며, 시스템이 연결 시점을 제한할 수도 있습니다. 네트워크 이름, 네트워크 전환과 절전 모드 해제에 따라 재현 결과가 달라질 수 있으므로 문제를 확인할 때 전후의 네트워크 환경을 기록하세요.

무엇인가요: Data는 앱이 기록하는 범위의 트래픽 정보를 보여 주며 연결 활동이나 사용량 급증을 살펴보는 데 도움이 됩니다. 통계는 표시 기간, 누적 시작 시점과 앱의 실제 기록 범위에 따라 달라집니다. 기기 전체의 셀룰러 데이터 사용량으로 간주하거나 회선의 남은 데이터 용량을 확인하는 유일한 기준으로 삼지 마세요.

어디에서 확인하나요: Data를 열고 통계 항목의 이름과 현재 기간을 먼저 확인한 뒤 수치를 살펴보세요. 특정 테스트로 트래픽이 발생했는지 확인하려면 테스트 전후에 같은 항목을 확인해야 합니다. 기간, 네트워크 또는 집계 기준이 다른 수치를 단순히 빼면 유효한 결과를 얻기 어렵습니다.

확인 방법: ① 테스트 전 통계값과 시간을 기록합니다. ② 관련 없는 다운로드나 동기화 작업을 중단합니다. ③ 명확한 접속 동작을 한 번만 실행합니다. ④ Data로 돌아가 변화를 확인합니다. ⑤ 현재 라우팅 모드, 대상과 네트워크 유형을 함께 고려해 결과를 해석합니다. 통계를 초기화해야 한다면 먼저 비교 기록을 저장하고 화면에서 제공하는 초기화 방식이 무엇인지 확인하세요.

주의 사항: 트래픽이 늘었다고 해서 대상이 완전히 로드되었다고 단정할 수는 없습니다. 업로드, 재시도와 백그라운드 연결도 사용량을 늘릴 수 있습니다. 사용량이 많아 보이면 특정 규칙의 문제로 바로 판단하지 말고 시스템 백그라운드 작업, 동기화 활동과 연결 재시도를 먼저 확인하세요. 요금이나 데이터 한도를 확인할 때는 시스템의 셀룰러 데이터 기록과 사용 중인 서비스의 사용량 정보를 각각 확인하세요.

DNS: 도메인 확인 및 설정 출처

무엇이며 어디에서 설정하나요: DNS는 도메인을 주소로 변환합니다. 관련 설정은 Settings와 현재 Config에서 함께 확인해야 합니다. 이름 확인 실패와 프록시 연결 실패는 서로 다른 문제입니다. 서버 항목이 올바르더라도 대상 도메인을 확인할 수 없으면 요청이 실패할 수 있습니다.

설정 방법: ① 현재 DNS 설정과 활성화된 설정의 dns-server 값을 기록합니다. ② 지정된 DNS 서버에 현재 네트워크와 라우팅 방식으로 접속할 수 있는지 확인합니다. ③ 한 곳만 변경한 뒤 도메인 요청을 다시 보냅니다. ④ 앱에서 제공하는 진단 정보를 비교해 변화를 확인합니다. 주의: DNS, 라우팅 모드와 서버를 동시에 변경하면 어느 항목이 영향을 주었는지 확인할 수 없습니다. 사용자 지정 DNS를 사용한다고 해서 요청이 자동으로 암호화되는 것은 아니며, 캐시 때문에 변경 사항이 바로 반영되지 않을 수도 있습니다.

Test Method: 테스트 방식과 결과의 범위

무엇이며 어디에서 설정하나요: Settings의 Test Method에서는 테스트 방식을 선택하며, 선택한 방식에 따라 Connectivity Test 결과의 의미가 달라집니다. 연결 테스트와 웹 페이지 전체 로드는 서로 다른 작업입니다. 프로토콜 핸드셰이크, 대상 접속과 앱 요청도 서로 다른 단계에서 진행될 수 있습니다.

설정 방법: ① 선택 가능한 방식과 테스트 대상을 확인합니다. ② 같은 네트워크와 방식으로 여러 서버를 테스트합니다. ③ 그런 다음 실제로 사용할 대상에 접속합니다. 주의: 서로 다른 방식으로 측정한 수치를 직접 비교해 순위를 매기지 마세요. 테스트가 한 번 시간 초과되었다고 모든 요청이 실패하는 것은 아니며, 테스트 성공이 모든 웹사이트의 접속을 보장하지도 않습니다. 수치만 기록하기보다 테스트 방식과 대상 이름을 함께 기록하면 문제를 확인하기 쉽습니다.

Today Widget: 빠른 확인 및 제어

무엇이며 어디에서 설정하나요: Today Widget은 시스템 위젯 관련 설정 메뉴입니다. 실제 표시 내용과 제어 방식은 현재 시스템 및 앱에서 제공하는 옵션을 따릅니다. 상태를 빠르게 확인하거나 조작하는 기능이며, 별도의 라우팅 설정을 제공하는 것은 아닙니다.

설정 방법: ① Settings에서 Today Widget 옵션을 확인합니다. ② 시스템의 위젯 편집 메뉴에서 사용 가능한 위젯을 추가합니다. ③ Home으로 돌아가 조작 후 연결 상태를 확인합니다. 주의: 위젯 표시는 시스템의 새로 고침 일정에 따라 달라질 수 있습니다. 상태가 동기화되지 않으면 앱 내부 상태와 시스템 연결 상태를 함께 확인하고, 반복해서 눌러 상태를 바꾸지 마세요. 시스템에서 해당 위젯을 제공하지 않는다면 다른 기기의 조작 경로가 동일하다고 가정하지 마세요.

iCloud: 설정 동기화 및 기기 확인

무엇이며 어디에서 설정하나요: iCloud 동기화 옵션을 제공하는 화면에서 앱이 지원하는 항목의 동기화를 관리할 수 있습니다. 구체적인 동기화 범위는 현재 옵션 설명을 따릅니다. 동기화를 켰다고 서버, 통계, 연결 상태와 모든 시스템 권한까지 그대로 복사되는 것은 아닙니다.

설정 방법: ① 기기의 iCloud 로그인 상태와 관련 권한을 확인합니다. ② 기존 설정을 백업합니다. ③ 앱에서 지원하는 동기화 항목을 활성화합니다. ④ 다른 기기에서 파일 내용과 현재 활성화된 항목을 확인합니다. 주의: 두 기기에서 같은 설정을 동시에 수정하지 마세요. 구독 주소와 인증 정보도 민감한 정보이므로 동기화 범위를 확인한 뒤 진행해야 합니다. 동기화는 백업을 대신하지 않습니다. 파일 이름이 같아도 두 기기에서 같은 내용이 활성화되어 있다고 단정할 수 없습니다.

Diagnostics: 재현 가능한 문제 정보 수집

무엇이며 어디에서 확인하나요: Settings에서 Diagnostics를 찾아 실제 제공되는 진단 도구로 연결 관련 정보를 확인합니다. 진단 정보는 문제 범위를 좁히는 데 쓰이며, 모든 설정을 자동으로 복구하는 기능은 아닙니다.

확인 방법: ① 문제가 발생한 시간, 네트워크 유형과 Global Routing을 기록합니다. ② 구체적인 동작을 한 번만 재현합니다. ③ 해당 시간대의 오류나 결과를 확인합니다. ④ 서버, DNS와 규칙을 각각 점검합니다. 주의: 외부에 공유하기 전에 구독 자격 정보, 비밀번호, 개인 주소와 불필요한 접속 기록을 삭제하세요. 오류 한 줄만 보고 모든 설정을 변경하지 마세요. 해당 오류가 이번 실패와 같은 시간, 같은 대상에서 발생했는지 먼저 확인해야 합니다.

1. 기본 네트워크를 확인합니다. 기기의 현재 네트워크가 정상적으로 작동하는지 확인한 다음 앱에 필요한 시스템 연결 권한을 확인합니다. 기본 네트워크에 문제가 있다면 규칙을 조정해도 해결되지 않습니다.
2. 서버 항목을 확인합니다. SERVER에서 실제 선택된 항목, 프로토콜과 인증 정보를 확인합니다. 특히 구독을 업데이트한 뒤 다시 확인하세요. 목록에 항목이 있다고 해서 현재 선택되어 있는 것은 아닙니다.
3. Global Routing을 확인합니다. 평소 트래픽 분기에는 Config를 사용합니다. 비교가 필요할 때만 Proxy 또는 Direct로 잠시 전환하고 테스트가 끝나면 원래대로 되돌립니다. 결과를 비교할 수 있도록 모드와 테스트 대상을 기록하세요.
4. 설정과 DNS를 확인합니다. 현재 활성화된 파일, 규칙 순서, 정책 이름과 DNS 설정을 확인합니다. 요청이 어느 단계에서 멈췄는지 파악한 뒤 해당 항목을 수정하세요.
5. 자동 연결과 통계를 확인합니다. 마지막으로 On Demand 조건을 추가하고 Data와 Diagnostics로 상태를 확인합니다. 수동 연결이 안정적이지 않다면 자동 연결 조건을 추가하지 마세요.

‘연결은 켜지지만 인터넷에 접속할 수 없음’, ‘일부 대상만 실패함’, ‘구독 가져오기 실패’ 또는 ‘업데이트 후 문제가 발생함’이 있다면 문제 해결 매뉴얼을 참고하세요. 처음 설정하는 경우 사용 설명서의 순서에 따라 진행하세요. 영어 메뉴 이름이나 규칙 키워드를 찾으려면 용어 설명을 확인하고, 이름만 보고 설정 기능을 추측하지 마세요.