Shadowrocket 지정 사이트만 프록시하는 방법: 규칙으로 특정 도메인은 PROXY, 나머지는 직접 연결

일부 웹사이트만 프록시를 이용하고 싶을 때 적합합니다. 대상 도메인에 PROXY를 지정하고 FINAL,DIRECT로 나머지를 처리한 뒤, Config에서 라우팅이 적용되는지 확인하는 방법을 안내합니다.

이 글 미리 보기

Shadowrocket에서 일부 웹사이트만 프록시하려면 Global Routing에서 Config를 선택하고, 대상 도메인의 PROXY 규칙을 앞에 배치한 다음 FINAL,DIRECT로 마무리합니다. 사용자가 이미 자체 연결 서비스와 구독을 보유한 상황을 전제로 도메인 목록 작성, 설정 적용, 연결 확인 및 누락 항목 점검 방법을 설명합니다. 기본적으로 직접 연결하고 지정한 도메인만 프록시를 사용하는 규칙 구성을 만들 수 있습니다.

1. 라우팅 목적과 적용 범위 정하기

이 구성은 명시한 도메인만 프록시를 사용하고 나머지 요청은 기본적으로 직접 연결합니다. 대상 범위가 좁고 도메인 목록을 관리할 수 있는 경우에 적합합니다. 알 수 없는 요청도 기본적으로 프록시를 사용하게 하려는 경우에는 이 글의 기본 규칙을 사용하지 마세요. FINAL,DIRECT는 그 반대 의미이며, 앞선 규칙에 해당하지 않는 요청은 직접 연결됩니다.

준비할 항목은 두 가지입니다. Home에 사용할 수 있는 연결 항목이 있어야 하고, Config에 수정하고 활성화할 수 있는 설정이 있어야 합니다. 구독을 가져오면 연결 항목이 제공될 뿐, 대상 웹사이트에 맞는 라우팅 규칙까지 자동으로 설정되는 것은 아닙니다. 클라이언트 구매, 연결 서비스 이용, 규칙 설정은 각각 별개의 항목입니다. 클라이언트 구매에는 회선 요금제가 포함되지 않습니다.

2. Global Routing에서 Config 선택

Home → Global Routing에서 Config를 선택해야 현재 활성화된 설정의 규칙에 따라 연결 경로가 결정됩니다. Proxy와 Direct는 임시 비교 테스트에 적합하지만, 일부 도메인만 프록시하는 규칙 설정을 대신할 수는 없습니다. Scene을 사용 중이라면 해당 Scene에 실제로 적용된 라우팅 설정도 확인하세요. 이 글의 검증 과정에서는 조건이 바뀌지 않도록 Config를 계속 사용합니다.

Config

권장

활성화된 설정의 규칙에 따라 요청을 처리합니다. 대상 도메인에 PROXY를 지정하고 마지막에 FINAL,DIRECT를 두면 지정한 도메인만 프록시되고 나머지는 직접 연결됩니다.

적합한 경우: 매일 사용하는 몇 개의 대상 도메인을 직접 관리할 때

Proxy

이 라우팅이 처리하는 범위의 트래픽을 모두 프록시로 보냅니다. 이 글의 도메인별 규칙에 따라 대상을 구분하지 않습니다. 전환 후 웹사이트에 접속할 수 있다면 문제가 라우팅과 관련 있는지 판단하는 데 참고할 수 있습니다.

적합한 경우: 프록시 연결과 규칙 일치 중 어디를 점검해야 하는지 임시로 확인할 때

Direct

이 라우팅이 처리하는 범위의 트래픽을 모두 직접 연결합니다. 설정에 PROXY 규칙이 있더라도 이 모드에서는 이 글에서 설명하는 라우팅 결과를 얻을 수 없습니다.

적합한 경우: 현재 네트워크에서 직접 연결되는지 임시로 비교할 때

모드를 먼저 고정한 뒤 규칙 수정

테스트할 때마다 Home → Global Routing → Config인지, 활성화된 설정 이름이 맞는지 확인하세요. 모드 전환, 연결 항목 변경, 도메인 규칙 수정을 한꺼번에 하지 마세요. 결과가 달라진 원인을 파악하기 어렵습니다.

3. 도메인 목록을 정하고 최소 규칙 작성

도메인 규칙은 호스트 이름을 대상으로 하며 웹 주소 전체를 대상으로 하지 않습니다. 예를 들어 https://www.example.com/account에서는 www.example.com을 추출해야 합니다. https://, 경로 /account, 쿼리 매개변수는 DOMAIN 규칙에 넣지 마세요. 아래에서는 문법 설명용으로 예약된 예시 도메인을 사용하며, 실제 연결 테스트 대상이 아닙니다.

