Shadowrocket 프록시 모드 및 설정 방법 - Shadowrocket 지원

Global Routing: 트래픽 처리 방식 선택

Global Routing은 트래픽을 처리할 방식을 정하며, 잘못된 서버 매개변수를 수정하지는 않습니다. 처음 사용할 때는 보통 Config를 선택해 현재 구성 파일의 규칙에 따라 요청별로 PROXY, DIRECT 또는 REJECT를 적용합니다. 비교 테스트가 필요할 때만 Proxy 또는 Direct로 잠시 전환하세요. 세 모드는 각각 구성, 프록시, 직접 연결을 뜻하며 앱의 메뉴 이름은 Config, Proxy, Direct로 표시됩니다.

경로: Home을 열고 Global Routing으로 이동해 현재 선택 항목을 확인합니다. 모드를 바꾼 뒤 Home으로 돌아와 선택된 서버와 연결 스위치를 확인하고 다시 접속해 보세요. 모드 이름이 바뀌었다고 기존 연결이 새 방식으로 다시 설정된 것은 아닙니다. 테스트할 때는 대상 앱의 기존 연결을 끊거나 대상 페이지를 새로 여세요.

세 가지 모드의 용도와 확인 사항
화면의 옵션	처리 방식	사용 상황	주의 사항
Config(구성)	현재 활성화된 Config의 규칙과 정책에 따라 처리합니다.	일상적으로 도메인, IP 등의 조건에 따라 트래픽을 분기할 때 사용합니다.	규칙 순서, 정책 이름, FINAL을 확인하세요. 서버만 점검해서는 안 됩니다.
Proxy(프록시)	프록시로 전달되는 요청을 현재 선택된 프록시로 처리합니다.	Config와 비교해 규칙 분기가 차이를 일으키는지 확인할 때 사용합니다.	서버를 사용할 수 없다면 Proxy로 바꿔도 문제가 해결되지 않습니다.
Direct(직접 연결)	프록시가 처리하는 요청을 직접 연결 방식으로 처리합니다.	현재 네트워크 자체의 연결 상태를 비교할 때 사용합니다.	연결 스위치를 끄는 것과 같지 않으며, 모든 앱의 연결 경로를 보장하지도 않습니다.

선택 방법: 같은 대상이 Proxy에서는 열리지만 Config에서는 열리지 않는다면, 바로 프로토콜을 바꾸기보다 해당 대상에 어떤 규칙이 적용됐는지 먼저 확인하세요. 원래 직접 연결되어야 하는 대상이 Direct에서도 열리지 않으면 Wi-Fi, 셀룰러 네트워크, 대상 서비스 상태를 확인합니다. 비교를 마친 뒤에는 원래 사용하던 Config로 되돌려 임시 점검 설정을 계속 사용하지 않도록 하세요.

규칙 분기: 매칭 조건과 처리 정책

규칙은 ‘무엇을 매칭할지’와 ‘매칭 후 어떻게 처리할지’로 구성됩니다. DOMAIN, DOMAIN-SUFFIX 등은 매칭 유형이고 PROXY, DIRECT, REJECT는 정책입니다. 앞부분은 대상 범위를 지정하고 뒷부분은 처리 결과를 정하므로 서로 혼동하지 마세요. 규칙은 일반적으로 순서대로 확인합니다. 구체적인 예외 규칙은 범위가 넓은 규칙보다 앞에 두고, 매칭되지 않은 트래픽의 최종 처리를 담당하는 FINAL은 마지막에 둡니다.

경로: Config로 이동해 현재 사용 중인 구성 파일을 확인한 다음, 해당 파일의 편집 화면에서 규칙을 살펴봅니다. 저장하기 전에 복원할 수 있도록 사본을 보관하세요. 저장 후에는 해당 파일이 계속 활성화되어 있는지, Global Routing이 Config로 설정되어 있는지 확인합니다. 활성화되지 않은 파일만 수정하면 현재 트래픽 분기에는 변화가 없습니다.

