공식 매뉴얼 / Config 참고

Shadowrocket
규칙 및 설정 가이드

설정 섹션, 매칭 대상, 정책별로 내용을 확인하세요. 먼저 현재 설정을 확인하고 규칙을 하나씩 수정한 뒤 새 연결로 결과를 검증합니다.

빠른 시작 가이드 보기 목차 보기
  • General / Rule / Host / URL Rewrite
  • 규칙은 위에서 아래로 매칭됩니다
  • 예시 도메인 example.com

이 페이지는 Shadowrocket 공식 매뉴얼의 설정 참고편으로, 첫 연결을 마치고 설정 동작을 이해하려는 사용자를 위한 안내입니다. 기존 구독을 처음 가져오거나 서버를 선택하고 VPN 구성을 승인하는 방법은 먼저 사용 가이드를 따라 진행한 뒤 관련 규칙 설명을 확인하세요.

아래 절차는 본인 소유의 구독 또는 서버 정보를 이미 보유한 경우를 전제로 합니다. 앱을 한 번 구매하는 것과 회선 요금제를 구독하는 것은 별개입니다. Shadowrocket은 App Store에서만 받을 수 있습니다. 구매 확인은 App Store 정품 안내를 참고하세요. iPhone 및 iPad의 시스템 요구 사항은 App Store 페이지에 표시된 내용을 기준으로 합니다.

설정 파일 구조와 편집 위치

Shadowrocket 설정 파일에는 규칙과 관련 동작 설정이 들어 있으며, 일반적인 텍스트 파일의 확장자는 .conf입니다. 설정 파일은 서버 구독 자체가 아니며, Home에서 현재 선택한 서버와도 다릅니다. 규칙을 살펴보기 전에 이 세 가지의 역할을 구분해야 합니다. 서버 정보는 연결 대상을 설명하고, 구독은 기존 서버 항목을 모아 갱신하며, 설정 파일은 요청을 어떤 조건에 따라 처리할지 지정합니다. 각각을 따로 확인해야 회선 문제를 규칙 오류로 오해하지 않습니다.

섹션에 따라 각 줄의 의미가 달라집니다

대괄호로 둘러싼 제목은 설정 섹션 이름입니다. 예를 들어 [General]과 [Rule]이 있습니다. 섹션 이름 뒤의 내용은 다음 섹션이 나올 때까지 해당 섹션에 속합니다. General에는 보통 키-값 설정이, Rule에는 쉼표로 구분된 매칭 표현식이 들어갑니다. Host는 호스트 이름 매핑을 지정하고 URL Rewrite는 요청 주소를 다시 씁니다. 둘 다 도메인과 관련 있어 보인다고 해서 Host 매핑이나 재작성 표현식을 Rule에 넣으면 안 됩니다. 파서는 먼저 섹션을 기준으로 각 줄을 해석한 다음 매개변수를 읽습니다.

구조 예시 · 전체 동작 설정이 아님 
[General]
bypass-system = true
dns-server = system

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

[Host]
example.com = 192.0.2.10

[URL Rewrite]
^http://example\.com/old$ http://example.com/new 302

위 예시는 섹션 경계를 설명하기 위한 것으로, 전체를 그대로 복사하는 것은 권장하지 않습니다. Host의 주소는 문서용 예시 주소이며 실제 서비스에 접속할 수 없습니다. 재작성 줄도 문법 설명을 위한 예시일 뿐입니다. 실제 수정 시에는 현재 문제에 필요한 부분만 골라 본인 설정 파일의 복사본에 적용하세요. 도메인 분기만 확인하려는 경우 Host와 URL Rewrite를 동시에 추가할 필요는 없습니다. 변수를 여러 개 한꺼번에 바꾸면 결과가 달라져도 어느 수정이 영향을 줬는지 파악하기 어렵습니다.

현재 선택된 설정을 확인한 뒤 편집하세요

Config에 들어가 현재 사용 중인 설정이 무엇인지 먼저 확인한 다음 내용을 살펴보거나 편집하세요. 목록에 파일이 있다고 해서 현재 설정으로 선택된 것은 아닙니다. 이름이 같은 복사본이 서로 다른 위치에 저장되어 있을 수도 있습니다. 먼저 설정 이름과 출처, 수정 전 주요 규칙의 내용을 기록해 두세요. 저장한 뒤 Config로 돌아가 선택 상태를 다시 확인하면 복사본을 편집한 일을 설정 전환으로 오해하는 것을 막을 수 있습니다. 기기에서 실제로 표시되는 화면을 기준으로 메뉴 위치를 확인하세요.

수정 전에 복원할 수 있는 복사본을 저장하고, ‘일상 규칙 복사본’처럼 용도를 구분하기 쉬운 이름을 사용하세요. 몇 줄의 텍스트만 기억해 두는 것으로는 충분하지 않습니다. 원본에는 정책 그룹, 규칙 참조 또는 DNS 관련 설정이 더 들어 있을 수 있습니다. 원격으로 갱신되는 설정이라면 업데이트가 로컬 편집을 덮어쓰는지 먼저 확인하세요. 원격 업데이트와 로컬 저장은 같은 작업이 아닙니다. 중요한 수정 사항은 업데이트 후에도 다시 확인해야 하며, 계속 유지될 것이라고 단정해서는 안 됩니다.

텍스트 형식과 예시 조각의 적용 범위

규칙에 쓰는 쉼표, 대괄호, 등호는 영문 반각 문자를 사용해야 합니다. 독립된 주석 줄에는 한국어 문장 부호를 써도 되지만, 규칙 필드에 전각 쉼표를 넣으면 분리되어야 할 매개변수가 하나로 인식될 수 있습니다. 예시를 복사한 뒤에는 줄의 앞뒤에 서식용 따옴표, 목록 번호, 보이지 않는 공백이 붙지 않았는지 확인하세요. 편집기에서 긴 규칙이 줄바꿈되어 보이는 것은 실제 개행과 다를 수 있습니다. 규칙은 한 줄에 하나씩 작성해야 합니다.

이 매뉴얼의 코드 블록은 독립된 섹션일 수도 있고, 기존 설정에 합쳐 넣을 몇 개의 규칙일 수도 있습니다. 합칠 때는 같은 이름의 섹션을 계속 추가하지 말고 기존 섹션을 찾아 넣으세요. 기본값으로 처리하는 규칙도 한곳에 모아 관리하는 것이 좋습니다. 원본 파일에 추가 설정이 있다면 이 페이지에 보이는 섹션만 남기고 나머지를 삭제해서는 안 됩니다. 용도를 먼저 파악한 뒤 유지 여부를 결정해야 정상 동작 중인 설정을 ‘정리’하다가 망가뜨리는 일을 줄일 수 있습니다.

