Shadowrocket Global Routing 사용법: Config·Proxy·Direct 선택 가이드

이 글의 핵심 내용

이 글은 Shadowrocket에서 연결 구성을 추가했지만 Global Routing에서 어떤 모드를 선택해야 할지 잘 모르는 사용자를 위한 안내입니다. Config의 규칙 기반 처리, Proxy의 전체 프록시 경로, Direct의 전체 직접 연결을 구분하고, 정해진 단계에 따라 새 요청이 실제로 어디로 전송되는지 확인합니다. 일상적으로는 Config를 기본으로 사용하고, Proxy와 Direct는 경로를 임시로 바꾸거나 문제 원인을 분리할 때 활용합니다. 이 모드들은 서버 설정이나 규칙 자체를 점검하는 일을 대신하지 않습니다.

1. 연결 스위치, Global Routing, 현재 구성 구분하기

Home의 연결 스위치는 Shadowrocket의 VPN 연결 여부를 결정하고, Global Routing은 연결이 트래픽을 처리할 때 요청의 경로를 정합니다. Config에서 선택한 구성은 규칙 등의 설정을 제공합니다. 세 항목은 서로 관련이 있지만 대체할 수는 없습니다. Global Routing을 Proxy로 바꿔도 연결 스위치가 켜지는 것은 아닙니다. 시스템에 VPN 표시가 보인다고 해서 모든 요청이 프록시 서버를 거친다고 단정할 수도 없습니다.

여기서 말하는 ‘전체 프록시’와 ‘전체 직접 연결’은 Shadowrocket이 처리하는 범위의 트래픽을 가리키며, 기기의 모든 통신에 예외 없이 적용된다는 뜻은 아닙니다. 라우팅 제외 설정, 로컬 네트워크 설정, DNS 처리, 기존 연결 등이 관찰 결과에 영향을 줄 수 있습니다. 전환한 뒤에는 상태 표시줄만 보지 말고 새 요청을 보내 확인하세요.

3가지

기본 모드: Config / Proxy / Direct

4가지

이 글의 규칙 예시: DOMAIN-SUFFIX / IP-CIDR / GEOIP / FINAL

2개 계층

메뉴 경로: Home → Global Routing

2. Config, Proxy, Direct의 경로와 사용 상황

직접 연결이 필요한 리소스와 프록시를 사용할 리소스에 모두 접속해야 한다면 Config를 우선 사용하세요. 단, 현재 구성의 규칙이 요구 사항에 맞아야 합니다. Config가 ‘일부 요청은 자동으로 직접 연결하고 나머지는 자동으로 프록시 처리하는’ 고정 템플릿인 것은 아닙니다. 각 도메인의 처리 방식과 마지막 기본 경로는 실제로 불러온 규칙과 정책에 따라 달라집니다.

Config: 현재 구성의 규칙에 따라 처리

권장

요청은 규칙 순서대로 확인되며, 일치하는 규칙이 DIRECT, PROXY 또는 구성에 지정된 다른 정책을 선택합니다. 앞선 규칙에 일치하지 않으면 FINAL 등의 기본 설정에 따라 경로가 정해집니다. Config를 선택한 뒤에는 의도한 파일이 Config에서 활성화되어 있는지도 확인하세요.

적합한 경우: 명확한 규칙이 있고, 장기간 목적지별로 트래픽을 분기하려는 일상적인 사용.

Proxy: 모든 요청에 프록시 경로 사용

처리 범위에 포함된 일반 요청은 모두 프록시 경로를 사용하며, 일반적인 분기 규칙에 따라 DIRECT와 PROXY를 개별 선택하지 않습니다. 사용할 수 있는 프록시 서버가 있어야 합니다. 모드를 바꿔도 잘못된 주소, 포트 또는 인증 정보가 수정되지는 않습니다.

적합한 경우: 프록시 사용 가능 여부를 잠시 확인하거나, 연결 실패가 규칙 기반 분기와 관련 있는지 판단할 때.

Direct: 모든 요청에 직접 연결 경로 사용