2가지
이 글에서는 DOMAIN과 DOMAIN-SUFFIX 두 가지 도메인 매칭 유형을 사용합니다
3개 요소
도메인 규칙은 유형, 매칭 대상, 정책 순으로 작성하고 영문 쉼표로 구분합니다
1개
마지막에 FINAL,DIRECT를 두어 기본 규칙으로 사용합니다
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,login.example.net,PROXY
FINAL,DIRECT

아래는 설명용 [Rule] 내용이며, 설정 전체를 덮어쓰라는 뜻이 아닙니다. 첫 번째 규칙은 example.com과 하위 도메인인 www.example.com, static.example.com을 모두 매칭하지만 notexample.com은 매칭하지 않습니다. 두 번째 규칙은 login.example.net만 매칭하며 www.example.net까지 프록시하지는 않습니다.

요청 호스트 이름매칭 항목예상 정책
example.com첫 번째 DOMAIN-SUFFIXPROXY
img.example.com첫 번째 DOMAIN-SUFFIXPROXY
login.example.net두 번째 DOMAINPROXY
www.example.net마지막 FINALDIRECT

PROXY는 프록시 경로를 사용한다는 뜻이며, 실제 연결은 현재 선택된 프록시와 설정의 정책에 따라 달라집니다. 서버 주소를 입력하는 항목이 아닙니다. 기존 설정에서 사용자 지정 정책 그룹을 사용한다면 그룹 이름과 그룹 내 선택 항목을 확인하세요. 기존 그룹 이름을 무조건 PROXY로 바꾸지 마세요. 이 글의 예시는 PROXY 정책을 직접 사용하는 최소 구성입니다.

4. 순서에 따라 설정을 수정하고 활성화

규칙은 일반적으로 위에서 아래로 확인하며, 처음 일치한 규칙의 정책을 적용합니다. 따라서 새 규칙을 기존 FINAL 뒤에 추가하면 적용되지 않습니다. 앞에서 먼저 매칭되는 범위가 넓은 규칙 뒤에 두어도 해당 규칙까지 도달하지 않을 수 있습니다. 지정한 도메인만 프록시하도록 설정할 때는 새로 추가한 두세 줄만 볼 것이 아니라 규칙 구간 전체를 검토해야 합니다.

  1. 복사본 보관

    Config로 이동해 현재 설정의 복사본을 보관하거나 내보내 백업하고, 현재 활성화된 설정 이름을 기록합니다. 원격 콘텐츠로 관리되는 설정이라면 로컬 복사본을 따로 저장한 뒤 수정하세요. 이후 업데이트로 수동 수정 내용이 덮어쓰이는 것을 방지할 수 있습니다.

  2. 규칙 정리

    Config에서 수정할 설정의 편집 화면을 열고 [Rule]을 찾습니다. 텍스트 편집 시에는 해당 구간만 수정하고, 규칙 편집 화면에서는 유형, 도메인, 정책을 확인합니다. 중복된 [Rule] 구간을 추가하지 마세요.

  3. 기본 규칙 설정

    대상 도메인의 PROXY 규칙을 해당 도메인에 먼저 일치할 수 있는 범위가 넓은 규칙보다 앞에 두고, 마지막에는 FINAL,DIRECT를 유지합니다. 기존 PROXY 규칙이나 규칙 세트도 확인하세요. 이를 유지하면 ‘이 글에서 지정한 도메인만 프록시’하는 구성이 되지 않습니다.

  4. 설정 활성화

    저장한 뒤 Config로 돌아가 방금 수정한 설정을 선택하고 활성화 표시를 확인합니다. 파일을 저장하는 것만으로 현재 사용 중인 설정이 되는 것은 아닙니다. 다음으로 Home → Global Routing → Config로 이동합니다.

  5. 다시 확인

    Home에서 선택한 프록시 항목을 사용할 수 있는지 확인한 뒤 연결을 다시 설정하고 새 요청을 보냅니다. 기존 연결이 유지되는 페이지를 새로고침하는 것만으로 판단하지 마세요. 필요하면 이전 페이지를 닫고 다시 열어 연결 재사용의 영향을 줄이세요.

5. 대상 도메인과 비대상 도메인을 모두 확인

검증할 때는 ‘웹페이지가 열리는지’뿐 아니라 ‘어떤 규칙이 적용됐는지’도 확인해야 합니다. 웹사이트 접속 성공은 직접 연결이나 프록시 연결 모두에서 발생할 수 있습니다. 접속 실패 원인도 DNS, 대상 서비스, 프록시 연결 또는 누락된 의존 도메인일 수 있습니다. Connectivity Test는 연결 항목을 확인하는 기능이며, 요청별 규칙 확인을 대신하지 않습니다.