Home, Config, Settings의 역할을 아직 잘 모르겠다면 화면의 영문 용어 안내를 먼저 확인하세요. 설정 편집의 목표는 파일을 최대한 짧게 만드는 것이 아니라 각 섹션의 역할을 설명할 수 있고 변경 사항을 되돌릴 수 있게 하는 것입니다. 현재 설정과 수정 위치, 검증할 대상을 정확히 파악해야 매칭 동작을 확인할 수 있습니다.

General 및 Global Routing

General은 여러 공통 동작 설정을 설명하고, Global Routing은 전체적으로 어떤 처리 모드를 사용할지 결정합니다. 둘 다 연결에 영향을 주지만 서로 다른 계층입니다. ‘규칙이 적용되지 않는다’는 문제를 확인할 때는 먼저 Global Routing을 점검한 뒤 설정 텍스트를 살펴보세요. 현재 Config 모드가 아니라면 Rule을 계속 수정해도 기대한 결과가 나오지 않을 수 있습니다. 반대로 모드를 잠시 바꿨을 때 정상 작동했다고 해서 서버나 설정 파일 전체가 올바르다고 단정할 수는 없습니다.

세 가지 모드의 확인 및 검증 방법

화면에 표시되는 용어설명검증 시 확인할 점
ConfigConfig 모드로, 현재 설정에 따라 트래픽을 분기합니다.규칙 조건, 순서, 정책을 검증합니다.
ProxyProxy 모드로, 주요 요청을 프록시 경로로 보냅니다.Config 모드와 비교해 트래픽 분기 문제의 범위를 좁힙니다.
DirectDirect 모드로, 주요 요청을 직접 연결합니다.현재 네트워크에서 직접 접속이 어떻게 되는지 확인합니다.

표에서 ‘주요 요청’이라고 표현한 이유는 시스템 우회, 로컬 네트워크 조건, 클라이언트의 다른 설정이 실제 트래픽에 영향을 줄 수 있기 때문입니다. Global Routing이 모든 시스템 동작을 제어하거나 연결을 켜고 끄는 기능은 아닙니다. Proxy로 전환해도 사용할 수 있는 기존 서버가 필요하고, Direct로 전환해도 현재 네트워크에서 대상에 반드시 접속할 수 있는 것은 아닙니다. 비교할 때는 같은 대상과 네트워크를 비슷한 시간대에 테스트해야 외부 변화를 모드 차이로 오해하지 않습니다.

Config 모드에서는 화면의 Config 선택과 설정 섹션 [Rule]이 함께 트래픽 분기에 관여합니다. 규칙 줄 끝의 PROXY는 해당 규칙에 지정된 정책입니다. 이름이 서로 관련되어 보여도 바꿔 쓸 수는 없습니다. 규칙 줄 끝에 Config라고 적는다고 ‘설정에 따라 처리’하라는 뜻이 자동으로 전달되지 않습니다. 마찬가지로 화면에서 Proxy를 선택했다고 해서 특정 PROXY 규칙이 실제로 매칭됐다는 의미도 아닙니다. 전체 모드와 개별 연결의 처리 결과를 각각 확인해야 합니다.

자주 쓰이는 General 설정 두 가지

[General]
bypass-system = true
dns-server = system

bypass-system = true는 시스템 관련 우회 동작을 활성화한다는 뜻입니다. 이는 연결 처리 범위에 관한 설정이며 특정 도메인 정책을 대신하지 않습니다. 기존 기본값을 유지 중이라면 일반 트래픽 분기 원인은 먼저 Rule에서 확인하세요. 시스템 트래픽이나 특정 네트워크 서비스에 문제가 있다고 의심될 때만 우회 설정을 테스트 변수로 삼는 것이 좋습니다. 무작정 값을 바꾸면 여러 종류의 요청이 동시에 달라져 원래 문제를 재현하기 어려워질 수 있습니다.

dns-server = system은 시스템이 제공하는 DNS 설정을 사용한다는 뜻입니다. 여기서 system은 값이므로 임의의 한국어 설명으로 바꿔 쓸 수 있는 자리표시자가 아닙니다. 시스템 DNS 결과는 Wi-Fi, 셀룰러 네트워크 및 기타 시스템 네트워크 설정에 따라 달라질 수 있습니다. 따라서 같은 설정인데 네트워크를 바꾼 뒤 DNS 응답이 달라져도 규칙 내용이 변한 것은 아닐 수 있습니다. 기존 설정에서 다른 DNS를 지정했다면 먼저 원래 값을 기록한 뒤 시스템 DNS를 시험할지 판단하세요.

설정을 완성된 것처럼 보이게 하려고 의미를 모르는 General 매개변수를 대량으로 복사하지 마세요. 설정 항목에는 서로 전제 조건이 있을 수 있고, 출처가 다른 설정 조각은 같은 문제를 서로 다른 가정으로 다룰 수 있습니다. 동작 중인 기본 설정은 유지하고, 명확한 증상에 맞춰 매개변수 하나만 변경한 뒤 이유를 기록하는 편이 안전합니다. 기기에 관련 옵션이 있다면 앱 내 설정과 현재 설정 파일을 함께 확인하세요. 파일에 특정 키가 있는지만으로 실제 동작을 판단할 수는 없습니다.

연결 스위치, 주문형 연결, 규칙은 서로 다른 기능입니다

On Demand는 조건이 맞을 때 연결을 시작하는 기능으로, 도메인 규칙을 대신하지 않습니다. 연결이 아직 성립하지 않았다면 도메인이 Rule에 매칭되는지 확인해도 권한 승인이나 연결 시작 문제는 해결되지 않습니다. 연결은 됐지만 대상이 잘못된 경로로 이동한다면 On Demand를 반복해서 바꿔도 규칙 순서가 고쳐지는 것은 아닙니다. 먼저 VPN 구성 승인, 연결 상태, 현재 네트워크를 확인한 다음 개별 요청의 처리 방식을 살펴보세요. 이렇게 하면 ‘연결이 언제 활성화되는가’와 ‘연결 중인 트래픽에 어떤 정책을 적용하는가’를 구분할 수 있습니다.

첫 연결 때 표시되는 시스템 안내와 규칙 파일은 서로 다른 설정 계층입니다. 자세한 내용은 VPN 구성 권한 안내를 참고하세요. 백그라운드 연결이 잦거나 배터리 사용량이 달라지는 문제가 있다면 On Demand와 배터리 사용을 확인하고, 모든 백그라운드 증상을 Rule을 줄이는 방식으로 해결하려 하지 마세요. 계층이 다른 문제에는 각각에 맞는 근거가 필요합니다.