규칙 유형	매칭 대상	적용 범위 및 주의 사항
`DOMAIN`	전체 도메인 이름입니다.	특정 호스트 이름 하나만 처리할 때 적합합니다.
`DOMAIN-SUFFIX`	지정한 도메인과 하위 도메인입니다.	접미사 매칭 범위를 확인해 관련 없는 트래픽에 영향을 주지 않도록 하세요.
`DOMAIN-KEYWORD`	도메인에 포함된 키워드입니다.	매칭 범위가 넓어 예상하지 못한 도메인이 포함될 수 있습니다.
`IP-CIDR / IP-CIDR6`	IPv4 / IPv6 주소 대역입니다.	주소 대역 매칭은 도메인 매칭과 다릅니다.
`GEOIP`	IP 지리 데이터베이스의 분류를 기준으로 합니다.	데이터베이스 분류에 의존하므로 서비스의 실제 소속 지역과 일치한다고 보장할 수 없습니다.
`USER-AGENT`	식별 가능한 User-Agent 정보입니다.	요청에서 확인할 수 있는 정보에 한정되므로 모든 암호화 연결을 식별하는 방법으로 볼 수 없습니다.
`FINAL`	앞선 규칙에 매칭되지 않은 트래픽입니다.	최종 정책이 예상한 대로 설정되어 있는지 확인하세요.

간단한 예시로 규칙 순서 이해하기

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

아래 예시는 문법 설명용입니다. 먼저 example.com과 하위 도메인에 매칭해 PROXY를 적용하고, 다음으로 GEOIP 조건에 맞는 주소에는 DIRECT를 적용하며, 나머지 트래픽은 FINAL로 처리합니다. 완전한 구성 파일이 아니며 사용할 수 있는 서버 정보도 포함하지 않습니다. PROXY의 실제 연결 대상은 현재 서버 또는 구성에 지정된 정책 선택에 따라 달라집니다. REJECT는 매칭된 요청을 거부하는 정책이지, 다른 연결 방식이 아닙니다.

주의: 대상 서비스는 여러 도메인, 주소 또는 연결 프로토콜을 사용할 수 있습니다. 메인 페이지는 열리지만 일부 리소스가 실패한다면 실패한 요청의 실제 대상을 확인한 뒤 필요한 규칙을 추가하세요. 한 도메인 문제를 해결하려고 범위가 넓은 DOMAIN-KEYWORD 규칙을 모든 규칙보다 앞에 두지 마세요. 출처를 알 수 없는 규칙 파일 전체를 기존 구성에 그대로 덮어쓰는 것도 피하세요.

Subscribe 및 서버 관리

Subscribe는 여러 서버 정보를 가져와 업데이트하는 기능이며, 개별 Add Server 항목에는 서버의 프로토콜과 연결 매개변수를 저장합니다. 두 기능 모두 Config와는 다릅니다. 구독을 가져왔다고 특정 규칙을 사용 중이라는 뜻은 아니며, Config를 선택했다고 서버 매개변수가 준비된 것도 아닙니다. 문제를 확인할 때는 ‘현재 서버’와 ‘현재 구성 파일’을 따로 점검하세요.

경로: Home 오른쪽 위의 +를 누르고 Add Server로 이동합니다. Type에서 Subscribe를 선택한 뒤 이용 중인 서비스 제공업체에서 받은 링크를 붙여넣고 저장하세요. 업데이트가 끝나면 Home의 SERVER 목록으로 돌아가 사용할 항목을 선택합니다. 서버를 하나씩 추가할 때는 해당 Type을 선택하고 보유한 정보를 바탕으로 주소, 포트, 인증 매개변수를 입력하세요. 사용할 QR 코드가 있다면 Scan QR Code를 이용할 수 있습니다.

설정 방법: 프로토콜은 서비스 제공업체가 안내한 매개변수와 일치해야 합니다. Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, Hysteria2는 입력 항목이 서로 다르므로 Type만 바꾸고 이전 프로토콜의 매개변수를 그대로 사용하지 마세요. 전송 방식, TLS, 서버 이름 등의 정보는 제공된 안내에 따라 하나씩 확인하고 포트 번호만으로 설정을 추측하지 마세요.

구독을 업데이트한 뒤 목록이 실제로 새로 고쳐졌는지 확인한 다음 Connectivity Test를 실행하세요. 업데이트 실패와 서버 연결 실패는 별개의 문제입니다. 전자는 구독 링크에 접속할 수 없거나 응답 내용이 예상과 다를 때 발생할 수 있고, 후자는 실제 서버 연결과 관련됩니다. 정보를 보관하기 전에 항목 전체를 반복해서 삭제하지 마세요. 확인에 필요한 매개변수의 마지막 사본을 잃을 수 있습니다.

주의: 구독 링크, QR 코드, 서버 상세 정보에는 인증 정보가 포함될 수 있으므로 공개하지 마세요. 구독을 새로 고치면 항목에 수동으로 적용한 변경 사항이 덮어써질 수도 있습니다. 데이터가 구독으로 관리되는지 직접 관리되는지 먼저 확인하세요. 문제를 설명할 때는 프로토콜 이름, 오류 유형, 필요한 설정 상태만 공유하고 링크와 인증 항목은 숨기세요.