페이지의 글자는 보이는데 이미지가 표시되지 않으면 이미지 요청의 실제 호스트 이름부터 확인하세요. 예를 들어 본문은 www.example.com에서 가져오지만 이미지가 img.example.net에서 제공된다면 첫 번째 접미사 규칙은 이미지 도메인에 적용되지 않습니다. 해당 호스트도 프록시가 필요하다고 확인한 경우에만 DOMAIN,img.example.net,PROXY를 추가하고 FINAL 앞에 배치하세요.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,login.example.net,PROXY
DOMAIN,img.example.net,PROXY
FINAL,DIRECT

리소스 로드가 한 번 실패했다고 DOMAIN-KEYWORD나 넓은 IP 규칙을 바로 추가하지 마세요. 공유 인프라의 도메인과 주소는 여러 웹사이트에서 함께 사용할 수 있습니다. 규칙 범위가 넓을수록 ‘지정한 사이트만 프록시’한다는 경계를 유지하기 어렵습니다.

6. 자주 묻는 질문과 확인 항목

규칙을 작성했는데 지정한 웹사이트가 왜 직접 연결되나요?

먼저 Home → Global Routing이 Config인지 확인한 뒤 Config에서 활성화된 파일을 확인하세요. 다음으로 규칙 순서를 살펴봅니다. 앞에 있는 DIRECT, 규칙 세트, FINAL이 먼저 매칭될 수 있습니다. 마지막으로 연결 기록에서 실제 호스트 이름을 확인해 입력한 도메인과 일치하는지, 리디렉션 후 다른 도메인으로 바뀐 것은 아닌지 살펴보세요.

다른 웹사이트까지 왜 프록시를 사용하나요?

먼저 Global Routing이 Proxy에 머물러 있지 않은지 확인하세요. Config를 사용 중이라면 기존 설정에 다른 PROXY 규칙, 범위가 넓은 DOMAIN-KEYWORD 또는 참조 규칙 세트가 남아 있는지 확인하고, 마지막 규칙이 FINAL,PROXY가 아닌지도 살펴보세요. 접미사 규칙은 해당하는 모든 하위 도메인에 적용됩니다. 범위를 줄이려면 DOMAIN을 사용하세요.

웹페이지 경로에 따라 특정 페이지에만 프록시를 적용할 수 있나요?

이 글에서 사용하는 DOMAIN과 DOMAIN-SUFFIX는 같은 호스트에서 /video와 /account를 구분하지 않습니다. 포트가 다르다고 별개의 도메인 규칙으로 처리되지도 않습니다. HTTPS에서 흔히 사용하는 포트는 443이지만 규칙에 :443을 추가해도 호스트 이름을 올바르게 지정하는 방법을 대신할 수는 없습니다. 하위 사이트만 구분하려면 먼저 서로 다른 호스트 이름을 사용하는지 확인하세요.

IP 주소로 접속하면 왜 도메인 규칙이 적용되지 않나요?

IP 주소로 직접 요청할 때 도메인 규칙이 반드시 매칭된다고 가정할 수 없습니다. 특정 IPv4 주소에 프록시를 적용해야 한다면 필요에 따라 IP-CIDR,192.0.2.10/32,PROXY,no-resolve와 같은 규칙을 FINAL 앞에 둘 수 있습니다. 이 주소는 문서 예시용입니다. 웹사이트가 일시적으로 확인한 전체 주소 범위를 프록시에 포함하지 마세요. 공유 주소와 DNS 응답 변경으로 적용 범위가 넓어질 수 있습니다.

구독을 업데이트하면 규칙도 함께 바뀌나요?

연결 구독 업데이트와 Config의 규칙 설정은 서로 다른 작업입니다. 업데이트 후 현재 선택한 프록시를 계속 사용할 수 있는지 확인하고, 활성화된 설정이 바뀌었는지도 살펴보세요. 원격 설정만 업데이트한 경우에는 로컬 수정 내용이 덮어쓰였는지 확인해야 합니다. 연결 목록 새로고침에 성공했다는 이유만으로 규칙이 여전히 올바르다고 판단하지 마세요.

7. 유지 관리 목록과 기존 설정 복원

이후에는 ‘실제 요청 호스트 이름’을 기준으로 관리합니다. 특정 기능이 작동하지 않으면 실패한 도메인을 기록한 뒤 프록시 목록에 추가해야 하는지 판단하세요. 프록시가 필요 없는 분석, 리소스 등의 요청까지 기록을 깔끔하게 만들기 위해 추가할 필요는 없습니다. 규칙을 정확하게 작성할수록 각 연결 경로를 설명하기 쉽습니다.

최종 확인 기준은 두 가지입니다. 목록에 있는 실제 요청은 예상한 PROXY 규칙에 매칭되고, 목록에 없는 비교 요청은 FINAL,DIRECT에 매칭되어야 합니다. 설정 복사본과 검증 기록, 명확한 도메인 범위를 보관하면 전체 라우팅 모드를 반복해서 전환하는 것보다 장기적으로 관리하기 쉽습니다.

App Store 정품 구매 페이지구매 전 개발자와 앱 ID 확인