General 확인을 마치면 현재 네트워크, 설정, Global Routing, 선택된 기존 서버, On Demand 활성화 여부를 명확한 기준 상태로 기록하세요. 이후 규칙을 테스트할 때 이 상태를 유지해야 새 규칙과 접속 결과의 관계를 설명할 수 있습니다.

DOMAIN 계열 도메인 규칙

도메인 규칙은 연결과 연관된 호스트 이름을 기준으로 정책을 선택합니다. 웹페이지 제목, 앱 이름, 주소창의 전체 텍스트를 기준으로 매칭하지 않습니다. 규칙을 작성하기 전에 대상이 정확한 호스트 하나인지, 도메인 전체와 하위 도메인인지, 이름에 특정 문자열이 포함된 여러 호스트인지 확인하세요. 각각 DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD가 적합합니다. 조건이 너무 넓으면 관련 없는 요청까지 포함되고, 너무 좁으면 페이지 진입 도메인만 처리하고 실제 리소스를 불러오는 다른 도메인을 놓칠 수 있습니다.

DOMAIN: 정확한 호스트 이름 하나만 지정

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,static.example.com,DIRECT

첫 번째 규칙은 api.example.com만 대상으로 하며 example.com이나 v2.api.example.com까지 자동으로 포함하지 않습니다. 두 번째 예시는 같은 도메인 아래의 호스트 두 개에 서로 다른 정책을 적용할 수 있음을 보여 줍니다. 정확한 규칙은 대부분의 요청을 같은 경로로 보내면서 특정 호스트만 별도로 처리해야 하는 경우에 적합합니다. 필드에 프로토콜 접두사, 경로, 쿼리 매개변수, 포트를 붙이지 마세요. DOMAIN의 호스트 이름에 해당하지 않습니다.

로그에 예상과 다른 호스트가 표시되면 리디렉션과 리소스 로딩 과정을 먼저 확인하세요. 주소를 입력한 뒤 로그인, 이미지, API 도메인에 추가로 접속할 수 있습니다. 진입 호스트에 DOMAIN 규칙을 추가해도 관련 요청이 모두 매칭되는 것은 아닙니다. 문제가 발생한 요청의 호스트를 먼저 확인한 다음 규칙을 추가하세요. 웹페이지에 보이는 이름만 보고 매칭 범위를 넓혀서는 안 됩니다. 새 도메인을 추가할 때마다 문제와 어떤 관련이 있는지 설명할 수 있어야 합니다.

DOMAIN-SUFFIX: 도메인과 하위 도메인 포함

[Rule]
DOMAIN,local.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

DOMAIN-SUFFIX,example.com,PROXY는 example.com과 그 하위 도메인에 매칭됩니다. 문자열을 단순 검색하는 것이 아니라 도메인 경계를 기준으로 판단하므로 DOMAIN-KEYWORD와 적용 범위가 다릅니다. 위 예시는 정확한 예외를 먼저 배치한 다음 접미사 규칙을 적용합니다. 이에 따라 local.example.com은 DIRECT를 사용하고 나머지 매칭 호스트는 PROXY를 사용합니다. 접미사 규칙을 앞에 두면 먼저 매칭되어 정확한 예외가 적용되지 않을 수 있습니다.

접미사 규칙에는 *.을 붙일 필요가 없고 정규식으로 작성해서도 안 됩니다. example.com/path라고 적어도 ‘이 경로만 처리’한다는 뜻이 되지 않습니다. 도메인과 경로는 서로 다른 대상입니다. 서로 관련 없는 여러 최상위 도메인은 각각 규칙을 작성하고, 지나치게 짧은 접미사 하나로 묶지 마세요. 실제 경계에 가까운 규칙을 사용하면 나중에 로그를 이해하기 쉽고 다른 서비스에 영향을 줄 가능성도 줄어듭니다.

DOMAIN-KEYWORD: 더 넓게 매칭하는 이름 일부

[Rule]
DOMAIN-KEYWORD,example,PROXY

DOMAIN-KEYWORD는 도메인에 지정한 문자열이 포함되어 있는지 확인합니다. 위 예시는 example.com뿐 아니라 example이 들어간 다른 도메인에도 매칭될 수 있으므로 DOMAIN-SUFFIX의 줄임말로 보면 안 됩니다. 키워드가 짧을수록 적용 범위를 예측하기 어렵습니다. 특정 조직이 관리하는 도메인 묶음이 대상이라면 먼저 정확한 호스트 이름이나 접미사를 고려하세요. 서로 다른 도메인에서 공통 문자열을 찾아야 할 때만 키워드 규칙을 검토하는 것이 좋습니다.

규칙 유형적용 조건주요 확인 사항
DOMAIN확인된 호스트 이름 하나실제로 문제가 발생한 하위 도메인을 놓치지 않았는지
DOMAIN-SUFFIX최상위 도메인과 하위 도메인앞에 정확한 예외 규칙을 둘 필요가 있는지
DOMAIN-KEYWORD이름에 지정한 문자열이 포함됨다른 도메인까지 의도치 않게 포함하지 않는지

도메인 매칭에는 클라이언트가 연결과 관련된 호스트 정보를 얻을 수 있어야 합니다. 앱이 IP 주소를 직접 사용하거나 기록에 대상 주소만 표시된다면 도메인 규칙이 매칭될 근거가 있다고 단정할 수 없습니다. 이때는 먼저 연결 기록에서 어떤 정보를 확인할 수 있는지 살펴본 뒤 주소 규칙을 검토하세요. 동일한 도메인을 여러 방식으로 반복해서 추가할 필요는 없습니다. 확인된 IP와 원래 도메인이 항상 일대일로 대응하는 것도 아닙니다.

도메인 규칙을 검증하려면 먼저 확실한 테스트 호스트를 정하고, 기존 페이지를 닫은 뒤 새 요청을 만들어 처리 정책을 확인하세요. 브라우저 캐시, 앱의 연결 재사용, 백그라운드 요청 때문에 이전 결과가 남아 있을 수 있습니다. 새로 발생한 해당 연결이 예상한 정책을 사용해야 규칙 검증이 완료된 것입니다. 웹페이지가 열린다는 사실만으로 규칙의 적용 범위까지 올바르다고 증명할 수는 없습니다.

IP, GEOIP 및 요청 조건

주소 규칙은 대상 IP 또는 주소의 지역 정보를 조건으로 사용합니다. 명확한 네트워크 대역, IP 주소를 직접 사용하는 연결, 도메인 규칙으로 처리되지 않은 요청을 분류할 때 적합합니다. 도메인 규칙의 다른 표기법은 아닙니다. 하나의 도메인이 여러 주소를 가리킬 수 있고 하나의 주소가 여러 도메인에서 사용될 수도 있습니다. 따라서 주소 기준 분기는 같은 주소를 사용하는 다른 서비스에도 영향을 줄 수 있습니다. 먼저 도메인으로 요구 사항을 명확히 표현한 뒤 적절한 위치에 주소 규칙을 추가하는 편이 범위를 제어하기 쉽습니다.