처리 범위에 포함된 일반 요청은 프록시 서버를 거치지 않고 전송됩니다. 이 모드는 요청의 출구 경로를 바꾸는 것이며, Shadowrocket의 VPN 연결을 끊거나 DNS 등 다른 처리를 연결 해제 상태와 완전히 동일하게 만드는 것은 아닙니다.

적합한 경우: 현재 네트워크의 직접 연결 가능 여부를 확인하거나, 로컬 네트워크 리소스를 테스트하거나, 프록시 경로의 영향을 일시적으로 제외할 때.

Proxy와 Direct는 ‘더 빠름’이나 ‘더 안정적’ 같은 등급이 아니라 비교 테스트에 쓰는 조건입니다. 프록시 경로의 사용 가능 여부는 서버와 네트워크에 달려 있고, 직접 연결 성공 여부는 현재 네트워크와 목적지 간 연결 상태에 달려 있습니다. 같은 웹페이지가 두 모드에서 다르게 작동하면 문제 해결의 단서가 되지만, 전체 구성이 정상인지 판단하는 근거가 되지는 않습니다.

3. Config의 규칙 매칭: 구체적인 규칙부터 FINAL까지

Config 모드에서는 구성에 적힌 순서대로 일반 규칙을 확인하며, 처음 일치하는 규칙이 해당 요청에 적용할 정책을 결정합니다. 따라서 범위가 좁은 예외 규칙은 대체로 범위가 넓은 규칙보다 앞에 두어야 합니다. 아래 예시는 규칙 문법과 순서를 보여 주기 위한 것으로, 완성된 연결 구성은 아닙니다. 예약된 IP 주소와 예시 도메인은 실제 사용 가능한 서비스를 뜻하지 않습니다.

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

키워드	예시에서의 역할	확인할 사항
`DOMAIN-SUFFIX`	지정한 도메인과 그 하위 도메인을 매칭합니다.	`intranet.example.com`에 적용할 예외 규칙은 더 넓은 범위의 `example.com` 규칙보다 앞에 두어야 합니다.
`IP-CIDR`	목적지 IP가 속한 네트워크 대역을 기준으로 매칭합니다.	`no-resolve`는 이 규칙을 매칭하기 위해 도메인 조회를 능동적으로 시작하지 않는다는 뜻입니다. 대상 IP가 이미 있으면 계속 매칭에 사용할 수 있습니다.
`GEOIP`	IP 지리 정보 데이터를 기준으로 매칭합니다.	IP의 지리적 분류 데이터에 의존하므로 도메인의 용도나 콘텐츠 속성을 판단하는 기준으로 사용할 수 없습니다.
`FINAL`	앞선 규칙에 일치하지 않은 요청을 처리합니다.	예시에서는 `PROXY`를 사용하므로 Config의 나머지 트래픽이 모두 직접 연결된다고 볼 수 없습니다.

도메인 규칙을 매칭하려면 사용할 수 있는 도메인 정보가 있어야 합니다. 대상 IP만 있는 경우 모든 DOMAIN-SUFFIX 규칙이 매칭될 것이라고 기대할 수는 없습니다. 문제를 확인할 때는 구성 파일에서 도메인만 검색하지 말고 연결 기록의 대상, 규칙, 최종 정책을 함께 살펴보세요. 규칙이 정책 그룹을 참조한다면 현재 선택된 출구도 확인해야 합니다.

4. 모드 전환 후 확인하는 방법

테스트할 때는 변수 하나만 바꾸세요. 네트워크, 목적지, 프록시 서버를 동일하게 유지하고 Config, Proxy, Direct를 차례로 시험합니다. 브라우저의 기존 탭은 이미 연결된 세션을 계속 사용할 수 있고, 페이지가 캐시에서 표시될 수도 있습니다. 전환 후 새로고침하는 것만으로 경로가 바뀌었다고 입증되지는 않습니다. 기존 요청을 종료하고 새로 접속한 뒤 해당 시각의 연결 기록을 확인하세요.

