2026년 8월 29일 · 고급 설정 · 약 8분

Shadowrocket 부분 사이트 프록시 설정법: DOMAIN-SUFFIX 규칙 예시

기본 연결은 DIRECT로 두고 지정한 사이트만 프록시로 보내는 방법을 안내합니다. DOMAIN-SUFFIX, DOMAIN-KEYWORD, IP-CIDR와 FINAL 규칙의 순서를 설명하고 수정해 쓸 수 있는 Config 예시를 제공합니다.

이 글의 핵심

이 글은 Shadowrocket에서 기존에 사용하던 서비스를 설정해 두었으며, 지정한 사이트에만 프록시를 적용하려는 사용자를 위한 안내입니다. 핵심은 Home → Global Routing에서 Config를 선택한 뒤, 현재 설정의 [Rule]에 사이트별 규칙을 먼저 작성하고 나머지 연결은 FINAL,DIRECT로 처리하는 것입니다. 아래에서 규칙 예시와 편집·확인 방법, 도메인·IP·DNS의 차이를 살펴봅니다.

1. Global Routing이 Config인지 확인하기

연결 스위치와 트래픽 분기 방식은 서로 다릅니다. 연결을 켜면 트래픽이 시스템 VPN 터널을 통과하지만, 모든 연결이 프록시를 사용한다는 뜻은 아닙니다. 기본 연결은 DIRECT로 두고 지정한 사이트만 프록시로 보내려면 Home → Global Routing에서 Config를 선택하고, 수정하려는 설정 파일이 활성화되어 있는지 확인하세요.

이 글은 사용할 수 있는 프록시 서비스가 이미 설정되어 있다고 가정합니다. 규칙의 PROXY는 트래픽 처리 방식이지 서버 주소가 아니며, 이것만으로 사용할 수 있는 서비스가 만들어지지는 않습니다. 먼저 Home에서 사용할 수 있는 서버를 선택하고, 현재 설정에 서버 선택에 영향을 주는 정책 그룹이 있는지 확인하세요.

설정기능이 글에서의 선택
Proxy모든 연결을 전역 프록시 모드로 처리합니다. 이 글의 도메인 허용 목록에 따른 분기 방식과는 다릅니다.이 글의 규칙을 확인하는 데는 사용하지 않습니다.
Direct모든 연결을 전역 DIRECT 모드로 처리합니다.지정한 도메인 규칙을 작성해도 해당 연결이 자동으로 프록시를 사용하지는 않습니다.
Config현재 활성화된 설정 파일의 규칙에 따라 처리 방식을 선택합니다.이 글에서는 이 항목을 사용합니다.
Scene설정된 Scene에 따라 동작을 결정합니다.먼저 Config로 고정해 Scene 변경과 규칙 수정을 함께 진행하지 않도록 합니다.

Settings → On Demand에서는 필요할 때 연결할 조건을 관리합니다. 특정 사이트에 DIRECT 또는 PROXY를 적용하는 기능은 아닙니다. 문제를 확인할 때는 터널 연결 여부와 어떤 규칙이 연결에 적용됐는지를 따로 살펴보세요. 도메인 규칙을 고치려고 On Demand를 반복해서 전환하지 마세요.

2. 규칙은 위에서부터 적용하고 FINAL은 맨 마지막에 두기

이 글에서 다루는 기본 규칙 구성에서는 연결이 앞쪽 규칙과 일치하면 그 규칙의 정책이 적용됩니다. 뒤에 있는 규칙이 이미 적용된 결과를 덮어쓰지는 않습니다. 따라서 구체적인 예외를 범위가 넓은 규칙보다 먼저 작성하고, 나머지 연결을 처리하는 FINAL은 맨 마지막에 두세요.

앱 요청 시스템 터널 규칙 매칭 정책 선택 외부 연결

DOMAIN-SUFFIX는 도메인을 대상으로 매칭하며 전체 URL을 확인하지 않습니다. https://example.com/video가 아니라 example.com을 입력하세요. 같은 도메인 아래의 경로별 구분은 이 규칙으로 할 수 없습니다. /video, 쿼리 매개변수, 페이지 제목도 매칭 대상이 아닙니다.

3. 수정해서 사용할 수 있는 Config 예시