IP-CIDR: 문자열이 아닌 접두사 길이 이해하기

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
FINAL,PROXY

CIDR에서 슬래시 뒤의 숫자는 네트워크 접두사 길이를 뜻하며 포트나 주소 개수가 아닙니다. 접두사가 길수록 일반적으로 적용 범위가 좁아집니다. 위 예시는 자주 쓰이는 사설 IPv4 대역을 보여 주지만, 모든 대역을 사용하는 것이 본인 로컬 네트워크의 기본이라는 뜻은 아닙니다. 규칙을 작성하기 전에 기기의 네트워크 정보를 확인하세요. 특히 조직 네트워크나 개인 VPN에 연결되어 있다면 대상 주소가 현재 Wi-Fi의 로컬 대역에 속하지 않을 수 있습니다.

단일 IPv4 주소는 /32로 표시할 수 있습니다. 특정 대상 하나를 우회하려고 접두사를 긴 값에서 짧은 값으로 바꾸지 마세요. 훨씬 많은 주소의 처리 방식이 함께 달라집니다. 로컬 기기 검색이 실패하는 문제라면 기기 검색에 사용되는 트래픽과 이후 기기에 접속하는 연결을 구분해야 합니다. 사설 네트워크 대역 규칙 하나를 추가한다고 모든 로컬 검색 기능이 의도대로 동작하는 것은 아닙니다.

IP-CIDR6과 no-resolve의 적용 범위

[Rule]
IP-CIDR6,fd00::/8,DIRECT,no-resolve
IP-CIDR6,2001:db8::10/128,DIRECT,no-resolve

IP-CIDR6은 IPv6 주소용이며 IPv4 규칙으로 대체할 수 없습니다. 두 번째 줄은 단일 주소 접두사 표기를 보여 주는 문서용 예시 주소입니다. 기기에서 두 주소 유형을 모두 받으면 같은 대상에 대한 연결도 서로 다른 주소 체계를 사용할 수 있습니다. IPv4 규칙만 설정하고 IPv6을 확인하지 않으면 ‘어떤 때는 규칙이 적용되고 어떤 때는 적용되지 않는’ 것처럼 보일 수 있습니다. 도메인 조회 결과에 어떤 주소가 보이는지만 보지 말고 실제 연결 기록을 기준으로 판단하세요.

no-resolve는 이 주소 규칙을 매칭하기 위해 별도의 도메인 조회를 일으키지 않도록 하는 옵션입니다. 시스템 DNS를 중지하거나 앱이 DNS 조회를 하지 않도록 보장하는 것은 아닙니다. 연결 대상이 처음부터 IP 주소라면 해당 주소를 바로 비교할 수 있습니다. 대상이 도메인뿐이고 사용할 수 있는 주소 정보가 없다면 규칙이 예상대로 매칭되지 않을 수 있습니다. 테스트 전에 ‘이미 확인된 주소로 판단할지’ 또는 ‘주소 조회 후 판단할지’를 명확히 하세요.

GEOIP: 언어가 아닌 주소 데이터베이스에 따른 분류

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

GEOIP는 대상 주소가 지리 데이터베이스에서 어떻게 분류되는지에 따라 매칭합니다. CN은 이 규칙에서 사용하는 지역 코드입니다. 웹페이지 언어, 도메인 접미사, 조직 이름으로 매칭 결과를 추정하지 않습니다. CDN 주소 배정은 달라질 수 있고 데이터베이스 분류가 예상과 다를 수도 있습니다. 특정 호스트에 고정 정책이 필요하다면 명확한 도메인 규칙을 GEOIP보다 앞에 두세요. 한 번의 조회 결과가 예상 지역으로 나온다는 데 의존하지 마세요.

no-resolve가 포함된 GEOIP 규칙도 주소 정보가 있어야 매칭할 수 있다는 점을 이해해야 합니다. 매칭되지 않으면 데이터베이스 분류를 따지기 전에 대상 IP와 도메인 정보를 확인할 수 있는지 먼저 살펴보세요. GEOIP와 FINAL의 순서를 무작정 바꾸는 것은 해결책이 아닙니다. FINAL은 기본 처리 규칙이므로 마지막에 둬야 합니다. GEOIP 앞에 놓으면 뒤의 규칙이 정상적으로 매칭되지 않습니다.

USER-AGENT: 확인할 수 있는 HTTP 정보에 의존

[Rule]
USER-AGENT,ExampleClient*,DIRECT

USER-AGENT 조건은 HTTP 요청 헤더를 기준으로 하며 기기에 표시되는 앱 이름과는 다릅니다. 위 예시는 가상의 요청 헤더 접두사로 와일드카드 매칭을 설명할 뿐, 실제 앱을 식별하는 방법은 아닙니다. 암호화된 연결에서는 클라이언트가 이 정보를 읽지 못할 수 있으므로 모든 요청에 적용되는 앱 단위 분기 규칙으로 사용해서는 안 됩니다. 요청 헤더는 앱 업데이트나 요청 유형에 따라 달라질 수도 있으므로 장기적인 안정성을 별도로 검증해야 합니다.

규칙 유형은 확인 가능한 근거에 따라 선택해야 합니다. 호스트 이름이 확실하면 도메인 규칙을, 주소 범위가 명확하면 CIDR을, 주소 분류가 꼭 필요하면 GEOIP를 사용하세요. 요청 내용을 확인할 수 있고 조건이 안정적이라는 점을 검증한 경우에만 USER-AGENT를 고려합니다. 관찰 가능한 정보에 맞춰 규칙을 선택하면 결과를 설명하지 못한 채 여러 조건을 반복해서 바꾸는 일을 줄일 수 있습니다.

정책, 매칭 순서 및 FINAL

일반 규칙은 보통 유형, 매칭 값, 정책으로 구성되며 FINAL에는 일반적인 매칭 값이 필요하지 않습니다. 유형은 무엇을 확인할지, 정책은 매칭 후 어떻게 처리할지를 정합니다. PROXY, DIRECT, REJECT는 이 페이지에서 다루는 기본 정책 세 가지입니다. Global Routing 화면의 모드와는 서로 다른 계층입니다. 규칙을 읽을 때는 먼저 조건, 다음으로 결과를 확인하고 마지막으로 해당 규칙이 실행될 수 있는지 살펴보세요. 파일에서 원하는 정책 키워드만 검색해서는 충분하지 않습니다.