기준 정보 기록. Home에서 현재 서버와 연결 상태를 확인하고 Config에서 활성 파일을 확인합니다. 접근 권한이 있는 테스트 목적지 하나와 테스트 시간을 기록해 서로 다른 요청의 결과가 섞이지 않도록 하세요.
먼저 Config 테스트. Home → Global Routing → Config로 이동해 새 요청을 보냅니다. 연결 기록에서 대상, 매칭된 규칙, 적용된 정책을 확인하세요. DIRECT가 표시되면 서버를 바로 바꾸지 말고 현재 규칙에 맞는 결과인지 먼저 판단합니다.
다음은 Proxy 테스트. Home → Global Routing → Proxy로 이동합니다. 서버와 목적지는 그대로 두고 다시 요청을 보냅니다. 이때는 성공하고 Config에서는 실패한다면 규칙 매칭, 정책 그룹 선택, DNS 차이를 중점적으로 확인하세요.
마지막으로 Direct 테스트. Home → Global Routing → Direct로 이동한 뒤 같은 목적지에 다시 요청합니다. Direct에서는 성공하지만 Proxy에서는 실패한다면 프록시 연결 매개변수, 서버 상태, 프록시 경로의 DNS 문제를 확인하세요.
일상 설정으로 복원. 비교 테스트가 끝나면 Config로 돌아가 규칙 적용 결과를 다시 확인합니다. 반복해서 재현되는 현상만 문제 해결 기록에 남기고, 한 번의 성공이나 타임아웃만으로 결론 내리지 마세요.

일반 웹페이지는 HTTPS에 TCP 443을 사용하는 경우가 많고, HTTP/3는 UDP 443을 사용할 수 있습니다. 이는 목적지 서비스의 포트이지 프록시 서버 포트를 443으로 바꾸라는 뜻이 아닙니다. 브라우저는 전송 방식이 달라도 다른 방식으로 전환해 연결할 수 있으므로, 지연 시간 테스트가 성공했다고 두 전송 경로가 모두 정상인 것은 아닙니다. 서버 포트, 프로토콜, 인증 항목은 현재 사용 중인 구성과 대조해 확인하세요.

두 가지 비교 사례: 규칙을 먼저 확인할까, 프록시 경로를 먼저 확인할까

Config 실패, Proxy 성공

Config에서 올바른 파일이 활성화되어 있는지 확인합니다.
같은 목적지로 보낸 새 요청의 기록을 찾아 매칭된 규칙과 최종 정책을 확인합니다.
범위가 넓은 규칙이 먼저 매칭되는지, FINAL 설정이 예상과 일치하는지 확인합니다.

Proxy 실패, Direct 성공

Home에서 선택한 서버가 테스트 전과 동일한지 확인합니다.
주소, 포트, 인증 정보, 프로토콜 관련 항목을 확인합니다.
같은 네트워크에서 다시 시도하고 오류 유형을 기록하세요. DNS와 규칙을 동시에 수정하지 마세요.

비교 결과는 문제 범위를 좁히는 데 도움이 됩니다. 세 가지 모드에서 모두 실패한다면 네트워크 연결, DNS, 목적지 서비스 상태, 연결 기록을 차례로 확인하세요.

5. Global Routing에서 설정하지 않는 항목

Global Routing은 ‘요청이 어떤 경로를 선택할지’를 정할 뿐, 연결 매개변수를 만들거나 연결 서비스를 제공하지 않습니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 프로토콜 이름이며 Config, Proxy, Direct가 속한 결정 단계와는 다릅니다. 프로토콜 구성이 잘못되어도 모드를 바꿔 누락된 항목을 보완할 수는 없습니다.