아래 예시는 [Rule] 섹션만 보여 주며, 서비스 설정 전체가 아닙니다. 도메인과 IP 대역은 문법 설명을 위한 예시입니다. 203.0.113.0/24는 문서용 대역이므로 실제 서비스 확인에 사용하지 마세요. 실제로 사용할 때는 분기할 도메인이나 확인된 대상 IP 대역으로 바꾸고, 필요 없는 줄은 삭제하세요.

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,example.net,PROXY
DOMAIN-KEYWORD,example-media,PROXY
IP-CIDR,203.0.113.0/24,PROXY,no-resolve
FINAL,DIRECT

첫 번째 규칙은 api.example.com을 DIRECT 예외로 남깁니다. 이어지는 두 개의 접미사 규칙은 지정한 두 사이트와 하위 도메인을 PROXY로 보냅니다. 키워드 규칙은 작성법을 보여 주기 위한 예시입니다. 전체 도메인을 알고 있다면 오매칭을 줄이도록 DOMAIN 또는 DOMAIN-SUFFIX를 사용하는 편이 좋습니다. 마지막 IP 규칙은 알고 있는 대역을 추가로 처리하고, FINAL은 그 외 연결을 기본적으로 DIRECT로 보냅니다.

  1. 설정 백업하기

    Config에서 현재 활성화된 설정을 열고, 먼저 원본을 복사하거나 내보내 백업하세요. 원격 설정은 편집할 수 있도록 로컬 사본으로 저장하는 것이 좋습니다. 이후 원격 설정을 업데이트할 때 로컬에서 수정한 내용이 덮어써지는 일을 방지할 수 있습니다.

  2. 규칙 편집하기

    Config에서 해당 로컬 파일의 편집 기능을 열고 기존 [Rule] 섹션을 찾습니다. 필요한 규칙을 이 섹션에 합치세요. 두 번째 [Rule] 섹션을 새로 추가하지 말고, 기존 FINAL의 위치도 확인하세요.

  3. 정책 확인하기

    DIRECT와 PROXY의 철자가 정확한지 확인하세요. 원본 설정의 사용자 지정 정책 그룹 이름을 유지했다면 해당 그룹이 여전히 있는지도 확인해야 합니다. 이 글의 예시는 일반적인 PROXY 정책을 사용하며, 같은 이름의 서버를 새로 만들 필요는 없습니다.

  4. 설정 활성화하기

    저장한 뒤 Config에서 수정한 파일을 선택하고, Home → Global Routing에서 Config를 선택하세요. 파일만 저장하고 활성화하지 않으면 현재 연결에 적용되는 규칙은 바뀌지 않습니다.

  5. 연결 다시 시작하기

    Home의 연결 스위치를 껐다가 다시 켠 후 웹페이지에 새로 요청을 보내세요. 기존 장시간 연결은 이전 연결 경로를 계속 사용할 수 있으므로 해당 페이지나 앱을 닫고 다시 시도해야 할 수 있습니다.

원래 설정에 GEOIP,CN,DIRECT가 있다면 대상 IP의 지역 정보를 기준으로 DIRECT를 선택한다는 뜻입니다. 웹사이트의 언어나 도메인 접미사를 판별하는 규칙은 아닙니다. 기본 연결을 DIRECT로 두는 이 글의 구성에서는 대개 이 규칙이 필요하지 않습니다. 유지한다면 사이트별 프록시 규칙 뒤, FINAL 앞에 두어 먼저 적용되지 않도록 하세요.

4. 웹페이지가 열리는지만 보지 말고 연결 기록으로 확인하기

웹페이지가 열린다는 사실만으로 요청에 응답이 왔다는 것은 확인할 수 있지만, 어떤 정책이 적용됐는지는 알 수 없습니다. 연결 기록에서 대상 도메인, 대상 IP, 적용된 규칙과 처리 정책을 함께 확인하세요. 기록을 보는 위치와 표시 항목은 화면에 따라 다를 수 있습니다. 확인할 핵심은 새로 만들어진 동일 연결에 실제로 어떤 결과가 적용됐는지입니다.

테스트 대상예상 규칙예상 정책
api.example.com가장 위에 있는 DOMAIN 예외 규칙DIRECT
www.example.comDOMAIN-SUFFIXPROXY
static.example.netDOMAIN-SUFFIXPROXY
앞선 규칙과 일치하지 않은 실제 사이트FINALDIRECT

표는 규칙에 따른 예상 결과이며, 예시 도메인의 연결 가능성을 테스트한 결과가 아닙니다. 실제로 확인할 때는 설정에 입력한 실제 사이트를 사용하세요. 한 번에 규칙 하나만 변경하고 연결을 새로 만든 뒤 결과를 기록하면 규칙 순서 문제인지, 설정이 활성화되지 않은 문제인지, 서비스 자체에 연결할 수 없는 문제인지 구분할 수 있습니다.