PROXY, DIRECT, REJECT의 의미

정책처리 방식추가로 확인할 내용
PROXY프록시 경로를 사용합니다.사용 가능한 기존 서버와 연결 매개변수
DIRECT직접 연결 경로를 사용합니다.로컬 네트워크, DNS 응답, 대상에 연결할 수 있는지
REJECT매칭된 연결을 거부합니다.조건 범위가 지나치게 넓지 않은지, 관련 요청에 영향이 있는지

PROXY가 사용할 서버 정보를 자동으로 만들거나 대상 연결 성공을 보장하지는 않습니다. 규칙에 매칭되더라도 서버에 연결할 수 없거나, 프로토콜 매개변수가 맞지 않거나, 원격 서버가 대상에 접속하지 못하면 실패할 수 있습니다. DIRECT도 ‘반드시 성공’하는 정책은 아니며 직접 접속을 선택한다는 의미입니다. REJECT는 연결을 명시적으로 차단하므로 판단이 어려울 때 임시 기본값처럼 사용하지 마세요. 인증이나 API 요청을 잘못 차단하면 앱 전체에 이상이 생길 수 있습니다.

기존 설정에는 이름이 지정된 정책 그룹이 있을 수도 있습니다. 줄 끝에 이 세 가지 키워드가 없다면 원래 설정으로 돌아가 해당 이름의 정의와 현재 선택 상태를 확인하세요. 그룹 이름을 임의로 PROXY로 바꾼 뒤 기존 선택 방식이 그대로 유지된다고 가정해서는 안 됩니다. 다른 설정에서 가져온 그룹 이름은 정의가 없으면 단독으로 복사해 사용할 수 없습니다. 참조되는 정의가 필요하며 철자, 공백, 이름이 다르면 참조 문제가 생길 수 있습니다.

첫 매칭 규칙이 우선하며 ‘더 구체적인’ 규칙이 자동으로 앞서지 않습니다

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

일반 규칙은 배치된 순서대로 확인하며 앞쪽의 매칭 결과가 뒤 규칙의 적용 여부를 결정합니다. 위 예시는 정확한 예외를 접미사 규칙보다 앞에 두고, 사설 네트워크와 주소 분류를 처리한 뒤 마지막에 기본 규칙을 둡니다. 모든 환경에 적용되는 고정 템플릿이 아니라 읽기 쉬운 배치 방식의 예입니다. 넓은 범위의 접미사 규칙을 맨 위에 놓으면 뒤에 더 정확한 DOMAIN 규칙이 있어도 ‘더 구체적’이라는 이유로 자동 우선되지 않습니다.

주소 규칙과 도메인 규칙 사이에도 적용 순서가 있을 수 있습니다. 적용 범위가 넓은 주소 조건을 너무 앞에 두면 뒤의 도메인 예외가 동작하지 않을 수 있습니다. 반대로 앞선 규칙이 도메인을 먼저 처리하면 이 연결의 일반 규칙 결과는 해당 도메인의 IP가 어디에 속하는지에 따라 결정되지 않습니다. 문제를 확인할 때는 파일 위에서부터 첫 번째로 조건에 맞는 규칙을 찾으세요. 방금 추가한 규칙만 확인해서는 안 됩니다.

중복 규칙은 실제 문제를 가릴 수 있습니다. 조건이 완전히 같은 두 규칙이 서로 다른 정책을 지정하면 뒤 규칙은 예상대로 적용되지 않는 경우가 많습니다. 중복 항목을 삭제하기 전에 서로 다른 관리 영역이나 업데이트 출처에서 온 것인지 확인한 뒤 수정할 위치를 결정하세요. 설정이 큰 경우에는 위치를 찾기 위해 정확한 테스트 규칙 하나를 잠시 앞쪽에 둘 수 있습니다. 테스트가 끝나면 원래 구성 방식으로 되돌려 설명하기 어려운 우선순위 예외가 남지 않게 하세요.

FINAL은 기본 처리 규칙이며 반드시 PROXY를 사용해야 하는 것은 아닙니다

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

이 예시는 example.com에 매칭되는 요청에 PROXY를 사용하고 나머지는 DIRECT로 보냅니다. 마지막 줄을 FINAL,PROXY로 바꾸면 앞의 규칙에 매칭되지 않은 모든 일반 요청의 처리 방식이 달라집니다. 두 방식 모두 요구 사항에 따라 사용할 수 있습니다. 먼저 기본 경로를 정한 뒤 예외를 추가하세요. 예시가 PROXY를 기본 경로로 사용한다고 해서 본인 설정의 전체 접속 방식을 바로 바꾸면 안 됩니다.

FINAL은 일반 규칙의 마지막에 두고 기본 처리 규칙도 명확한 한 곳에 유지하세요. 그 아래에 DOMAIN이나 GEOIP를 추가하면 앞에서 이미 트래픽을 처리해 ‘저장은 됐지만 규칙이 적용되지 않는’ 상황이 생길 수 있습니다. 여러 예시를 복사할 때 하나의 FINAL이 중간에 남고 그 아래에 새 규칙이 추가되기 쉬우므로 파일의 끝부분을 특히 주의해서 확인하세요.

규칙이 의도한 대로 동작하는데도 접속할 수 없다면 같은 종류의 규칙을 계속 추가하지 말고 연결 경로를 점검하세요. 단계별 안내는 연결 실패 문제 해결 순서를 참고하세요. 규칙 계층은 어떤 경로가 선택된 이유를 설명하고 연결 계층은 그 경로가 성공하거나 실패한 이유를 설명합니다. 둘을 나눠 살펴봐야 재현 가능한 결론을 얻기 쉽습니다.

Host 매핑 및 DNS 확인

Host는 호스트 이름에 주소를 지정하고 Rule은 연결에 적용할 정책을 결정합니다. 서로 대체할 수 없습니다. 도메인을 특정 주소에 매핑해도 DIRECT로 연결하라는 뜻은 아니며, 도메인에 PROXY를 지정해도 주소가 고정되는 것은 아닙니다. 문제를 확인할 때는 ‘요청 호스트 이름’, ‘실제 대상 주소’, ‘적용된 정책’을 각각 기록한 뒤 어느 계층에 차이가 있는지 판단하세요. 웹페이지가 열리는지만으로는 이 세 가지 변화를 구분하기 어려운 경우가 많습니다.

Host의 기본 작성법과 적용 범위

[Host]
example.com = 192.0.2.10
api.example.com = 192.0.2.20

