Shadowrocket Global Routing 설정 방법: Config·Proxy·Direct 차이와 사용법

이 글의 핵심

이용 중인 서비스와 구독이 있고 Shadowrocket에서 트래픽 분산 방식을 선택하려면, 먼저 서버가 정상적으로 작동하는지 확인한 다음 Global Routing을 설정하세요. 평소에는 규칙을 확인한 Config를 우선 사용하고, Proxy는 임시로 모든 트래픽을 프록시 처리하거나 규칙 문제를 비교 진단할 때, Direct는 직접 연결을 확인할 때 사용합니다. 이 글에서는 각 모드의 차이와 전환 방법, 규칙 확인 절차를 설명하고 Scene과 On Demand를 구분해 연결 스위치, 라우팅 모드, 자동 연결을 혼동하지 않도록 안내합니다.

먼저 결론: 일상적인 기본값은 Config

Global Routing은 Shadowrocket이 처리하는 트래픽의 경로를 정합니다. 서비스를 생성하거나 작동하지 않는 서버 설정을 복구하는 기능은 아닙니다. 일부 연결은 직접 접속하고 나머지는 프록시를 통해 연결하려면, 현재 구성 파일의 규칙과 최종 매칭 항목이 목적에 맞는지 확인한 뒤 Config를 선택하세요. Config가 가장 빠른 경로를 자동으로 고르거나 모든 트래픽을 예상대로 분산하는 것은 아닙니다.

Config

Proxy

처리 범위에 들어온 트래픽을 모두 프록시 모드로 처리합니다. Config의 일반적인 트래픽 분산 규칙에 따라 DIRECT 또는 프록시를 하나씩 선택하지 않습니다. DNS와 시스템 수준의 동작은 별도로 확인해야 합니다.

적합한 경우: 임시로 모든 트래픽을 프록시 처리하거나 Config와 비교해 규칙 문제의 범위를 좁힐 때.

Direct

처리 범위에 들어온 트래픽을 직접 연결합니다. 선택한 프록시 서버를 거치지 않습니다. 이는 라우팅 모드이며 Shadowrocket 연결 스위치를 끄는 것과는 다릅니다.

적합한 경우: 현재 Wi-Fi 또는 셀룰러 네트워크의 직접 접속 가능 여부를 확인할 때.

여기서는 기본 모드 세 가지를 비교하며 Global Routing의 모든 옵션을 다루지는 않습니다. 화면에 Scene이 표시된다면, 이는 장면 조건에 따라 처리 방식을 선택하는 기능입니다. 문제를 진단할 때는 현재 장면과 설정을 확인하고, Scene을 Config의 다른 이름으로 여기지 마세요.

Home에서 모드 전환하기: 다른 조건은 그대로 유지

Home에서는 현재 서버와 연결 상태를 확인하고, Config에서는 구성 파일을 관리하며, Settings에서는 앱 설정을 조정합니다. Home의 Global Routing에서 Config를 선택하는 것과 Config 화면에서 파일을 선택하는 것은 별개의 작업입니다. 라우팅 모드와 적용 중인 파일을 모두 확인해야 요청에 어떤 규칙이 적용되는지 알 수 있습니다.

서버 확인

Home을 열고 현재 이용 중인 서비스에서 테스트할 서버가 선택되어 있는지 확인합니다. 주소, 포트, 인증 정보, 프로토콜 매개변수를 먼저 점검하고, 모드를 바꾸는 동시에 서버까지 변경하지 마세요.
구성 파일 확인

Config로 이동해 현재 사용 중인 구성 파일을 확인합니다. 수정하기 전에는 기존 내용을 보존하세요. 서버 구독을 가져오거나 갱신해도 새로운 트래픽 분산 구성이 자동으로 선택되는 것은 아닙니다.
모드 선택

Home → Global Routing으로 돌아가 Config, Proxy 또는 Direct를 선택한 다음 Home에서 선택 결과를 확인합니다. 이전에 사용한 설정을 기억에만 의존하지 마세요.
요청 다시 보내기