On Demand: 조건에 따라 연결 시작

On Demand는 설정한 조건에 따라 시스템이 연결을 시작하도록 합니다. 연결 시점을 관리하는 기능으로, Config의 규칙 분기를 대체하거나 서버의 사용 가능 여부를 바꾸지는 않습니다. 먼저 수동으로 안정적인 연결을 확인한 뒤 자동 연결을 활성화하세요. 그렇지 않으면 시스템의 자동 재연결 때문에 실제 실패 지점이 가려져 문제를 파악하기 어려울 수 있습니다.

경로: 앱에서 Settings로 이동해 On Demand 관련 설정을 찾습니다. 현재 표시된 조건과 동작을 먼저 확인한 뒤 사용 환경에 맞게 활성화하거나 조정하세요. 시스템과 앱에 따라 선택 항목이 다를 수 있으므로 현재 화면에 표시된 항목을 기준으로 삼고, 다른 기기에 있는 옵션이 이 기기에도 있다고 가정하지 마세요.

설정 방법: 평소에 자동으로 연결을 시작하려는지, 특정 네트워크 환경에서만 연결하려는지 먼저 정하세요. 설정을 마친 뒤 자주 사용하는 Wi-Fi와 셀룰러 네트워크에서 각각 확인합니다. 네트워크를 바꾼 후 연결이 설정될 때까지 기다리고 앱의 연결 상태를 점검하세요. 수동으로 연결을 끈 뒤 다시 연결된다면 스위치를 계속 반복해서 조작하기보다 On Demand가 여전히 적용 중인지 먼저 확인하세요.

주의: 자동 연결을 사용한다고 모든 요청이 프록시를 거치는 것은 아닙니다. 실제 처리는 여전히 Global Routing과 Config에 따라 결정됩니다. 조건을 통제해 반복 테스트해야 한다면 On Demand를 잠시 끄고 연결 스위치를 수동으로 조작하세요. 점검이 끝나면 원래 설정을 복원하고 결과에 영향을 줄 수 있는 다른 네트워크 설정이 동시에 활성화되어 있지 않은지 확인합니다.

Data: 트래픽 확인, 요금 기록과는 별개

Data에서는 클라이언트가 확인할 수 있는 트래픽 통계를 볼 수 있습니다. 테스트 중 데이터 전송이 있었는지, 업로드와 다운로드가 달라졌는지 확인하는 데 유용합니다. 연결 동작을 점검할 때 참고할 수 있지만 서비스 제공업체 계정의 잔여 데이터와 같지는 않으며, 전체 사용량만으로 각 대상에 어떤 규칙이 적용됐는지도 알 수 없습니다.

경로: 연결하기 전에 Data를 열어 표시된 통계 범위와 수치를 기록합니다. 명확한 대상에 한 번 접속한 뒤 Data로 돌아와 변화를 비교하세요. 통계 기간이나 초기화 항목이 있다면 먼저 그 의미를 확인합니다. 문제를 추적할 근거를 남겨야 한다면 초기화하기 전에 수치를 기록해 비교 기준을 보존하세요.

사용 방법: 테스트 중에는 백그라운드 다운로드, 클라우드 동기화, 다른 앱의 활동을 최대한 줄이세요. 새로 발생한 트래픽이 점검 중인 대상에서 나온 것인지 알기 어려울 수 있습니다. 페이지 로딩에 실패해도 DNS 요청, 핸드셰이크, 재시도로 트래픽이 발생할 수 있습니다. 반대로 캐시된 페이지를 열면 수치 변화가 거의 없을 수 있습니다. Data는 실제 요청, 연결 상태, 진단 기록과 함께 판단하세요.

주의: 클라이언트와 서비스 제공업체는 통계 범위, 갱신 시점, 측정 기준이 서로 다를 수 있습니다. 사용량 한도는 본인의 서비스 제공업체 기록에서 확인하세요. Data에 표시된 숫자 하나만으로 청구 내역을 판단하지 마세요. 한 번의 접속이 PROXY와 DIRECT 중 어느 방식으로 처리됐는지 확인하려면 현재 모드와 관련 요청 기록을 살펴봐야 합니다. 트래픽 증가량을 규칙 적용의 근거로 대신할 수는 없습니다.

Settings: 자주 쓰는 항목 확인

Settings의 각 항목은 서로 다른 역할을 합니다. DNS는 도메인 이름 해석에 영향을 주고, Test Method는 테스트 방식을 정하며, Today Widget은 시스템에서 빠르게 확인하는 기능을 제공하고, iCloud 옵션은 지원되는 항목을 클라우드에 동기화합니다. 이 설정들은 연결 성능을 한꺼번에 높여 주는 공통 스위치가 아닙니다. 변경 전에 기존 값을 기록하고, 변경 후에는 해당 항목과 관련된 결과만 확인하세요.