왼쪽에는 매핑할 호스트 이름, 오른쪽에는 지정할 주소를 씁니다. 예시 주소는 문서 설명용이며 접속 가능한 서버를 의미하지 않습니다. Host 항목은 Rule의 쉼표로 구분된 세 필드 형식을 사용하지 않으며 끝에 PROXY나 DIRECT를 붙이지 않습니다. 추가한 뒤 주소를 고정해야 하는 이유가 있는지, 해당 주소를 대상 서비스 관리자가 명확하게 제공했는지 확인하세요. 한 번 조회된 결과만으로 동적 서비스를 특정 주소에 계속 연결해서는 안 됩니다.

주소를 고정하면 정상적인 DNS 응답에서 이루어지는 동적 선택의 일부를 건너뛰게 됩니다. CDN, 로드 밸런싱, 장애 조치를 사용하는 서비스는 지역, 네트워크, 시간에 따라 주소가 달라질 수 있습니다. 오래된 매핑은 잠시 동작하다가 나중에 타임아웃, 인증서 오류, 일부 리소스 실패를 일으킬 수 있습니다. 이런 현상이 나타나면 Host 항목을 확인 대상으로 삼고, 도메인 분기 규칙을 더 추가하기 전에 매핑을 해제해 정상 DNS와 비교해 보세요.

Host가 요청의 모든 식별 정보를 바꾸는 것은 아닙니다. HTTPS에서는 인증서 검증이 요청한 호스트 이름과 계속 연관되어 있습니다. IP를 지정했다고 해서 임의의 사이트 인증서를 허용할 수 있는 것은 아닙니다. 인증서 오류가 발생하면 대상 도메인, 매핑 주소, 기기 시간을 확인하고 신뢰 수준을 낮춰 매핑 문제를 감추려 하지 마세요. 근거가 충분하지 않다면 매핑을 더 확대하기보다 되돌리는 편이 기존 상태를 복구하기 쉽습니다.

DNS와 규칙의 연관성

DNS는 이름을 주소로 변환합니다. 도메인 규칙은 호스트 정보를 확인할 수 있을 때 이름을 기준으로 판단하고, 주소 규칙은 적절한 주소 정보가 필요합니다. 둘은 밀접하게 연관되어 있지만 모든 연결에서 정보가 같은 순서로 외부에 드러나는 것은 아닙니다. 앱 캐시, 시스템 캐시, 프록시 경로에서의 DNS 조회 방식이 관찰 결과에 영향을 줄 수 있습니다. 따라서 ‘시스템 조회에서 이 주소가 나왔다’와 ‘이번 연결에서 실제로 이 주소를 사용했다’는 별도로 기록해야 합니다.

[General]
dns-server = system

[Rule]
DOMAIN,api.example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,DIRECT

이 예시는 각 판단 계층을 설명합니다. 첫 번째 규칙은 명확한 도메인을 처리하고, 두 번째는 확인 가능한 주소 정보가 있을 때만 예시 네트워크 대역에 매칭되며, 마지막 줄에서 나머지를 처리합니다. DNS 문제를 해결하는 범용 설정은 아닙니다. api.example.com이 첫 번째 규칙에 매칭됐다면 예시 대역으로 해석된다는 이유만으로 두 번째 규칙을 적용해야 한다고 단정할 수 없습니다. 반대로 요청이 호스트 이름 없이 IP 주소를 직접 사용한다면 매칭 과정이 다를 수 있습니다.

DNS 문제의 분기별 점검 방법

모든 도메인에 접속할 수 없고 확인된 주소에 대한 연결은 다르게 동작한다면 현재 네트워크의 DNS 조회, General의 DNS 설정, Host 덮어쓰기 여부부터 확인하세요. 특정 도메인 하나만 문제가 있으면 철자 오류, 오래된 매핑, 서비스 자체 상태, 차단 규칙이 있는지 먼저 살펴보세요. 페이지가 비어 있다는 이유만으로 바로 DNS 실패라고 판단해서는 안 됩니다. 페이지 진입은 성공했지만 후속 API나 인증 요청이 실패했을 수 있습니다.

Wi-Fi와 셀룰러 네트워크를 전환할 때는 네트워크 변화도 기록하세요. 시스템 DNS, IPv6 사용 가능 여부, 로컬 네트워크 접속 조건이 달라질 수 있습니다. 설정이 같아도 결과가 다르다면 입력 조건을 확인하세요. 서로 모순되는 설정을 두 개 만들어 네트워크별로 ‘맞추려’ 하지 마세요. 비교 테스트의 목표는 차이의 원인을 찾는 것입니다. 최종 설정은 차이를 설명할 수 있어야지, 특정 네트워크에서 우연히 동작했던 상태만 기억해서는 안 됩니다.

Host나 DNS를 수정한 뒤에는 새 테스트 연결을 만들어야 합니다. 기존 연결은 이전 주소를 계속 사용할 수 있습니다. 필요한 경우 대상 앱을 완전히 종료한 다음 다시 열고 새 요청 기록을 확인하세요. 페이지를 새로 고친다고 모든 네트워크 상태가 반드시 갱신되는 것은 아닙니다. 여러 설정을 한꺼번에 초기화한 뒤 ‘재시작하니 해결됐다’고만 기록하지 마세요. 변경 순서를 남겨야 새 DNS 응답, 기존 연결 종료, 다른 작업 중 무엇이 결과를 바꿨는지 알 수 있습니다.

DNS 문제를 확인한 뒤에는 문제가 발생한 호스트, 당시 네트워크, 매핑 유무, 실제 사용 주소, 최종 정책처럼 확인 가능한 사실을 기록해야 합니다. 정보가 충분하지 않은 상태에서 다른 General 매개변수까지 수정하면 불확실성만 커집니다. 자주 발생하는 연결 및 DNS 문제는 자주 묻는 질문과 함께 항목별로 확인할 수 있습니다.

URL Rewrite와 매칭 범위

URL Rewrite는 확인 가능한 요청 주소를 다시 쓰거나 리디렉션하는 기능으로, Rule의 경로 선택과는 다릅니다. Rule은 ‘연결에 어떤 정책을 적용할지’를 결정하고 URL Rewrite는 ‘조건에 맞는 요청 주소를 어떻게 처리할지’를 결정합니다. example.com에 PROXY를 사용하려는 것뿐이라면 재작성 표현식이 아니라 도메인 규칙을 작성하세요. 요청 주소를 실제로 바꿔야 하고 결과 동작을 이해하는 경우에만 재작성 섹션을 사용해야 합니다.

리디렉션 표현식의 구성

[URL Rewrite]
^http://example\.com/old$ http://example.com/new 302