연결 스위치 상태를 확인한 뒤 테스트 앱에서 대상 페이지를 다시 엽니다. 필요하면 기존 연결을 종료하거나 Shadowrocket에 다시 연결해 이전 세션 때문에 전환 결과를 잘못 판단하지 않도록 하세요.
기록하고 원래 설정으로 복구

네트워크 유형, 모드, 서버, 페이지 결과를 기록합니다. 비교가 끝나면 Home → Global Routing → Config로 돌아가 일상적으로 사용하는 구성 파일이 적용되어 있는지 확인하세요.

Config의 핵심: 규칙 순서와 FINAL

Config는 구성 파일의 규칙에 따라 요청을 처리하며, 일반적으로 위에서 아래로 내려가며 일치 항목을 찾습니다. 같은 대상이 도메인 조건과 주소 조건에 모두 해당할 수 있으므로 구체적인 규칙을 앞에, 범위가 넓은 규칙을 뒤에 배치해야 합니다. 그래야 앞의 포괄적인 규칙이 요청을 먼저 처리하는 일을 막을 수 있습니다. FINAL은 기본 처리 항목이며, 앞선 결과를 다시 확인하는 기능이 아닙니다.

DOMAIN-SUFFIX

도메인 접미사로 매칭

IP-CIDR

IPv4 주소 대역으로 매칭

GEOIP

IP 지리 데이터베이스로 매칭

FINAL

앞선 규칙에 매칭되지 않은 요청 처리

아래는 규칙 순서를 이해하기 위한 예시이며 완전한 구성 파일이 아닙니다. 예시 도메인 example.com은 문법 설명용입니다. PROXY에 해당하는 정책을 실제 구성에서 확인할 수 있어야 합니다. 다른 정책 이름을 사용하는 경우 구성에 이미 정의된 이름으로 바꾸세요. 그대로 붙여 넣은 뒤 작동한다고 가정하지 마세요.

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

DOMAIN-SUFFIX,example.com,PROXY: 해당 도메인과 하위 도메인을 PROXY 정책으로 보냅니다. 이름이 비슷한 다른 도메인까지 자동으로 포함하지는 않습니다.
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve: 지정한 주소 대역에 직접 연결합니다. no-resolve는 이 주소 규칙을 매칭하기 위해 별도의 도메인 조회를 유발하지 않는다는 뜻입니다.
GEOIP,CN,DIRECT: 사용 가능한 IP 지리 데이터베이스를 바탕으로 대상 IP의 지역을 판단합니다. 브랜드나 도메인 접미사를 기준으로 판단하는 것은 아닙니다.
FINAL,PROXY: 앞선 규칙에 매칭되지 않은 요청을 PROXY로 보냅니다. FINAL,DIRECT로 작성하면 기본 처리 방식이 달라집니다.

따라서 “Config를 선택하면 나머지 트래픽은 모두 직접 연결된다”는 말은 맞지 않습니다. 나머지 트래픽의 처리 방식은 FINAL을 확인해야 합니다. 웹사이트 하나를 진단할 때는 페이지가 여러 도메인에 요청을 보낼 수 있다는 점도 고려하세요. 메인 페이지가 한 규칙에 매칭되더라도 이미지, 로그인 API, 기타 리소스가 같은 규칙에 매칭된다는 보장은 없습니다.

Proxy와 Direct: 비교 가능한 테스트 방법

모드 전환은 문제의 범위를 좁히기 위한 것이지, 한 번의 성공으로 전체 구성이 올바르다고 증명하는 방법은 아닙니다. 같은 기기, 같은 네트워크, 같은 서버로 같은 대상에 접속하고, 매 회차 설정 하나만 변경하세요. 테스트 도중 구독을 갱신하거나 DNS를 바꾸고 규칙까지 편집하면 결과에 영향을 준 항목을 구분할 수 없습니다.

비교 방법: 대상을 고정하고 Global Routing만 변경

Proxy 비교

