사용 중인 서비스와 접속 정보를 이미 갖고 있다면, 평소에는 현재 설정에 따라 각 요청의 정책을 결정하는 Config를 사용하는 것이 일반적입니다. Proxy는 일시적으로 모든 요청을 프록시로 보내거나 비교 진단할 때, Direct는 직접 연결 상태를 확인할 때 사용합니다. 이 글에서는 각 모드의 적용 범위와 전환 방법, 문제 진단 절차를 설명하고 ‘연결이 켜짐’과 ‘특정 요청이 실제로 프록시를 사용함’의 차이를 짚어봅니다.
먼저 모드 선택: Config는 규칙에 따라 라우팅하고, Proxy와 Direct는 비교 진단에 사용
Shadowrocket의 Global Routing은 처리 대상 요청에 적용할 라우팅 방식을 결정합니다. 서버 목록이 아니며 접속 서비스를 제공하는 기능도 아닙니다. 모드를 선택하기 전에 Home에서 사용할 수 있는 서버 정보가 있는지 확인하세요. 서버 정보가 없다면 Proxy로 전환해도 사용할 수 있는 연결이 자동으로 생기지 않습니다.
Config
권장현재 설정의 규칙과 정책을 사용합니다. 규칙에 따라 PROXY, DIRECT, REJECT 또는 설정에 정의된 정책 그룹이 적용될 수 있습니다. 앞선 규칙에 일치하지 않으면 마지막으로 FINAL을 확인합니다.
적합한 경우: 규칙에 따른 라우팅 설정을 마련해 둔 일상적인 사용
Proxy
처리 대상 일반 요청을 Config의 개별 라우팅 규칙에 따라 보내는 대신, 모두 프록시 경로로 보냅니다. 단, 서버를 사용할 수 있어야 하며 시스템과 설정의 트래픽 제외 항목도 고려해야 합니다.
적합한 경우: 프록시 경로를 잠시 확인하거나 규칙이 결과에 영향을 주는지 진단할 때
Direct
처리 대상 일반 요청을 선택한 프록시 서버를 거치지 않고 직접 연결합니다. 연결 스위치는 계속 켜져 있을 수 있으므로 Direct가 연결을 끄는 것은 아닙니다.
적합한 경우: 현재 네트워크에서 직접 접속한 결과를 비교할 때
여기서 ‘모두’라는 표현은 기기의 모든 시스템 연결을 강제로 처리한다는 뜻이 아닙니다. 실제 적용 범위는 시스템 라우팅, 설정의 제외 항목, 앱 작동 방식에 따라 달라집니다. DNS에도 별도 설정이 있으므로 모드 이름만 보고 DNS 서버나 모든 DNS 요청의 경로를 단정할 수 없습니다.
Global Routing에 Scene이 표시된다면 별도의 시나리오별 설정 진입점으로 보세요. Config의 다른 이름으로 취급하면 안 됩니다. 이 글에서는 먼저 세 가지 명확한 모드를 기준으로 판단 방법을 설명합니다. 문제를 진단할 때는 모드를 하나로 고정한 뒤 Scene 전환으로 상태가 바뀌는지도 확인하세요.
전환 절차: 현재 상태를 기록한 뒤 새 연결로 테스트
모드 설정은 Home → Global Routing에서 찾을 수 있습니다. 전환하기 전에 현재 모드, 선택한 서버, Config에서 사용 중인 설정 파일을 기록해 두세요. 테스트가 끝난 뒤 원래 설정으로 돌아가기 쉽습니다. 설정 파일은 규칙을 결정하고 서버 정보는 프록시 연결 매개변수를 결정하므로 서로 대체할 수 없습니다.
- Home에서 서버를 확인합니다. 이미 보유하고 있으며 사용할 권한이 있는 접속 정보를 선택했는지 확인하세요. 목록에 있다는 이유만으로 현재 사용할 수 있다고 판단하지 마세요.
- Global Routing을 엽니다. 평소 규칙에 따라 라우팅하려면 Config, 프록시 경로를 확인하려면 Proxy, 직접 연결을 확인하려면 Direct를 선택합니다.
- Home으로 돌아가 연결 스위치를 확인합니다. 모드만 바꿔서는 연결이 새로 설정되지 않습니다. 필요하다면 다시 연결해 테스트 상태를 명확히 하세요.
- 요청을 새로 보냅니다. 기존 테스트 페이지를 닫았다가 다시 열거나 관련 앱의 연결을 새로 시작하세요. 이미 재생 중인 콘텐츠나 기존 장시간 연결만 관찰해서는 안 됩니다.
- 테스트가 끝나면 원래 설정으로 되돌립니다. 평소 사용하려던 모드로 돌아가 선택한 설정과 서버가 여전히 예상한 상태인지 확인하세요.
연결 스위치를 끈 뒤 자동으로 다시 켜진다면 Settings → On Demand의 트리거 조건을 확인하세요. On Demand는 필요에 따른 연결을 관리하고 Global Routing은 연결이 설정된 뒤의 라우팅을 관리합니다. 자동으로 연결되더라도 이번 테스트 목적에 맞는 모드가 자동 선택된다는 뜻은 아닙니다.
일상적인 사용에 Config가 적합한 이유: 규칙을 확인한 뒤 FINAL 점검
Config를 사용하면 기본적으로 ‘특정 사이트는 항상 이 경로를 사용한다’고 가정하지 않고 대상별로 처리 방식을 구분할 수 있습니다. 결과는 전적으로 현재 설정에 달려 있습니다. 규칙은 보통 순서대로 확인하며 먼저 일치하는 규칙이 적용할 정책을 결정합니다. 따라서 Config를 선택하더라도 설정을 바꾸면 결과가 달라질 수 있습니다.
아래는 규칙 순서를 설명하기 위한 예시이며 완성된 설정 파일이나 바로 사용할 수 있는 서비스 정보가 아닙니다. 예시 도메인은 설명용입니다. 실제로 편집할 때는 Config에서 원본 파일을 복사해 보관한 뒤 대상 설정을 수정하세요.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECTDOMAIN-SUFFIX,example.com,PROXY: example.com과 하위 도메인에 PROXY를 적용합니다. 다른 도메인도 프록시를 사용한다는 뜻은 아닙니다.IP-CIDR,192.168.0.0/16,DIRECT,no-resolve: 지정된 IPv4 주소 대역과 일치합니다.no-resolve는 이 IP 규칙과 일치시키기 위해 도메인 조회를 별도로 시작하지 않는다는 뜻입니다.GEOIP,CN,DIRECT: 앱에서 사용하는 GEOIP 데이터를 바탕으로 대상 IP를 판별합니다. 페이지 언어나 웹사이트 이름을 기준으로 판별하는 것은 아닙니다.FINAL,DIRECT: 앞선 규칙에 하나도 일치하지 않으면 직접 연결합니다. 마지막 규칙을FINAL,PROXY로 바꾸면 일치하는 규칙이 없는 요청의 기본 경로도 바뀝니다.
REJECT는 요청을 거부하는 정책이며 사용할 수 없는 서버를 선택하는 것과는 다릅니다. 현재 설정에 대상과 일치하는 REJECT 규칙이 있으면 서버 테스트가 정상이어도 Config에서 해당 요청이 거부될 수 있습니다. 설정에 사용자 지정 정책 그룹이 있다면 그룹 안에서 선택한 항목도 확인해야 합니다. 규칙에 적힌 그룹 이름만 확인해서는 충분하지 않습니다.
진단 기준: Proxy에서는 되지만 Config에서는 안 될 때 먼저 대상 규칙 확인
서버와 네트워크를 그대로 둔 상태에서 대상 도메인에 더 먼저 일치하는 규칙, 해당 정책 그룹, FINAL을 확인하세요. 프로토콜 매개변수부터 다시 입력하지 마세요. 이 비교로 점검 범위를 좁힐 수 있지만, 원인을 확인하려면 DNS와 연결 기록도 함께 살펴봐야 합니다.
Proxy와 Direct 사용법: 변수를 고정해 비교 테스트
Proxy는 개별 라우팅 규칙을 잠시 건너뛰어 확인할 때, Direct는 현재 네트워크에서 직접 연결한 기준을 세울 때 유용합니다. 둘 다 진단 도구일 뿐 속도를 보장하지 않습니다. Proxy로 전환한 뒤 속도가 느려졌다면 프록시 경로나 서버 부하가 달라졌을 수 있습니다. Direct에서 열리지 않더라도 현재 네트워크가 대상에 직접 접속할 수 없는 것일 수 있으므로 앱 설정이 손상됐다고 단정할 수 없습니다.
비교 방법: 같은 대상, 같은 네트워크, 같은 서버
프록시 경로 확인: Proxy
- 현재 Wi-Fi 또는 셀룰러 네트워크를 기록하고 테스트 중에는 일부러 바꾸지 않습니다.
- 선택한 서버를 그대로 유지하고 Proxy를 선택한 뒤 테스트 연결을 새로 설정합니다.
- 같은 대상에 접속해 성공, 시간 초과, 연결 중단 등 구체적인 결과를 기록합니다.
- Config로 돌아가 다시 시도하고, 모드에 따라 차이가 반복되는지 확인합니다.
직접 연결 확인: Direct
- Direct를 선택한 뒤 같은 대상에 새 요청을 보냅니다.
- 페이지에 캐시된 콘텐츠가 표시되는지만 보지 말고 연결이 설정되는지 기록합니다.
- 연결을 완전히 끈 상태를 확인해야 한다면 별도로 연결 스위치를 끄고 테스트합니다.
- 테스트가 끝나면 Config로 돌아가 임시 설정을 평소 상태로 남겨 두지 않습니다.
한 번에 모드 하나만 바꾸세요. 네트워크와 서버를 동시에 바꾸고 DNS까지 수정하면 비교 결과로 원인을 찾기 어려워집니다.
결과를 판단할 때는 아래 순서대로 점검 범위를 좁혀 보세요. 이는 문제 진단을 위한 참고 사항이며, 이 글에서 실제 테스트를 완료했다고 주장하는 데이터가 아닙니다. 실제 결과는 해당 기기에서 수행한 테스트 기록을 기준으로 판단하세요.
| 관찰된 결과 | 우선 확인할 항목 | 다음 조치 |
|---|---|---|
| Proxy는 정상, Config는 이상 | 규칙 일치 여부, 정책 그룹, FINAL, DNS 차이 | Config로 돌아가 대상 규칙을 확인하고 DIRECT 또는 REJECT 규칙에 일치한 것은 아닌지 살펴봅니다. |
| Direct는 정상, Proxy는 이상 | 선택한 서버, 인증 정보, 전송 매개변수 | 보유한 서비스 정보의 주소, 포트, 프로토콜, TLS 설정을 확인합니다. |
| 세 가지 모드 모두 이상 | 기본 네트워크, 대상 상태, DNS, 시스템 시간 | 먼저 다른 대상에 접속할 수 있는지 확인한 뒤 항목별로 점검합니다. 여러 설정을 한꺼번에 바꾸지 마세요. |
| 전환했는데 결과가 한동안 달라지지 않음 | 캐시, 연결 재사용, 테스트 요청을 새로 보냈는지 여부 | 연결을 새로 설정한 뒤 같은 동작으로 다시 테스트합니다. |
혼동하지 마세요: 프로토콜, 구독, On Demand는 서로 다른 부분을 관리합니다
Global Routing은 ‘이번 요청이 어떤 경로를 사용할지’를 결정하고, 프로토콜 매개변수는 ‘프록시 연결을 어떻게 설정할지’를 결정합니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 매개변수 구성이 서로 다릅니다. 모드를 바꿔도 잘못 입력한 인증 정보가 수정되거나 한 프로토콜이 다른 프로토콜로 바뀌지는 않습니다.
- 주소와 포트: 이미 보유한 서비스 정보에 따라 입력해야 합니다. 어떤 정보에 포트
443이 사용된다고 해서 그것만으로 특정 프로토콜이라고 판단할 수 없으며, 다른 포트를 모두443으로 바꿔서도 안 됩니다. - 구독 가져오기 및 업데이트: 이미 보유한 서버 정보를 가져오거나 갱신하는 기능입니다. 업데이트에 성공했다는 것은 해당 정보 가져오기 절차가 완료됐다는 뜻일 뿐, 목록의 모든 항목을 사용할 수 있거나 현재 Config 규칙이 예상대로 작동한다는 뜻은 아닙니다.
- Config: 현재 사용 중인 설정 파일과 규칙 순서, 정책 대상을 확인합니다. 서버 정보를 가져오는 것만으로 라우팅 규칙 설정이 완료되지는 않습니다.
- Settings → On Demand: 자동 연결 조건을 확인합니다. 이 설정과 Home → Global Routing의 선택은 각각 따로 점검해야 합니다.
Wi-Fi나 셀룰러 네트워크를 바꾼 뒤에는 현재 모드가 예상대로 유지되는지 먼저 확인하고 테스트를 시작하세요. Scene이나 다른 자동화 설정을 사용한다면 실제 적용 결과도 점검해야 합니다. 환경이 달라져 설정이 전환된 것을 같은 규칙의 결과가 무작위로 바뀐 것으로 오해하지 마세요.
자주 묻는 질문: 연결은 켜져 있는데 왜 예상한 경로를 사용하지 않나요?
연결을 켰는데도 일부 요청이 직접 연결되는 이유는 무엇인가요?
먼저 Home → Global Routing에서 Direct가 선택되어 있는지 확인하세요. Config를 선택했다면 Config에서 대상과 일치한 규칙과 FINAL을 살펴보세요. 연결 스위치가 켜져 있다는 것은 연결 상태를 뜻할 뿐, 모든 요청이 PROXY를 사용한다는 의미는 아닙니다.
Config를 선택하면 라우팅 규칙이 자동으로 설정되나요?
아닙니다. 먼저 현재 사용 중인 설정 파일을 확인한 뒤 규칙과 정책을 점검하세요. 설정 마지막에 FINAL,DIRECT가 있으면 다른 규칙에 일치하지 않은 요청은 직접 연결됩니다. Config 자체에 모든 사용자에게 적합한 라우팅 규칙이 포함되어 있는 것은 아닙니다.
Proxy를 임시로 선택한 뒤 계속 그대로 사용해도 되나요?
분명한 사용 목적이 있다면 그대로 둘 수 있지만, Config의 개별 규칙에 따라 요청을 구분하지는 않습니다. 일부 대상에 DIRECT를 적용하던 중이었다면 테스트가 끝난 뒤 Home → Global Routing → Config로 돌아가 새 요청으로 확인하세요.
Direct와 연결 스위치를 끄는 것은 같은 테스트인가요?
다릅니다. Direct에서는 앱의 연결 상태와 관련 처리 환경이 유지됩니다. 연결 스위치를 끈 상태는 별개의 상태입니다. 앱의 연결 환경이 원인인지 판단하려면 두 가지를 각각 테스트하세요. 테스트 중에는 Settings → On Demand도 확인해 조건에 따라 스위치가 다시 켜지지 않도록 합니다.
구독을 업데이트한 뒤에도 연결되지 않으면 바로 Proxy로 전환해야 하나요?
먼저 Home에서 업데이트 후 실제로 선택된 항목을 확인한 다음, 이미 보유한 서비스 정보와 테스트 결과를 점검하세요. Proxy는 잠깐 비교하는 데 쓸 수 있지만 프록시 연결 자체가 실패한다면 모드를 바꿔도 주소, 포트 또는 인증 정보 오류는 해결되지 않습니다.
일상적인 사용은 다음 순서로 정리할 수 있습니다. 현재 설정이 올바른지 확인한 뒤 Config를 사용하고, 문제가 생기면 네트워크와 서버를 고정한 상태에서 Proxy와 Direct로 잠시 비교한 다음 원래 상태로 되돌립니다. 매번 테스트한 모드와 대상, 결과를 기록하면 여러 설정을 반복해서 동시에 바꾸는 것보다 원인을 찾기 쉽습니다.