이 줄은 매칭 표현식, 대체 주소, 처리 방식으로 구성됩니다. 예시는 302를 사용해 임시 리디렉션을 나타냅니다. 확인 가능한 요청 주소가 왼쪽 표현식과 일치하면 오른쪽 주소로 이동하는 리디렉션 결과가 반환됩니다. 기본 문법을 설명하기 위해 HTTP와 경로 전체가 정확히 일치하는 표현식을 사용했습니다. HTTPS의 가시성이나 복잡한 경로 캡처는 포함하지 않았습니다. 예시 도메인은 설명용이며 실제 테스트 서비스가 아닙니다.

표현식에서 ^는 시작 부분, $는 끝부분을 고정하고 \.은 점 문자 자체를 나타냅니다. 이스케이프를 생략하면 정규식의 점은 일반적으로 더 넓은 범위와 일치합니다. 끝 고정 기호를 생략하면 추가 경로나 쿼리가 붙은 주소도 매칭될 수 있습니다. 편집할 때는 각 기호의 의미를 하나씩 확인하세요. 표현식이 ‘URL처럼 보인다’는 이유만으로 일반 주소 텍스트와 같다고 판단해서는 안 됩니다.

오른쪽 주소도 완전하고 명확해야 합니다. HTTP를 HTTPS로 바꿔도 대상 서비스가 같은 위치에서 동일한 내용을 제공한다는 보장은 없습니다. 호스트 이름이나 경로를 바꾸면 로그인 상태, 교차 출처 요청, API 동작에도 영향을 줄 수 있습니다. 재작성은 지정된 요청만 바꿀 뿐 대상 서비스에 페이지를 새로 만들지는 않습니다. 브라우저에서는 동작하는 표현식도 앱이 리디렉션을 허용하지 않으면 해당 앱의 요청에서 실패할 수 있습니다.

범위를 제한한 뒤 복잡한 조건을 추가하세요

처음 테스트할 때는 호스트 하나와 경로 하나로 시작하고 모든 도메인을 대상으로 하는 패턴은 피하세요. 정확한 매칭이 예상대로 동작하는지 확인한 뒤 하위 경로나 쿼리 매개변수를 허용할지 검토합니다. 표현식의 범위를 넓힐 때마다 새로 포함되는 요청 유형을 적어 두세요. 쿼리 내용을 유지해야 한다면 매개변수가 대체 주소에 어떻게 포함되는지 명확히 지정해야 합니다. 원래대로 자동 전달될 것이라고 가정해서는 안 됩니다.

정규식의 캡처 그룹, 이스케이프, 설정 텍스트는 서로 다른 계층의 문제입니다. 설정 파일에서 직접 편집하는 경우와 같은 텍스트를 다른 형식 안에 넣는 경우에는 필요한 이스케이프가 다를 수 있습니다. 설명 페이지에 표시된 이중 이스케이프를 설정 파일에서도 백슬래시를 두 배로 써야 한다는 뜻으로 받아들이지 마세요. 이 페이지의 코드 블록은 설정 파일에 들어가는 텍스트 자체를 보여 줍니다. 복사한 뒤 편집기에서 문자 하나씩 확인하고 따옴표나 이스케이프를 한 겹 더 추가하지 마세요.

하나의 재작성 섹션에 표현식이 여러 개 있다면 조건이 서로 겹치지 않도록 하고 구체적인 항목부터 일반적인 항목 순으로 정리하세요. Rule의 FINAL을 URL Rewrite에 그대로 적용하지 마세요. 서로 다른 문법입니다. 기존 설정에 복잡한 재작성 조합이 있다면 복사본에서 관련 조합을 잠시 비활성화해 비교한 뒤 대상 표현식만 따로 활성화해 검증하세요. 출처를 알 수 없는 규칙을 한꺼번에 여러 개 추가하고 페이지가 열리는지만 확인해서는 안 됩니다.

HTTPS, 인증서 및 요청 내용 확인 가능 여부

HTTPS는 요청 내용을 보호합니다. 도메인을 안다고 해서 클라이언트가 전체 경로를 읽고 임의의 재작성을 수행할 수 있다고 가정해서는 안 됩니다. 관련 요청을 처리할 수 있는지는 실제 기능 설정과 연결 조건에도 달려 있습니다. 이 페이지의 예시를 사용하기 위해 HTTPS 복호화를 켜거나 인증서를 설치할 필요는 없습니다. 도메인 분기만으로 요구 사항을 해결할 수 있다면 영향 범위가 더 명확한 Rule을 우선 사용하세요.

인증서와 신뢰 관련 변경은 별도로 검토해야 합니다. 특히 재작성 표현식을 ‘적용’하려고 출처를 설명할 수 없는 설정을 허용해서는 안 됩니다. 인증서 오류, 앱의 연결 거부, 재작성 미매칭은 각각 다른 현상입니다. 시스템이나 앱에 실제로 표시된 오류를 먼저 기록한 뒤 요청이 처리 가능한 계층까지 도달했는지 확인하세요. 그렇지 않으면 요청 내용 확인 제한을 정규식 오류로 오해해 매칭 범위를 계속 넓힐 수 있습니다.

반복 리디렉션과 캐시로 인한 착각 구분하기

대체된 주소가 다시 원래 표현식에 매칭되면 리디렉션이 반복될 수 있습니다. 브라우저에는 연속 이동, 오류 페이지, 로딩 실패로 나타날 수 있습니다. 문제를 확인할 때 시작 주소, 대체 주소, 대체 주소가 다시 매칭되는지를 각각 적어 보세요. 검증 후에도 반복을 피하려고 브라우저가 우연히 더 요청하지 않는 상황에 기대지 말고 조건을 충분히 구체적으로 유지하세요.

리디렉션 결과가 앱에 캐시되어 표현식을 비활성화해도 이전 동작이 바로 사라지지 않을 수 있습니다. 새 요청을 사용해 주소가 어떻게 바뀌는지 기록하고 필요한 경우 대상 앱의 이전 세션을 종료하세요. 원래 설정으로 복구한 뒤에도 문제가 남아 있다면 저장 실패라고 단정하지 말고 캐시와 대상 서비스의 응답을 먼저 확인하세요. 원래 주소에서 최종 주소까지의 모든 단계를 설명할 수 있어야 재작성 문제를 해결한 것입니다.

설정 검증 및 문제 해결 순서

설정 문제 해결의 목표는 모든 설정을 반복해서 바꾸는 것이 아니라 현상을 설명할 수 있는 최소한의 원인을 찾는 것입니다. 시작하기 전에 현재 네트워크, Global Routing, 설정 이름, 기존 서버, 대상 요청을 기록하세요. 다음으로 ‘api.example.com의 새 연결은 PROXY를 사용해야 한다’처럼 구체적인 기대 결과를 정합니다. 목표가 구체적일수록 검증하기 쉽습니다. ‘모든 기능이 정상으로 돌아오는 것’은 최종 확인에는 적합하지만 단일 규칙의 첫 검증 기준으로는 적절하지 않습니다.