기존 서버를 그대로 두고 Home → Global Routing → Proxy로 전환합니다.
실패했던 페이지에 다시 요청을 보내고, 페이지가 열리는지와 구체적인 오류를 기록합니다.
Proxy에서는 성공하고 Config에서는 실패한다면, 규칙 매칭, 정책 선택, DNS 차이를 먼저 확인하세요.

Direct 비교

같은 네트워크에서 Home → Global Routing → Direct로 전환합니다.
현재 네트워크에서 직접 접속할 수 있어야 하는 대상을 선택해 요청을 다시 보냅니다.
Direct에서는 성공하고 Proxy에서는 실패한다면, 서버 연결과 프록시를 통한 대상 접속 상태를 먼저 확인하세요.

비교 결과는 문제를 진단할 방향을 제시할 뿐입니다. 테스트가 끝나면 Config로 복구하고 새 요청을 보내 일상적인 트래픽 분산을 다시 확인하세요.

관찰된 현상	다음 확인 사항
Proxy는 되지만 Config는 안 됨	대상에 매칭된 규칙, 규칙이 참조하는 정책, FINAL을 확인하세요. 서버 장애라고 단정하지 마세요.
Direct는 되지만 Proxy는 안 됨	서버 주소, 포트, 인증 정보, 필요한 전송 매개변수를 확인한 다음 대상이 해당 출구를 거부하는지도 살펴보세요.
세 가지 모드 모두 안 됨	먼저 기본 네트워크와 대상 사이트의 상태를 확인한 다음 DNS 조회를 점검하세요. 필요하면 연결 스위치를 끈 상태에서도 추가로 비교해 보세요.
전환 후에도 기존 페이지가 그대로 표시됨	연결을 다시 시작해 캐시와 이전 세션의 영향을 배제하세요. 설정을 빠르게 연속 전환한 뒤 페이지에 남아 있는 내용만 보고 판단하지 마세요.

표의 내용은 조건에 따른 점검 방향이며, 이 사이트에서 직접 측정한 결과가 아닙니다. Direct도 앱 내부 DNS 설정의 영향을 받을 수 있으므로 Direct 실패만으로 Wi-Fi 또는 셀룰러 네트워크가 끊겼다고 단정할 수 없습니다. 연결 스위치를 끈 테스트는 별도의 조건으로 기록하세요.

DNS, Scene, On Demand 구분하기

Global Routing은 “요청을 어떤 경로로 보낼지”, DNS는 “도메인을 어떻게 조회할지”, On Demand는 “어떤 조건에서 연결을 시작할지”를 다룹니다. 서로 관련은 있지만 대체할 수는 없습니다. 예를 들어 Proxy로 바꿔도 잘못된 DNS 설정이 자동으로 수정되지는 않으며, Config를 유지한다고 시스템이 자동으로 연결을 시작하는 것도 아닙니다.

DNS: 먼저 도메인 조회가 가능한지 확인한 다음 대상 연결의 경로를 살펴보세요. 주소 규칙의 매칭 여부는 요청에 사용된 주소와 관련 조회 동작에도 달려 있으므로 규칙의 문구만 확인해서는 안 됩니다.
Scene: Home → Global Routing → Scene을 사용한다면 선택된 장면과 조건을 추가로 확인하세요. 결과를 명확하게 비교하려면 Config, Proxy 또는 Direct를 일시적으로 직접 선택하고, 테스트 후 Scene 설정을 원래대로 복구하세요.
On Demand: Settings → On Demand에서 저장된 조건을 확인하세요. 이 기능은 연결이 시작되는 조건에 영향을 주며 Config 파일의 DOMAIN-SUFFIX, IP-CIDR 또는 FINAL을 대체하지 않습니다.

구독 갱신 후 트래픽 분산 구성 다시 확인하기