DNS: 이름 해석과 연결을 구분하기

기능: DNS는 도메인 이름을 IP 주소로 변환합니다. 도메인 이름 해석에 성공해도 대상에 연결된 것은 아니며, 주소로 연결할 수 있어도 도메인 해석 경로가 올바르다는 뜻은 아닙니다. 위치: 먼저 Settings에서 DNS 관련 메뉴를 확인한 다음 현재 Config에 DNS 설정이 있는지 살펴보세요. 실제 적용 방식은 현재 구성과 연결 모드를 함께 고려해야 합니다.

설정 방법: 이미 정상 작동을 확인한 설정은 유지하고, 명확한 도메인 해석 오류가 있을 때만 변경하세요. 기존 구성에 지정된 DNS 매개변수를 사용할 경우 주소 형식과 연결 가능 여부를 확인하고 여러 구성의 옵션을 임의로 섞지 마세요. 주의: 도메인으로 접속할 때와 IP 주소로 직접 접속할 때의 차이는 단서일 뿐입니다. HTTPS 인증서, 서버 이름, 콘텐츠 전송 방식도 결과에 영향을 주므로 이 차이만으로 DNS 오류라고 단정할 수 없습니다.

Test Method: 동일한 기준으로 테스트하기

기능: Test Method는 Connectivity Test의 테스트 방식을 정합니다. 위치: Settings에서 Test Method를 찾아 현재 선택 항목을 확인한 뒤 Home으로 돌아가 Connectivity Test를 실행하세요. 테스트 방식에 따라 확인하는 연결 단계가 다를 수 있으므로 결과를 같은 기준으로 비교해야 합니다.

설정 방법: 같은 네트워크, 같은 서버, 같은 Test Method를 사용해 반복 테스트한 다음 실제 접속을 확인하세요. 테스트 관련 매개변수를 바꿨다면 변경 전후의 조건을 기록합니다. 주의: 테스트 통과는 해당 테스트 조건이 충족됐다는 뜻일 뿐, 모든 웹사이트와 앱이 정상 작동한다는 보장은 아닙니다. 실패했을 때도 선택한 방식에 따라 결과를 판단하고, 한 번의 결과만으로 서버를 삭제하지 마세요.

Today Widget: 빠른 조작 후 앱에서 상태 확인

기능: Today Widget은 시스템에서 빠르게 확인하거나 조작하는 기능이며, 사용 가능한 형태는 시스템과 앱의 지원 여부에 따라 다릅니다. 위치: Settings에서 관련 설정을 확인한 다음 시스템의 위젯 편집 화면에서 해당 항목을 제공하는지 살펴보세요. 표시되지 않는다면 다른 시스템의 화면을 기준으로 억지로 찾지 말고 이 기기에서 사용할 수 있는 항목을 확인하세요.

설정 방법: 이 기기의 화면에서 사용할 수 있는 위젯을 추가하고 처음 조작한 뒤 앱을 열어 연결 상태와 선택된 서버를 확인하세요. 주의: 위젯 정보는 일정 간격으로 갱신될 수 있으므로 Home에서의 전체 확인을 대신하지 않습니다. 위젯으로 연결을 빠르게 켜도 Global Routing이나 Config가 자동으로 원하는 값으로 바뀌지는 않습니다.

iCloud: 동기화 범위와 기기별 설정을 따로 확인

기능: iCloud 관련 기능은 지원되는 기기 환경에서 앱이 제공하는 항목을 동기화하거나 저장합니다. 위치: 먼저 시스템에서 현재 Apple 계정과 iCloud의 앱 권한을 확인한 뒤 Shadowrocket의 Settings에서 동기화 옵션을 살펴보세요. 구체적으로 어떤 항목이 동기화되는지는 앱 내 설명을 확인하세요.

설정 방법: 동기화하기 전에 현재 구성을 보관하고 어느 기기의 내용을 기준으로 삼을지 정한 다음 다른 기기에서 실제로 동기화된 항목을 확인하세요. 주의: 모든 설정, 인증 정보, 연결 상태가 동기화된다고 가정하지 마세요. iCloud 콘텐츠 동기화는 App Store 구입 항목 복원과 다르며, Windows, Android, Linux에서도 같은 데이터가 자동으로 제공된다는 뜻이 아닙니다.

Diagnostics: 단계별로 문제 찾기