구독 가져오기 및 업데이트: 구독은 사용 중인 서비스 제공업체에서 받아야 합니다. 업데이트는 제공업체가 게시한 연결 정보를 가져오는 데 주로 사용됩니다. 구독을 업데이트하면 로컬에서 사용하는 분기 규칙이나 Global Routing도 자동으로 원하는 상태가 된다고 가정하지 마세요.
On Demand: Settings → On Demand에서 자동 연결 조건을 확인하세요. 이 설정은 연결이 시작되는 시점에 영향을 줄 뿐, Config를 선택하거나 모든 요청이 프록시를 거치도록 보장하지 않습니다. 수동으로 연결을 끊어 테스트할 때는 자동 연결 조건이 다시 연결을 시작하지 않는지도 확인하세요.
DNS: 도메인 조회와 출구 정책은 서로 관련이 있지만 같은 스위치는 아닙니다. 모드를 바꾼 뒤에도 조회에 실패한다면 Global Routing만 반복해서 전환하지 말고 DNS 설정을 별도로 확인하세요.
앱 구매: 앱의 일회성 구매는 회선 요금제가 아닙니다. Shadowrocket은 Apple 플랫폼 전용 상용 앱이며, App Store에서만 받을 수 있습니다. 가격, 시스템 요구 사항, 구매 적용 범위는 App Store 페이지 표기를 기준으로 확인하세요.

처음 연결할 때는 시스템 안내에 따라 VPN 구성 추가를 허용해야 합니다. 이 권한은 시스템 연결 권한일 뿐, 현재 프록시에 접속할 수 있거나 규칙이 검증되었다는 뜻은 아닙니다. 먼저 권한을 허용하고 연결 상태를 확인한 다음, 앞 절의 방법으로 항목별 테스트를 진행해야 권한 문제, 매개변수 문제, 트래픽 분기 문제를 구분할 수 있습니다.

6. 모드 전환 시 자주 묻는 질문 4가지

Config를 선택했는데 왜 특정 웹사이트는 직접 연결되나요?

먼저 Config에서 활성 파일을 확인하고, 해당 웹사이트에 대한 새 요청이 어떤 규칙에 매칭됐는지 살펴보세요. DOMAIN-SUFFIX, GEOIP 또는 FINAL이 DIRECT를 지정했거나 정책 그룹에서 직접 연결을 선택했을 수 있습니다. Global Routing에 Config가 표시된다는 사실만으로 해당 웹사이트가 프록시를 사용해야 한다고 단정할 수는 없습니다.

Proxy로 바꾼 뒤 접속되면 규칙이 잘못된 건가요?

두 모드에서 경로가 달랐다는 뜻이지만, 그렇다고 특정 규칙 한 줄의 문법이 틀렸다고 바로 결론 내릴 수는 없습니다. 같은 서버와 네트워크를 유지한 채 Config에서 매칭된 규칙, 정책 그룹의 출구, DNS 조회 결과를 비교하세요. 차이를 찾은 다음 해당 설정을 수정하세요.

Direct인데 VPN 표시가 계속 보이면 전환에 실패한 건가요?

VPN 표시는 시스템 터널이 여전히 연결되어 있다는 뜻이지, 출구가 반드시 프록시 서버를 거친다는 뜻은 아닙니다. Direct는 라우팅 모드이며, 연결을 끊으려면 Home의 연결 스위치를 꺼야 합니다. 연결을 끊은 뒤 자동으로 다시 연결되면 Settings → On Demand를 확인하세요.

전환했는데 기존 웹페이지가 달라지지 않아요. 어떻게 확인하나요?

기존 페이지의 요청을 먼저 중지한 뒤 다시 접속하고, 같은 시각의 새 연결 기록을 확인하세요. 장기 연결의 영향을 배제하려면 연결을 끊었다가 다시 연결해 볼 수도 있습니다. 테스트 중에는 Global Routing만 바꾸고 서버, 규칙 파일, DNS는 함께 변경하지 마세요. 그래야 결과를 비교할 수 있습니다.

일상적인 사용은 다음 순서로 정리할 수 있습니다. 먼저 연결과 구성을 확인한 뒤 Config로 사용합니다. 문제가 생기면 Proxy와 Direct로 비교하고, 원인을 찾은 다음 Config로 복원해 새 요청으로 규칙을 확인합니다. 이 방법은 트래픽 분기 설정을 유지하면서 임시 점검용 모드가 기기에 계속 남는 일을 방지합니다.