이 글은 이용 중인 서비스와 구독이 있다는 전제로 작성했습니다. 서버 구독 갱신은 주로 서버 항목에 영향을 주며, Config의 규칙, 정책 참조, FINAL을 자동으로 수정하는 것은 아닙니다. 갱신 후 항목 이름이나 사용 가능한 서버가 달라졌다면 기존 정책 선택을 다시 확인해야 할 수 있습니다.

프로토콜도 Global Routing을 대신하지 않습니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 연결 프로토콜이나 터널 방식을 나타냅니다. 특정 프로토콜을 선택했다고 Proxy나 Config까지 선택되는 것은 아닙니다. 프로토콜 매개변수는 이용 중인 서비스에서 제공한 정보를 기준으로 설정하고, 프로토콜 이름만 보고 포트나 인증 방식을 추측하지 마세요.

Home에서 갱신된 서버 항목이 여전히 사용 가능한지, 선택한 서버가 이번 테스트 조건에 맞는지 확인합니다.
Config에서 적용 중인 파일을 확인하고, 규칙에서 참조하는 정책 이름이 존재하는지와 실제 정책 선택이 예상에 맞는지 살펴봅니다.
Home → Global Routing에서 모드를 확인해 이전 문제 해결 과정에서 Proxy나 Direct로 바꾼 상태가 남아 있지 않은지 확인합니다.
직접 연결이 예상되는 대상 하나와 프록시 연결이 예상되는 대상 하나를 각각 테스트합니다. 결과가 예상과 다르면 구독을 반복해서 갱신하지 말고 규칙을 하나씩 확인하세요.

일상적인 설정과 복구 확인

일상적인 기본값으로 Config를 권하는 것은 “구성 파일을 확인했고 목적에 맞게 설정했다”는 전제에 따른 것입니다. 가져온 파일이라면 무엇이든 보장한다는 뜻은 아닙니다. 서버 항목만 있고 규칙을 아직 정리하지 않았다면 Config를 계속 사용하기 전에 구성 내용과 기본 처리 방식을 확인하세요. Proxy와 Direct는 각각 분명한 용도가 있지만, 테스트용 설정을 모른 채 일상 설정으로 남겨 두지 않는 것이 좋습니다.

Proxy를 선택하면 기기의 모든 연결이 프록시를 거치나요?

그렇게 단정할 수는 없습니다. Proxy는 Shadowrocket의 처리 범위에 적용되는 프록시 모드를 뜻합니다. 시스템 라우팅의 범위, DNS 설정, 연결 유형에 따라 실제 경로가 달라질 수 있습니다. 특정 요청의 경로를 확인하려면 모드 이름만 보지 말고 해당 요청의 진단 정보를 확인하세요.

Config가 Proxy보다 느리면 계속 Proxy를 써야 하나요?

먼저 두 모드에서 같은 대상에 접속할 때 같은 정책과 서버를 선택했는지 확인하세요. Config가 다른 출구나 DIRECT를 사용했다면 동일한 경로의 속도를 비교한 것이 아닙니다. 규칙, DNS 조회, 연결 재사용을 확인한 다음 구성 변경 여부를 판단하세요.

문제 해결 후 어떤 설정을 복구해야 하나요?

Home → Global Routing → Config로 돌아가고 Config에서 적용 중인 파일을 확인하세요. 테스트 전에 사용하던 DNS와 Settings → On Demand 설정도 복구한 다음 요청을 다시 보내세요. 평소 Scene을 사용한다면 원래 Scene과 조건을 복구하고, 무조건 Config로 바꾸지 마세요.

이 사이트는 Shadowrocket 공식 웹사이트이며 이 글은 공식 매뉴얼의 일부입니다. Shadowrocket은 독점 상용 앱이며 App Store에서만 받을 수 있습니다. iPhone, iPad 및 기타 Apple 기기의 호환성, 시스템 요구 사항, 일반적인 구매 가능 여부는 App Store 페이지에 표시된 정보를 기준으로 확인하세요. 앱의 일회성 구매와 회선 요금제는 별개이며, 이 글에서는 이용 중인 서비스에 맞춘 앱 설정만 안내합니다.