Diagnostics는 문제 해결을 위한 단서를 수집하고 확인하는 기능이지, 모든 연결 문제를 자동으로 해결하는 스위치가 아닙니다. Settings에서 Diagnostics 또는 관련 진단 메뉴를 찾은 뒤 재현할 현상을 먼저 정하고 새로운 테스트 기록을 생성하세요. 시스템별로 진단 항목이 다를 수 있으므로 내용을 저장하기 전에 현재 화면의 안내를 읽어 보세요.

네트워크와 상태를 기록합니다. Wi-Fi와 셀룰러 네트워크 중 무엇을 사용 중인지, 연결 스위치가 켜져 있는지, Global Routing이 Config, Proxy, Direct 중 무엇인지, 선택한 서버의 프로토콜이 무엇인지 적어 두세요. 인증 정보는 기록하거나 공개할 필요가 없습니다.
최소한의 테스트를 진행합니다. Connectivity Test를 한 번 실행한 뒤 명확한 대상 하나에 접속해 보세요. 테스트 시간과 오류 메시지를 기록하고, 여러 앱을 동시에 열어 서로 연관 짓기 어려운 백그라운드 요청이 기록에 쌓이지 않도록 합니다.
조건은 하나씩 바꿉니다. 예를 들어 먼저 Config와 Proxy를 비교하세요. 차이가 분명하다면 규칙을 확인합니다. 서버 연결 자체가 실패했다면 매개변수와 로컬 네트워크를 점검하고 DNS, 프로토콜, 전송 설정을 한꺼번에 변경하지 마세요.
기록을 함께 살펴봅니다. 오류가 도메인 해석, 연결, TLS, 요청 처리 중 어느 단계에서 발생했는지 확인하세요. 명확한 오류 메시지가 있다면 원문을 보존합니다. 시간 초과가 발생해도 테스트 대상에 접속할 수 없는 것인지 서버 연결이 설정되지 않은 것인지 구분해야 합니다.
평소 설정으로 복원합니다. 점검을 마치면 필요한 Config와 On Demand 설정을 되돌리고 진단을 위해서만 켠 추가 기록을 끄세요. 임시 비교 설정이 현재 선택된 채로 남아 있지 않은지도 확인합니다.

개인정보에 유의하세요: 진단 데이터에는 접속한 도메인, 서버 주소, 구독 정보가 포함될 수 있습니다. 다른 사람에게 보내기 전에 인증 매개변수, 전체 구독 링크, 문제와 무관한 접속 기록을 숨기세요. 전체 내보내기 파일을 그대로 공개하지 마세요. 문제를 설명할 때 재현 단계, 설정 항목 이름, 오류 원문을 제공하면 ‘연결할 수 없음’이라고만 알리는 것보다 원인을 좁히기 쉽습니다.

자주 묻는 설정 문제

Config를 선택했는데 트래픽이 예상대로 분기되지 않는 이유는 무엇인가요?

먼저 Config 화면에서 실제로 활성화된 파일을 확인한 다음 대상에 적용되는 규칙과 순서를 점검하세요. 먼저 일치한 규칙이 있으면 뒤의 규칙은 더 이상 검사되지 않을 수 있습니다. PROXY 또는 사용자 지정 정책에 연결된 서버 선택도 확인하세요. 새 요청을 다시 보내 결과를 살펴보고 기존 연결로 새 구성을 판단하지 마세요.

연결을 끈 뒤 자동으로 다시 연결된다면 무엇을 확인해야 하나요?

먼저 On Demand와 시스템의 관련 연결 설정을 확인하세요. 자동 연결을 잠시 끈 뒤 연결 스위치를 수동으로 한 번 전환해 점검합니다. Direct는 트래픽 처리 모드이지 연결을 끄는 기능이 아니므로 혼동하지 마세요.

Connectivity Test는 성공했는데 대상 페이지가 열리지 않는 이유는 무엇인가요?

테스트 성공은 선택한 Test Method의 테스트 조건이 충족됐다는 뜻입니다. 대상 도메인 해석, 적용된 규칙, TLS 매개변수, 대상 서비스 상태를 계속 확인하세요. 같은 서버에서 Config와 Proxy 결과를 비교하면 규칙 문제와 서버 연결 문제를 구분하는 데 도움이 됩니다.

구독을 업데이트하면 Config도 함께 변경되나요?

두 항목을 같은 데이터로 보면 안 됩니다. Subscribe는 주로 서버 정보를 관리하고 Config는 구성과 규칙을 관리합니다. 구독 업데이트 후 SERVER 목록과 현재 Config를 각각 확인해 실제 변경 내용을 살펴보세요. 화면에 표시된 내용과 현재 적용 중인 설정을 기준으로 판단하세요.