연결 기준 상태부터 확인하고 규칙은 먼저 바꾸지 마세요

먼저 Shadowrocket의 VPN 구성이 승인되었고 연결이 성립하는지 확인하세요. 연결을 시작할 수 없다면 시스템 안내와 연결 상태를 먼저 살펴보세요. 연결은 됐지만 기존 서버에 도달할 수 없다면 서버 정보와 네트워크를 확인하세요. 기본 연결을 테스트할 수 있는 상태가 된 뒤에 Rule을 확인해야 합니다. Connectivity Test는 연결 관련 단서를 제공할 수 있지만 테스트 하나가 통과했다고 모든 도메인, 프로토콜 요청, 규칙을 검증한 것은 아닙니다.

다음으로 Config가 현재 Global Routing인지, 사용 중인 설정이 방금 편집한 파일인지 확인하세요. 복사본에 저장했지만 원본 설정을 계속 사용하면 결과가 달라지는 경우가 많습니다. 파일에서 쉽게 구분할 수 있는 규칙 하나를 대조하고 저장한 뒤 필요한 경우 다시 연결하세요. 앱에서 문법 오류가 표시되면 먼저 파일 문법을 수정해야 합니다. 유효하지 않은 설정으로 매칭 결과를 추정해서는 안 됩니다.

조건, 순서, 정책을 단계별로 확인하세요

  1. 실제 요청과 연결된 호스트 이름이나 대상 주소가 규칙 필드와 일치하는지 확인합니다.
  2. Rule의 첫 줄부터 아래로 살펴보며 더 앞에서 매칭되는 조건이 있는지 확인합니다.
  3. FINAL이 일반 규칙을 앞에서 종료시키지 않는지 확인합니다.
  4. 매칭된 정책 또는 이름이 지정된 정책 그룹과 실제 연결 경로를 확인합니다.
  5. 새 연결로 다시 테스트하고 결과를 수정 전 기록과 비교합니다.

요청 호스트가 규칙과 다르면 먼저 매칭 대상을 확인하세요. 호스트는 일치하지만 다른 정책이 적용되면 규칙 순서나 설정 선택을 확인합니다. 정책은 맞는데 연결에 실패하면 경로와 대상 서버를 살펴보세요. 이렇게 분기하면 연결이 실패할 때마다 도메인 규칙을 추가하고, 그래도 안 되면 DNS를 바꾸고, 다시 안 되면 키워드 범위를 넓히는 반복을 피할 수 있습니다. 테스트마다 하나의 질문에 답하도록 하고 모든 설정을 동시에 검증하려 하지 마세요.

[Rule]
DOMAIN,api.example.com,PROXY
FINAL,DIRECT

이 최소 설정 조각은 문제 위치를 찾는 방법을 설명하기 위한 것으로 기존 설정 전체를 덮어쓰면 안 됩니다. 실제 테스트는 저장된 복사본에서 정확한 조건 하나를 임시로 사용해 넓은 규칙의 영향을 배제하세요. 정확한 조건으로 예상한 정책이 적용되면 기존 규칙 블록을 단계별로 복원합니다. 그래도 결과가 다르면 요청 정보를 확인할 수 있는지, 설정이 적용됐는지, 현재 모드가 올바른지 살펴보세요. 비슷한 규칙을 계속 추가하는 것보다 신뢰할 수 있는 결론을 얻는 방법입니다.

현상을 다시 확인할 수 있는 유형으로 나누세요

관찰된 현상먼저 확인할 항목당장은 하지 말아야 할 일
편집해도 처리 결과가 전혀 바뀌지 않습니다.현재 설정, Global Routing, 저장 여부, 기존 연결같은 조건을 연달아 여러 개 추가하기
정책에는 매칭되지만 접속에 실패합니다.기존 서버, 연결 매개변수, 대상, 네트워크도메인 규칙 범위만 넓혀 해결하려 하기
일부 리소스만 실패합니다.실패 요청의 실제 호스트 이름과 차단 규칙진입 도메인이 모든 요청을 대표한다고 보기
네트워크를 바꾸면 동작이 달라집니다.시스템 DNS, 주소 유형, 로컬 네트워크 조건설정 텍스트 자체가 자동으로 바뀌었다고 단정하기

간헐적으로 발생하는 문제는 성공한 한 번만 기록하지 말고 실패할 때마다 시간, 네트워크, 대상을 적어 두세요. 페이지가 기존 연결을 재사용할 수도 있고 서비스가 DNS 응답 주소를 바꿀 수도 있습니다. 반복 요청도 매번 같은 조건을 사용하는 것은 아닙니다. 기록을 확인할 때는 테스트 동작에 해당하는 새 연결을 기준으로 삼고 백그라운드 동기화나 다른 앱의 트래픽을 테스트 결과로 오해하지 마세요.

Data 또는 관련 진단 기록을 확인해야 한다면 대상 요청에 필요한 정보만 수집하세요. 전체 기록에는 도메인, 경로, 쿼리 내용, 개인 식별 정보가 포함될 수 있으므로 공유 전에 정리해야 합니다. 다른 사람에게 문제를 설명할 때는 민감한 정보를 지운 규칙 조각, 현재 모드, 재현 절차를 제공하세요. 설정 전체나 구독 주소를 그대로 전달할 필요는 없습니다. 관련 없는 기록을 많이 제공하는 것보다 판단 과정을 재현할 수 있게 설명하는 편이 도움이 됩니다.

복구, 정리 및 추가 참고

원인을 확인한 뒤에는 문제 해결에 필요한 변경만 남기고 위치를 찾기 위해 추가한 임시 광범위 규칙, Host 매핑, 재작성 표현식을 되돌리세요. 예외 규칙의 영향을 받던 항목을 포함해 일상적으로 사용하는 다른 대상도 확인합니다. 마지막으로 복원 가능한 새 복사본을 저장하고 수정 목적을 기록하세요. 설정이 업데이트될 수 있다면 다음 업데이트 후에도 주요 내용이 유지되는지 확인해 로컬 수정이 덮어써지지 않았는지 살펴봐야 합니다.

일상적인 가져오기와 첫 연결은 빠른 시작 가이드를 참고하세요. 구매, 앱 ID, 개발자 확인은 정품 확인 안내에서 확인할 수 있습니다. 자주 묻는 사용 방법은 자주 묻는 질문을 참고하세요. 이 페이지의 규칙 참고는 설정으로 의도를 표현하는 방법을 설명합니다. 실제 결과는 현재 기기에서 새 연결을 만들고 확인 가능한 기록을 바탕으로 항목별 검증해야 합니다.