5. 시간 초과와 도메인 조회 오류를 구분해 확인하기

규칙이 PROXY를 선택하더라도 DNS, 서버 연결 또는 대상 서비스의 상태 때문에 실패할 수 있습니다. 아래는 시스템 네트워크 오류에 자주 표시되는 원문 메시지입니다. 실제 로그에 해당 내용이 있을 때만 그에 맞춰 확인하세요. 이 오류가 규칙 작성 오류만을 의미하는 것은 아니며, 오류 코드만으로 문제가 발생한 위치를 판단할 수도 없습니다.

NSURLErrorDomain Code=-1001

원인 및 해결 방법: 요청 시간이 초과된 경우로, 연결을 맺거나 응답을 기다리는 중 발생할 수 있습니다. 먼저 해당 연결에 실제로 DIRECT와 PROXY 중 무엇이 적용됐는지 확인하세요. 같은 프록시로 연결이 확인된 다른 대상을 이용해 한 사이트의 문제인지 프록시 연결 경로의 문제인지 구분합니다.

NSURLErrorDomain Code=-1003

원인 및 해결 방법: 호스트를 찾지 못한 경우로, 도메인과 DNS 조회 결과를 확인해야 합니다. 실제로 접속한 도메인의 철자가 맞는지 먼저 확인한 다음, 현재 설정의 [General]에 있는 dns-server 값을 살펴보세요. 수정 전에는 원래 값을 보관하고, DNS 문제를 해결하기 위해 FINAL 규칙을 추가하지 마세요.

도메인 규칙은 해당 도메인을 식별했을 때 어떤 정책을 적용할지를 정합니다. 모든 DNS 조회가 같은 프록시를 거친다는 뜻은 아닙니다. DNS의 출처와 조회 경로, 외부 연결은 서로 관련은 있지만 별도로 설정됩니다. no-resolve가 있는 IP-CIDR 규칙도 모든 도메인 요청이 먼저 조회된 뒤 해당 대역과 비교된다고 단정할 수 없습니다.

6. 특정 사이트만 프록시를 적용할 때 자주 묻는 질문

DOMAIN-SUFFIX 하나만 추가하면 되나요?

Global Routing이 Config로 설정되어 있는지, 현재 설정 끝의 FINAL이 DIRECT인지도 확인해야 합니다. 원본 파일에 FINAL,PROXY가 남아 있으면 다른 규칙과 일치하지 않은 연결은 계속 PROXY를 사용하므로, 기본 연결을 DIRECT로 두려는 이 글의 목적을 달성할 수 없습니다.

*.example.com으로 하위 도메인을 매칭할 수 있나요?

DOMAIN-SUFFIX에는 별표, 프로토콜, 경로를 붙이지 않고 example.com을 입력하세요. 이 설정은 루트 도메인과 하위 도메인을 모두 포함합니다. 호스트 하나만 매칭하려면 DOMAIN을 사용하세요.

업데이트 후 규칙이 원래대로 돌아가는 이유는 무엇인가요?

먼저 Home의 서비스 구독을 업데이트했는지, Config의 원격 설정을 업데이트했는지 확인하세요. 원격 설정을 다시 가져오면 파일 내용이 덮어써질 수 있습니다. 사용자 지정 분기 규칙은 별도의 로컬 설정 파일에 저장하고, 업데이트 후 현재 활성화된 파일을 다시 확인하세요.

Hysteria2 또는 WireGuard로 바꾸면 도메인 규칙도 다시 작성해야 하나요?

프로토콜은 프록시 연결 방식을 정하고 DOMAIN-SUFFIX는 대상을 매칭하므로 서로 다른 설정입니다. 서비스를 바꾼 뒤에는 새 서비스가 작동하는지, 규칙에서 참조하는 정책을 사용할 수 있는지 확인하고 같은 사이트에 다시 연결해 보세요. 프로토콜 이름이 바뀌었다는 이유만으로 도메인 규칙을 수정할 필요는 없습니다.

특정 사이트에 프록시를 적용하면 다른 앱에도 영향이 있나요?

이 글의 규칙은 앱 이름이 아니라 연결 대상에 따라 트래픽을 분기합니다. 다른 앱도 같은 도메인에 접속하면 PROXY를 사용할 수 있습니다. 한 앱이 매칭되지 않는 도메인에 접속하면 FINAL,DIRECT가 적용됩니다. 실제 연결 기록을 기준으로 확인하세요.

App Store에서 다운로드먼저 정품 정보를 확인하세요