Shadowrocket 규칙 매뉴얼
설정 구조와 매칭 순서

설정 파일과 구독은 서로 다른 항목입니다

설정 파일은 요청을 처리하는 방식을 지정하고, 구독은 사용자가 보유한 서버 항목을 가져오고 관리하는 데 주로 쓰입니다. 두 항목이 함께 연결에 쓰일 수는 있지만 서로를 대체하지는 않습니다. 구독 업데이트가 성공했다는 것은 관련 내용을 읽었다는 뜻일 뿐, 현재 규칙이 올바르다는 증거는 아닙니다. 설정 파일을 저장할 수 있어도 파일에 참조된 프록시를 사용할 수 있다는 보장은 없습니다. 문제를 진단하기 전에 두 항목을 각각 확인해 서버 설정 문제를 규칙 예외로 잘못 처리하지 않도록 하세요.

Config에서 현재 선택된 설정을 확인한 다음 해당 편집 화면으로 이동하세요. 테스트가 필요하면 먼저 파일을 복사해 알아보기 쉬운 이름을 붙이고 원본은 보관하세요. 복사본만 수정하고 실제로 선택하지 않으면 연결 결과에 수정 사항이 반영되지 않습니다. 반대로 사용 중인 파일을 편집했다면 저장 후 앱 안내에 따라 다시 불러오세요. 검증할 때는 요청을 새로 발생시키고, 수정 전에 이미 연결된 세션에 의존하지 마세요.

대괄호로 설정의 적용 범위를 구분합니다

Shadowrocket의 일반적인 텍스트 설정은 섹션 제목으로 내용을 구분합니다. [General]에는 일반 설정, [Rule]에는 분류 규칙, [Host]에는 호스트 이름 매핑, [URL Rewrite]에는 요청 주소 재작성 규칙을 넣습니다. 섹션은 단순한 장식이 아닙니다. 같은 문장도 어느 섹션에 있느냐에 따라 의미가 달라질 수 있습니다. 예시를 복사할 때는 섹션 위치까지 함께 확인하세요. 파일에 키워드가 있다는 이유만으로 설정이 적용됐다고 판단해서는 안 됩니다.

[General]
dns-server = system

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

이 예시는 구조만 보여 줍니다. 첫 번째 규칙은 루트 도메인에 정확히 적용되고, 두 번째 규칙은 같은 접미사를 가진 다른 도메인에 적용되며, 마지막 규칙은 나머지 요청을 처리합니다. dns-server = system은 시스템 DNS 설정을 사용한다는 뜻이며 모든 환경에서 같은 결과로 해석된다는 보장은 없습니다. 예시를 저장할 수 있다고 해서 서버 선택, 연결 권한 또는 모든 네트워크 설정이 끝난 것은 아닙니다. 이러한 조건은 앱에서 각각 확인해야 합니다.

설정을 수정할 때는 변경 내역을 추적할 수 있도록 최소한만 바꾸세요

긴 파일을 살펴볼 때는 먼저 섹션 제목을 찾고, 해결하려는 문제에 해당하는 부분을 확인하세요. 같은 섹션이 반복되거나 기본 처리 규칙이 중복되거나 임시 항목이 파일 곳곳에 흩어져 있으면 판단하기 어려워집니다. 같은 유형의 로컬 예외는 한곳에 모으고, 목적은 별도의 주석으로 설명하는 것이 좋습니다. 주석에는 규칙 내용을 되풀이하기보다 필요한 이유를 적으세요. 공유할 파일의 주석에 실제 구독 주소나 인증 정보를 넣지 마세요.

설정을 가져오기 전에는 파일 이름만 보고 적합성을 판단하지 말고 먼저 내용을 확인하세요. 최종 정책, DNS 설정, 호스트 매핑과 재작성 항목을 살펴본 뒤 현재 환경에 없는 정책 이름을 참조하는지 확인하세요. 규칙이 많아도 원래 설정이 사용하던 서버 구성에만 맞을 수 있습니다. 모르는 옵션은 원래 값을 유지하고 앱에서 지원 여부를 확인하세요. 다른 형식의 설정 이름을 현재 파일에 그대로 추가하지 마세요.

자동 업데이트되는 내용과 직접 관리하는 내용은 분리하세요. 설정 출처가 업데이트될 때 로컬 수정 사항이 덮어써질 수 있습니다. 먼저 업데이트 대상이 구독인지 전체 설정 파일인지 확인한 다음 로컬 예외를 어디에 둘지 결정하세요. 덮어쓰기 범위를 알기 어렵다면 별도 복사본을 보관하고 변경 사항을 기록하세요. 원격 파일을 계속 수정하는 것보다 복구하기 쉽고, 문제가 업데이트 때문인지 직접 수정 때문인지도 구분하기 좋습니다.

아래 코드 블록 중 일부에는 섹션 제목이 있고 일부에는 규칙만 있습니다. 규칙만 있는 예시는 기존 [Rule] 섹션에 넣으면 됩니다. 예시마다 같은 이름의 섹션을 새로 만들 필요는 없습니다. 구매와 첫 실행부터 다시 확인하려면 App Store 정품 확인 페이지를 참고하세요. 이 매뉴얼은 앱을 받는 과정과 트래픽 설정을 한 절차로 섞지 않습니다.

먼저 Config, Proxy, Direct 확인하기

설정 파일에 따라 트래픽을 분류하려면 Global Routing에서 Config를 선택해야 합니다. Proxy와 Direct는 전체 요청을 처리하는 별도의 모드이지, 설정 규칙에 덧붙이는 일반 규칙 두 개가 아닙니다. Proxy 모드에서는 도메인 규칙을 수정해도 Config의 분류가 올바른지 확인할 수 없습니다. Direct 모드에서 대상에 접속할 수 있더라도 프록시 서버가 요청을 처리했다는 뜻은 아닙니다. 문제를 확인할 때는 모드부터 점검하세요.

표는 세 가지 모드의 주요 용도를 설명합니다. 다른 설정이 모두 대체된다는 뜻은 아닙니다. DNS, 기존 연결, 앱 자체의 네트워크 동작도 관찰 결과에 영향을 줄 수 있습니다. 모드 전환은 비교를 위한 방법이지 특정 단계가 완벽히 정상임을 증명하는 검사는 아닙니다. 테스트할 때 현재 모드와 선택한 설정을 기록하고, 완료 후에는 원래 의도한 설정으로 되돌리세요. 그렇지 않으면 이후 조정이 잘못된 전제에 기반할 수 있습니다.

모드, 규칙, 서버를 세 단계로 확인하기

문제 확인은 세 단계로 나눌 수 있습니다. 먼저 설정 기반 분류가 적용되는지 확인하고, 다음으로 요청이 어떤 규칙에 매칭되는지 살펴본 뒤, 마지막으로 정책이 참조하는 연결 항목을 사용할 수 있는지 확인합니다. 규칙에서 PROXY를 선택한다는 것은 처리 경로를 지정할 뿐 서버 주소, 포트, 인증 정보를 채워 주지는 않습니다. 사용자 구독에 사용할 수 있는 항목이 없다면 정교한 도메인 규칙도 연결 정보를 대신할 수 없습니다. 사용자 본인의 서버 정보를 먼저 확인한 뒤 예외 규칙이 필요한지 살펴보세요.

화면의 Proxy와 규칙에 쓰인 PROXY를 혼동하지 마세요. 전자는 Global Routing 옵션이고 후자는 설정 텍스트의 정책 키워드입니다. 둘 다 프록시 경로와 관련되지만 서로 다른 단계에 속합니다. 화면의 Direct와 규칙의 DIRECT도 문맥에 따라 구분해야 합니다. 텍스트를 편집할 때 대문자 키워드를 그대로 유지하면 모드 이름을 규칙 매개변수로 착각할 가능성이 줄어듭니다.

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

이 규칙의 의도는 Config가 요청 처리에 참여하는 상태에서 지정된 도메인 접미사와 일치하는 요청은 PROXY로, 나머지는 DIRECT로 처리하는 것입니다. 검증할 때는 규칙에 매칭되어야 하는 요청과 매칭되지 않아야 하는 요청을 각각 확인하세요. 대상 사이트가 열리는지만 확인해서는 규칙이 올바른지, 전체 모드가 의도한 동작을 덮어썼는지, 대상에 원래 직접 연결할 수 있었는지 구분할 수 없습니다.

모드를 계속 전환하기보다 비교 테스트로 범위를 좁히세요

Proxy에서는 연결되지만 Config에서는 실패한다면 Config에서 사용하는 파일, 정책 참조와 매칭 순서를 먼저 확인하세요. 두 처리 방식에 차이가 있다는 뜻이지만 도메인 규칙이 잘못됐다고 단정할 수는 없습니다. Host 매핑, DNS 설정 또는 앞쪽의 차단 규칙이 차이를 만들었을 수도 있습니다. 두 모드에서 모두 실패하면 규칙을 더 늘리지 말고 서버 설정과 기본 네트워크부터 확인하세요.

Direct에서는 성공하지만 Proxy에서는 실패한다면 프록시 경로를 확인하세요. 대상 도메인 전체를 곧바로 DIRECT로 바꾸지 마세요. 임시로 직접 연결해 비교할 수는 있지만, 요청 경로 자체가 달라져 문제가 우회된 것일 수 있습니다. 연결 수립, 이름 확인, 이후 접속 중 어느 단계에서 실패했는지 기록한 뒤 수정할 부분을 결정하세요. 한 번에 조건 하나만 바꿔야 결과를 명확히 해석할 수 있습니다.

모드를 전환한 뒤에는 대상을 다시 열거나 작업을 새로 실행하세요. 필요하면 기존 연결을 종료한 후 테스트하세요. 장시간 연결은 처음 연결될 때의 처리 방식을 계속 사용할 수 있고, 캐시된 페이지는 새 네트워크 요청이 발생한 것처럼 보이게 할 수 있습니다. 새 요청이 확실히 발생하는 작업을 선택하고 앱에서 확인할 수 있는 연결 기록도 살펴보세요. 자세한 조작 방법은 가이드의 Global Routing 설명을 참고하세요.

DOMAIN: 지정된 호스트 이름만 매칭

DOMAIN은 도메인을 정확히 매칭합니다. example.com을 입력하면 해당 호스트 이름 자체만 매칭되며 모든 하위 도메인에 자동 적용되지는 않습니다. 대상이 명확한 호스트 하나라면 정확한 규칙을 사용하면 검증하기 쉽습니다. 루트 도메인과 하위 도메인을 함께 처리해야 한다면 접미사 규칙을 고려하세요. 정확한 도메인 값에는 프로토콜, 경로, 페이지 쿼리 매개변수를 넣지 마세요. 도메인에 포함되지 않는 정보입니다.

DOMAIN,example.com,DIRECT
DOMAIN,www.example.com,PROXY
DOMAIN,api.example.com,PROXY

이 세 줄은 각각 이름이 완전히 일치하는 호스트를 처리합니다. 두 번째 줄은 첫 번째 호스트를 매칭하지 않으며 세 번째 호스트까지 자동으로 포함하지 않습니다. 한 사이트에서 페이지, 로그인, 이미지, API를 서로 다른 호스트로 제공할 수 있고 브라우저 주소 표시줄에는 그중 일부만 보일 수 있습니다. 메인 페이지는 정상인데 로그인이 실패한다면 실제 실패 요청의 호스트 이름을 확인한 뒤 규칙을 추가할지 결정하세요. 주소 표시줄의 루트 도메인만 보고 서비스 전체가 매칭됐다고 판단하지 마세요.

DOMAIN-SUFFIX: 도메인 경계에 맞는 접미사 매칭

DOMAIN-SUFFIX,example.com,PROXY는 접미사 매칭을 뜻하며 보통 루트 도메인과 www.example.com 같은 하위 도메인을 포함합니다. 아무 위치에나 문자열이 있는지 찾는 규칙은 아니므로 notexample.com은 끝부분이 비슷하다는 이유만으로 같은 접미사로 매칭되지 않습니다. 규칙을 읽을 때는 전체 URL에서 문자열을 검색한다고 생각하지 말고 도메인 레이블의 경계를 확인하세요.

자주 하는 실수는 *.example.com을 접미사 규칙에 반드시 써야 한다고 생각하는 것입니다. 해당 접미사를 표현하려면 example.com만 쓰면 되며 와일드카드를 추가할 필요가 없습니다. 규칙 값 끝에 슬래시도 넣지 마세요. 대상 주소를 복사했다면 전체 URL에서 호스트 이름을 추출하고 프로토콜, 포트, 경로, 쿼리를 제외한 뒤 정확한 규칙과 접미사 규칙 중 무엇을 쓸지 결정하세요.

DOMAIN-KEYWORD: 범위가 넓으므로 오매칭 확인

DOMAIN-KEYWORD는 도메인에 지정된 문자열이 포함되어 있는지 확인합니다. 완전한 도메인 레이블을 경계로 삼지 않으므로 영향 범위를 직관적으로 파악하기 어렵습니다. 여러 도메인에 공통 문자열을 적용해야 하는 경우가 아니라면 열거 가능한 정확한 이름이나 명확한 접미사 규칙을 우선 사용하세요. 키워드가 짧을수록 관련 없는 요청까지 매칭될 가능성이 높고, 나중에 특정 호스트가 프록시 경로로 들어간 이유를 설명하기도 어려워집니다.

DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,REJECT
FINAL,DIRECT

이 순서에서는 정확한 호스트에 먼저 DIRECT를 적용하고, 같은 접미사의 나머지 요청에는 PROXY를 적용합니다. 앞의 두 규칙에 처리되지 않은 도메인 중 키워드를 포함한 항목만 REJECT될 수 있습니다. 이 예시는 세 규칙의 범위 차이를 보여 주기 위한 것이며, 넓은 키워드로 관련된 이름을 모두 차단하라는 뜻이 아닙니다. 세 번째 줄을 앞에 두면 유지하려던 예외가 적용될 기회를 잃을 수 있습니다.

도메인 규칙을 사용하려면 클라이언트가 매칭에 필요한 도메인 정보를 얻을 수 있어야 합니다. 요청이 주소로 직접 연결되면 원래 호스트 이름을 반드시 알아낼 수 있다고 기대해서는 안 됩니다. 반대로 도메인이 여러 주소로 해석되더라도 각 주소마다 규칙을 직접 작성할 필요는 없습니다. 실제 요청 형태에 맞는 방식을 선택하세요. 호스트 이름을 안정적으로 확인할 수 있다면 도메인 규칙을 사용하고, 네트워크 주소 범위를 처리해야 할 때 주소 규칙을 사용하세요.

도메인 규칙을 추가한 뒤에는 루트 도메인, 하위 도메인 하나, 비슷하지만 관련 없는 도메인 하나가 어떻게 처리되는지 확인하세요. 먼저 규칙을 검토하며 예상 결과를 따져 볼 수 있으며, 모든 예시가 실제 접속 가능한 서비스일 필요는 없습니다. 기본 문법을 하나씩 알아보려면 DOMAIN, DOMAIN-SUFFIX 및 기타 규칙 유형 설명을 참고하세요. 다음 절에서는 주소 규칙과 도메인 규칙이 겹칠 때 판단하는 방법을 다룹니다.

IP-CIDR과 IP-CIDR6은 주소 범위를 지정합니다

IP-CIDR은 IPv4 주소 범위에, IP-CIDR6은 IPv6 주소 범위에 사용합니다. 슬래시 뒤 숫자는 접두사 길이이며 포트나 와일드카드 개수가 아닙니다. 단일 IPv4 주소는 /32, 단일 IPv6 주소는 /128로 나타낼 수 있습니다. 네트워크 범위를 넓히면 적용 대상도 늘어납니다. 특정 주소 하나에 연결할 수 없다는 이유로 인접한 넓은 주소 범위 전체를 같은 정책에 넣지 마세요.

IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
IP-CIDR,192.0.2.0/24,PROXY,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve

여기에는 설명용 주소를 사용했으며 실제 서버를 가리키지 않습니다. 첫 번째 줄은 특정 주소에 대한 예외이고 두 번째 줄은 더 넓은 주소 범위입니다. 순서에 따라 예외가 적용될 수 있는지가 달라집니다. IPv6 예시는 다른 주소 체계의 문법을 보여 주며 IPv4 규칙을 대신하지 않습니다. 실제 대상이 두 주소 체계를 모두 반환할 수 있다면 한쪽만 확인하고 전체 접속이 예상대로 처리된다고 판단하지 말고 각각의 결과를 확인하세요.

no-resolve는 규칙 매칭을 위한 추가 DNS 조회를 제어합니다

주소 규칙으로 도메인 요청을 처리하려면 먼저 주소를 확인해야 할 수 있습니다. no-resolve는 해당 규칙의 매칭만을 위해 도메인 조회를 새로 시작하지 않도록 하는 옵션입니다. 이미 사용할 수 있는 주소 정보가 있을 때의 결과는 실제 처리 과정에 따라 판단해야 합니다. 클라이언트 전체의 DNS를 중지하거나 다른 경로의 조회까지 막는다는 뜻은 아닙니다. 이 옵션을 모든 DNS 문제를 해결하는 스위치로 여기면 실제 원인에서 벗어나게 됩니다.

도메인에 따라 안정적으로 트래픽을 분류해야 하는 서비스에는 보통 도메인 규칙이 적합합니다. 명확한 네트워크 범위를 처리해야 할 때 주소 규칙을 사용하세요. 같은 주소를 여러 호스트가 공유할 수 있고, 같은 호스트도 네트워크와 DNS 서버, 시점에 따라 다른 주소를 반환할 수 있기 때문입니다. 한 번 조회한 결과를 장기 규칙으로 고정하면 나중에 바뀐 주소를 놓치거나 같은 주소를 쓰는 다른 서비스에 영향을 줄 수 있습니다.

GEOIP는 주소의 지역 분류이며 웹사이트 식별 기능이 아닙니다

GEOIP,CN,DIRECT는 주소 데이터베이스의 지역 분류에 따라 정책을 선택한다는 뜻입니다. 주소의 지역 정보로 판단할 뿐 웹사이트의 운영 주체나 페이지 내용을 판별하지 않습니다. 분산 인프라를 사용하는 서비스는 도메인으로 파악한 정체성과 접속 주소의 지역 분류가 다를 수 있습니다. 데이터베이스는 갱신되고 분류 경계도 달라질 수 있으므로 한 번의 지역 매칭을 실제 서비스 위치에 대한 영구적인 결론으로 받아들이지 마세요.

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

이 예시는 먼저 명확한 도메인에 경로를 지정하고, 나머지는 주소 분류로 처리한 다음 마지막에 기본 규칙으로 넘깁니다. 의도가 분명한 도메인 규칙이 더 넓은 주소 판정보다 먼저 적용되는 순서입니다. GEOIP를 앞에 두면 관련 주소 범위로 해석된 도메인이 먼저 처리되어 뒤의 도메인 규칙이 적용되지 않을 수 있습니다. 중요한 것은 특정 규칙 유형이 본질적으로 우선이라는 점이 아니라 어떤 규칙이 먼저 조건을 만족하는지입니다.

USER-AGENT는 요청 정보의 확인 가능성에 따라 달라집니다

USER-AGENT는 확인 가능한 요청 헤더 특성으로 매칭하므로 해당 요청 정보가 있는 상황에서 사용할 수 있습니다. 하지만 모든 앱을 확실히 식별하는 방법은 아닙니다. 여러 앱이 같은 값을 사용할 수 있고, 한 앱도 요청에 따라 다른 값을 사용할 수 있습니다. 특히 암호화된 트래픽은 일반적인 네트워크 전달만으로 HTTP 요청 헤더를 읽을 수 있다는 뜻이 아닙니다. 매칭할 필드를 확인할 수 없다면 규칙은 앱 이름만으로 내용을 추측하지 않습니다.

USER-AGENT,ExampleClient*,DIRECT

이 줄은 해당 규칙 유형과 와일드카드 표기법을 설명할 뿐 기기에 그 프로그램이 설치되어 있다는 뜻은 아닙니다. 예시를 매칭시키려고 기기의 보안 설정을 바꾸지 말고, USER-AGENT로 명확하게 표현할 수 있는 도메인 규칙을 대신하지 마세요. 규칙이 적용되지 않는 것 같다면 순서를 확인하기 전에 실제 요청에 예상한 필드가 보이는지부터 확인하세요. 해당 필드를 애초에 확인할 수 없다면 비슷한 규칙을 더 추가해도 도움이 되지 않습니다.

주소, 지역, 요청 특성 규칙은 모두 실제로 확인 가능한 정보에 맞춰 해석해야 합니다. 기록에 대상 주소 하나만 있다면 먼저 그것이 직접 요청의 주소인지, DNS 조회 결과인지, 프록시 서버 주소인지 확인하세요. 세 가지는 서로 다른 대상입니다. 서버로 연결되는 외부 경로를 대상 사이트의 주소로 착각하면 분류 판단이 전부 잘못될 수 있습니다. 구분하기 어렵다면 최소한의 도메인 규칙으로 비교한 뒤 주소 조건을 하나씩 추가하세요.

규칙은 ‘무엇을 매칭할지’, 정책은 ‘어떻게 처리할지’를 정합니다

일반적인 도메인 규칙은 유형, 매칭할 값, 정책으로 구성됩니다. DOMAIN-SUFFIX,example.com,PROXY에서는 앞의 두 항목이 조건을 정하고 마지막 항목이 매칭된 요청의 처리 방식을 정합니다. 마지막 항목을 바꿔도 매칭 범위는 달라지지 않습니다. PROXY를 DIRECT로 바꾸면 같은 도메인에 적용되며 연결 경로만 바뀝니다. 이 구분을 이해하면 정책 문제를 도메인 범위 문제로 잘못 수정하는 일을 줄일 수 있습니다.

PROXY가 사용할 실제 연결 항목은 현재 설정과 앱에서 선택한 항목을 확인해야 합니다. 설정에 사용자 지정 정책 이름이 포함되어 있다면 그 이름이 정의되어 있는지, 해당 구성원이 현재 환경에 맞는지도 확인하세요. 이름에 ‘프록시’라는 뜻이 들어 있다고 해서 현재 선택한 서버를 가리킨다고 단정할 수 없습니다. 규칙을 복사할 때 원본 파일의 사용자 지정 이름을 무심코 남기면 참조하는 이름과 실제 항목이 일치하지 않을 수 있습니다.

DIRECT는 연결 경로를 선택할 뿐 성공을 보장하지 않습니다

DIRECT는 매칭된 요청을 직접 연결 경로로 보내지만 로컬 네트워크, 대상 서비스와 DNS 조회 결과에 따라 접속 여부가 달라집니다. 규칙을 DIRECT로 바꾼 뒤에도 실패한다면 규칙이 매칭되지 않았다고 단정하지 말고 직접 연결 경로를 확인하세요. 반대로 직접 연결에 성공해도 기존 프록시 경로의 인증, 인증서 또는 전송 설정이 정상이라는 뜻은 아닙니다. 정책 선택과 네트워크 연결 여부는 별개의 결과이므로 기록과 실제 접속으로 각각 확인해야 합니다.

REJECT는 요청을 의도적으로 차단하는 동작입니다. 규칙을 추가하기 전에 대상 호스트가 로그인, 인증 또는 페이지 표시에 필요한 리소스를 제공하지 않는지 확인하세요. 이름만 보고 용도를 추측하면 공유 API까지 함께 차단할 수 있습니다. 수정 후 페이지 일부가 표시되지 않으면 새로 추가한 차단 규칙을 잠시 제거하고 다시 테스트하세요. 프록시 예외 추가, DNS 변경, 주소 재작성을 한꺼번에 하지 마세요. 어떤 변경이 기능을 복구했는지 알 수 없게 됩니다.

FINAL에는 도메인 매개변수가 필요하지 않습니다

FINAL은 앞선 규칙에 매칭되지 않은 요청을 처리하는 기본 선택입니다. 일반적인 표기는 FINAL,DIRECT 또는 FINAL,PROXY이며 도메인 규칙처럼 매칭할 값을 추가하지 않습니다. 특정 도메인이 아니라 나머지 요청을 처리하므로 규칙 목록 맨 끝에 둬야 합니다. 앞쪽에 두면 뒤의 일반 규칙에 도달하지 못해 새 규칙을 어떻게 바꿔도 적용되지 않는 것처럼 보일 수 있습니다.

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

이 예시는 정확한 예외 하나, 접미사 범위 하나, 나머지는 직접 연결하는 구조입니다. 기본값으로 프록시를 사용하려면 마지막 줄을 FINAL,PROXY로 바꾸고 기존의 직접 연결 예외 중 유지할 항목을 다시 살펴보세요. 마지막 줄만 복사하고 파일 전체의 기본 방향을 무시하지 마세요. 기본 방향이 바뀌면 앞의 규칙을 그대로 두더라도 열거되지 않은 요청 대부분의 경로가 달라질 수 있습니다.

의도를 명확히 한 다음 기본 처리 방향을 선택하세요

FINAL을 선택하기 전에 목표를 한 문장으로 정리하세요. 지정한 소수의 호스트만 프록시를 사용하고 나머지는 직접 연결할지, 대부분의 요청이 프록시를 사용하고 소수의 예외만 직접 연결할지 결정해야 합니다. 전자는 보통 FINAL,DIRECT와 함께 구성하고, 후자는 예외와 FINAL,PROXY의 관계를 세심하게 관리해야 합니다. 모든 네트워크에 적용되는 정답은 없으며 사용자의 접속 요구와 보유한 연결 조건에 따라 결정해야 합니다.

기본 처리 규칙은 장애 시 자동으로 다른 경로로 전환하지 않습니다. FINAL,PROXY는 앞선 프록시 연결이 실패했을 때 다른 정책을 시도한다는 뜻이 아닙니다. 앞선 매칭 조건이 적용됐는지를 기준으로 처리할 뿐 연결 성공 여부는 판단하지 않습니다. 규칙 매칭과 연결 결과는 서로 다른 단계입니다. 같은 도메인에 서로 다른 정책을 적용하는 규칙 두 개를 연달아 써서 첫 번째가 실패하면 두 번째로 넘어갈 것이라고 기대하지 마세요. 일반적인 순서 매칭은 이런 방식으로 재시도하지 않습니다.

관리하기 쉽도록 규칙 목록에는 명확한 최종 처리 규칙을 하나만 두세요. 파일에 FINAL이 여러 개 있다면 실제로 먼저 적용되는 위치를 확인하고 그 뒤의 무효한 항목을 정리하세요. 삭제하기 전에 복사본을 보관해 다른 섹션의 내용을 규칙으로 착각해 지우지 않도록 하세요. 정리된 설정은 각 일반 규칙의 역할과 나열되지 않은 요청의 처리 경로를 설명할 수 있어야 합니다.

먼저 매칭된 규칙이 ‘더 정확해 보이는’ 규칙보다 우선합니다

일반적인 순서 기반 규칙은 위에서 아래로 확인하며 처음 매칭된 항목이 처리 정책을 결정합니다. DOMAIN이 DOMAIN-SUFFIX보다 항상 우선한다고 가정하거나 파일 뒤쪽의 새 규칙이 기존 규칙을 자동으로 덮어쓴다고 생각하지 마세요. 구체성은 순서를 정할 때 중요하지만 텍스트에 적힌 순서를 무시할 이유는 아닙니다. 넓은 범위 규칙에 가려지면 안 되는 정확한 예외는 해당 규칙보다 앞에 두세요.

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

api.example.com에 접속하면 첫 번째 줄에서 결과가 정해지므로 두 번째 줄까지 확인하지 않습니다. www.example.com은 첫 번째 줄에 매칭되지 않아 두 번째 줄에서 처리됩니다. 목록에 없는 다른 도메인은 마지막 규칙이 처리합니다. 이런 방식으로 실제 연결 전에 규칙을 검토할 수 있습니다. 문서상으로 어떤 규칙이 적용될 기회조차 없다는 점을 확인했다면 원인을 찾으려고 네트워크를 계속 전환할 필요가 없습니다.

사용 사례 1: 지정한 사이트만 프록시 사용

소수의 사이트만 프록시를 사용해야 한다면 먼저 정확한 도메인이나 접미사로 대상을 지정한 뒤 FINAL,DIRECT를 선택하세요. 처음부터 지역, 키워드, 주소 범위 규칙을 많이 추가하면 단순한 의도가 서로 다른 범위에 덮일 수 있습니다. 사이트가 실제로 여러 도메인을 사용한다면 요청 기록을 바탕으로 하나씩 추가하세요. 페이지 이름만 보고 전체 인프라를 추측하거나 지나치게 넓은 공통 문자열을 서비스 전체 범위로 간주하지 마세요.

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

이 최소 예시는 구조를 설명하기 위한 것이며 모든 실제 사이트에 접미사 규칙 하나만 필요하다는 뜻은 아닙니다. 규칙을 추가할 때 API나 정적 리소스처럼 새 호스트의 역할을 기록하고, 추가한 범위에 경로를 바꾸고 싶지 않은 요청이 포함되지 않는지 확인하세요. 자세한 사용 사례는 지정한 사이트만 프록시를 사용하도록 규칙 설정하기를 참고한 뒤 이 페이지로 돌아와 순서를 확인하세요.

사용 사례 2: 기본 프록시를 사용하되 명확한 직접 연결 예외 유지

또 다른 방식은 앞쪽에 명확한 직접 연결 조건을 두고 나머지는 FINAL,PROXY로 처리하는 것입니다. 이때 범위가 넓은 DIRECT 규칙을 추가하면 더 많은 트래픽이 기본 프록시 경로에서 빠집니다. 수정 전에 예외의 근거가 도메인 정체성인지, 네트워크 주소인지, 지역 분류인지 확인하세요. 근거가 다르면 규칙도 달라야 합니다. 편하다는 이유로 도메인과 관계없는 조건을 접미사 규칙 하나로 표현하지 마세요.

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

예시의 두 예외는 각각 호스트 이름과 주소를 기준으로 하므로 서로를 대체하지 않습니다. 첫 번째 조건은 요청에 도메인 정보가 있어야 적용할 수 있고, 두 번째는 주소를 기준으로 하며 no-resolve가 포함되어 있습니다. 실제 문제를 확인할 때는 최종 결과가 모두 DIRECT라는 이유로 둘을 합치지 말고 어떤 규칙이 매칭됐는지 기록하세요. 매칭 근거를 남겨 두면 주소나 요청 형태가 바뀌었을 때 결과 차이를 설명하기 쉽습니다.

충돌 확인과 단계별 관리

충돌이 발견되면 예상한 규칙보다 앞에서 매칭될 수 있는 항목을 모두 확인하세요. 키워드, 지역, 더 넓은 주소 범위도 포함해야 합니다. 전체 도메인 문자열만 검색해서는 안 됩니다. 문자열에 도메인 이름이 없어도 GEOIP 규칙이 먼저 요청을 처리할 수 있습니다. 원인을 찾았다면 정확한 예외를 앞으로 옮기거나 넓은 규칙의 범위를 줄이세요. 파일 여러 위치에 같은 내용을 반복해서 추가하지 마세요.

수정할 때마다 정상 사례와 예외 사례를 모두 테스트하세요. 정상 사례는 대상 요청이 예상한 정책을 따르는지 확인하고, 예외 사례는 적용 범위가 의도치 않게 넓어지지 않았는지 확인합니다. 정상 사례만 테스트하면 넓은 규칙의 오매칭을 오랫동안 알아채지 못할 수 있습니다. 다음에 서로 다른 환경의 결과를 혼동하지 않도록 모드, 설정 이름, 조작 순서를 기록하세요. 민감한 주소나 전체 인증 정보를 적을 필요는 없으며 매칭 근거와 정책 결과만 남기면 됩니다.

중복 규칙을 삭제할 때도 순서를 따져 봐야 합니다. 내용이 완전히 같은 규칙 두 개는 보통 함께 둘 필요가 없지만 비슷해 보이는 조건도 서로 다른 대상을 처리할 수 있습니다. 정리하기 전에 목적을 표시하고 한 번에 하나씩 제거하면서 주요 동작을 테스트하세요. 규칙 정리와 구독 업데이트, 서버 변경을 한꺼번에 하지 마세요. 변경을 나눠야 어느 단계로 되돌아갈 때 원래 동작이 복구되는지 알 수 있습니다.

Host는 이름에 대응하는 주소를 바꾸며 정책을 직접 선택하지 않습니다

[Host]는 호스트 이름을 주소에 매핑합니다. 이름이 어떤 주소에 대응하는지 지정할 뿐 해당 호스트를 PROXY나 DIRECT로 바로 설정하지는 않습니다. 매핑을 적용한 뒤에도 현재 처리 방식에 따라 연결 경로가 결정됩니다. 따라서 이름이 지정한 주소로 해석된다고 해서 분류 정책이 올바른 것은 아닙니다. 정책이 맞더라도 매핑된 주소가 현재 서비스에 유효한 접속 지점이라는 보장은 없습니다.

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

이 주소들은 문서용 예시입니다. 실제로 입력하기 전에 직접 관리하는 서비스에 해당 매핑이 필요한지, 대상 주소를 어떻게 관리하는지 확인하세요. DNS에서 한 번 조회한 주소를 장기간 사용할 수 있는 고정 주소로 간주하면 안 됩니다. 동적으로 접속 위치를 조정하는 서비스에 고정 매핑을 적용하면 정상적인 조정을 우회할 수 있고 네트워크가 바뀌거나 서비스가 이전한 뒤 간헐적인 오류가 생길 수 있습니다. 프록시가 불안정한 것처럼 보여도 실제로는 매핑이 오래된 정보일 수 있습니다.

도메인을 다른 주소에 매핑해도 해당 주소의 서비스에 올바른 인증서, 가상 호스트 설정, 접근 권한이 자동으로 생기지는 않습니다. 암호화된 사이트에 접속할 때는 이름과 인증서 검증이 여전히 중요합니다. 이름이나 인증서 오류가 발생하면 서비스 설정과 매핑이 일치하는지 확인하고 검증을 느슨하게 해 문제를 숨기지 마세요. Host는 대상이 명확할 때 사용하는 설정이지 낯선 서비스의 유효한 주소를 추측하는 용도가 아닙니다.

URL Rewrite는 요청 주소를 처리하며 프록시 설정을 대신하지 않습니다

[URL Rewrite]는 조건에 맞는 URL을 어떻게 다시 쓰거나 리디렉션할지 지정합니다. 매칭 대상이 호스트 이름에 한정되지 않고 주소 구조까지 포함된다는 점에서 DOMAIN 계열 규칙과 다릅니다. 추가하기 전에 접근 경로를 바꾸려는 것인지 네트워크 출구만 바꾸려는 것인지 확인하세요. 후자라면 정책과 분류 규칙으로 처리해야 하며 프록시를 사용하려고 사이트 주소를 다시 쓸 필요는 없습니다.

[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302

이 예시는 지정된 호스트의 HTTP 주소를 해당하는 HTTPS 주소로 리디렉션하며 302는 임시 리디렉션을 나타냅니다. 정규식에서 점을 이스케이프해 도메인 구분자 대신 임의의 문자가 매칭되는 것을 방지합니다. 앞뒤 경계 기호는 매칭 범위를 제한하고 괄호는 경로를 캡처하며 대체 문자열의 $1은 캡처한 값을 참조합니다. 정규식을 복사할 때 백슬래시와 반각 기호를 그대로 유지하고 텍스트 편집기가 전각 문자로 바꾸지 않도록 하세요.

요청 주소를 확인하고 처리할 수 있는지는 프로토콜과 앱의 관련 기능에 따라 달라집니다. 설정에 HTTPS 정규식을 적었다고 해서 모든 암호화 요청의 전체 URL을 읽을 수 있는 것은 아닙니다. 일반적인 트래픽 전달은 암호화된 내용을 볼 수 있다는 뜻이 아닙니다. 이 페이지의 예시는 인증서 신뢰 설정을 바꾸는 방식으로 구현하지 않습니다. 재작성을 학습할 때는 직접 관리하고 조건이 명확한 테스트 요청을 사용하고 낯선 사이트까지 처리 범위를 넓히지 마세요.

순환, 과도하게 넓은 범위, 인증 정보 노출 방지

리디렉션된 주소가 같은 조건을 다시 만족하면 순환이 발생할 수 있습니다. 규칙을 작성할 때 입력 주소와 출력 주소를 나란히 비교해 프로토콜, 호스트 또는 경로 중 적어도 하나가 바뀌어 새 요청이 기존 매칭 범위를 벗어나는지 확인하세요. 연속 리디렉션은 대상 사이트의 응답에서 비롯될 수도 있으므로 브라우저 안내만 보고 로컬 규칙에 순환이 있다고 단정하지 마세요. 먼저 로컬 재작성을 비활성화해 비교하고 원래 서비스도 계속 리디렉션하는지 확인하세요.

대체 대상이 바뀌면 요청에 포함된 정보가 전달되는 곳도 달라질 수 있습니다. 쿼리 매개변수가 포함된 전체 주소를 다른 호스트로 함부로 바꾸지 마세요. 로그인 상태, 일회용 매개변수, 앱 내부 이동은 대상 이름에 따라 달라질 수 있습니다. 테스트에는 실제 인증 정보가 없는 예시만 사용하고 경로와 쿼리가 의도대로 유지되는지 확인하세요. 정규식 매칭에 성공했다는 것은 텍스트 조건이 맞았다는 뜻일 뿐 업무 흐름이 정상이라는 보장은 아닙니다.

Host와 URL Rewrite는 각각 따로 검증하세요. 먼저 매핑만 활성화해 이름과 주소가 맞고 접속도 정상인지 확인한 다음 재작성 규칙을 하나만 추가해 예상한 리디렉션이 발생하는지 살펴보세요. 둘을 동시에 바꾸면 잘못된 주소 때문인지 새 URL 때문인지 알아내기 어렵습니다. 복구할 때는 이번에 추가한 항목을 되돌리고 요청을 새로 발생시키세요. 기존 연결이나 캐시된 리디렉션이 판단에 영향을 주지 않도록 합니다.

페이지 결과를 추측의 근거로 삼지 말고 실제 요청에서 규칙을 확인하세요

트래픽 분류를 검증할 때는 세 가지를 함께 확인하세요. 새 요청이 발생했는지, 어떤 조건에 매칭됐는지, 마지막에 어떤 정책을 사용했는지입니다. 페이지가 열리는지는 최종 결과일 뿐 앞의 두 질문에 답하지 못합니다. 반대로 규칙이 올바른 경로를 선택했더라도 페이지가 실패할 수 있습니다. 앱에서 확인할 수 있는 연결 및 진단 정보와 함께 대상 호스트와 관련 규칙을 기록하세요. 모든 실패를 규칙 오류로 뭉뚱그리지 마세요.

먼저 기본 네트워크가 동작하는지 확인한 뒤 Global Routing과 현재 설정 이름을 점검하고 저장 및 불러오기 상태를 확인하세요. 다음으로 대상 요청을 새로 발생시키고 규칙 순서에 따라 처음 매칭되는 조건을 찾으세요. 정책이 예상과 일치한다고 확인한 뒤에 서버 연결, 프로토콜 매개변수, 대상 서비스 상태를 점검하면 됩니다. 이 순서를 따르면 불필요한 수정과 서버 장애를 장기간 사용할 직접 연결 예외로 처리하는 일을 줄일 수 있습니다.

Connectivity Test와 실제 서비스 접속은 각각 다른 부분을 확인합니다

Connectivity Test 결과는 앱에서 선택한 테스트 방식과 함께 해석해야 합니다. 연결 점검에 참고할 수 있지만 실제 서비스가 사용하는 모든 도메인, 경로, 프로토콜 조건을 확인하는 것은 아닙니다. 테스트가 성공해도 실제 대상에 접속해 확인해야 합니다. 실패했다면 현재 환경에 적절한 테스트 대상인지도 살펴보세요. 화면에 표시된 하나의 결과로 전체 연결 경로가 정상이라고 단정하거나 테스트 수치를 규칙 매칭의 증거로 삼지 마세요.

서버 연결이 시간 초과되면 주소, 포트, 인증 정보와 프로토콜 매개변수가 사용자가 보유한 정보와 일치하는지 먼저 확인하세요. TLS를 사용하는 경우 이름과 시스템 시간도 확인해야 합니다. 매개변수 오류를 도메인 규칙으로 숨기지 마세요. 단계별 확인 방법은 서버 연결 시간 초과 확인 순서를 참고하세요. 자주 발생하는 연결 문제는 연결 문제 FAQ에 정리되어 있습니다.

예외를 쌓기보다 최소 구성으로 재현하세요

복잡한 설정으로 원인을 파악하기 어렵다면 복사본에 명확한 대상 규칙 하나와 FINAL 하나만 남기고 관련 없는 매핑과 재작성을 잠시 제외한 뒤 같은 작업을 테스트하세요. 최소 설정에서 예상대로 동작한다면 원래 규칙을 묶음별로 복구해 결과를 바꾸는 항목을 찾으세요. 이렇게 단순화하는 것은 원인을 찾기 위한 임시 방법입니다. 확인 없이 장기 설정을 대체하지 말고 복구한 뒤 기존에 의존하던 다른 기능도 다시 테스트하세요.

테스트 중에는 네트워크, 서버 선택, 접속 동작을 최대한 일정하게 유지하세요. 네트워크를 바꾸면 이름 확인과 연결 조건이 달라지고, 서버를 바꾸면 프록시 경로가 달라지며, 구독을 업데이트하면 항목 매개변수가 바뀔 수 있습니다. 이런 변경을 한꺼번에 하면 성공이나 실패의 원인을 알 수 없습니다. 비교를 위해 네트워크를 바꿔야 한다면 전후 조건을 기록하고 규칙 수정과 같은 테스트에 섞지 마세요.

업데이트, 되돌리기, 안전한 공유

설정을 관리할 때는 정상 동작하는 기준 파일을 보관하세요. 큰 변경을 하기 전 파일을 복사하고 변경 목적, 관련 섹션, 예상 동작을 기록하세요. 완료한 뒤에는 같은 주요 작업으로 다시 확인합니다. 구독 가져오기와 업데이트 방법은 구독 가져오기 및 업데이트 안내를 참고하세요. 업데이트 후 차이가 생기면 먼저 내용을 비교해 서버 정보와 규칙 파일 중 무엇이 바뀌었는지 확인한 다음 어느 항목을 복구할지 결정하세요.

다른 사람에게 문제를 설명할 때는 꼭 필요한 최소 설정 조각, 모드, 매칭 결과만 제공하세요. 전체 구독 주소와 인증 정보, 실제 서버 정보, 개인의 접속 기록을 드러낼 수 있는 내용은 삭제하세요. 설정 파일에는 규칙 외에 민감한 설정이 들어 있을 수 있습니다. 코드 일부에 도메인만 보인다는 이유로 파일 전체를 공유하지 마세요. 결과 화면을 보여 줄 때도 개인 정보가 기록에 포함되어 있는지 확인하세요.

원본 파일을 복구한 뒤에도 선택 상태를 다시 확인해야 합니다. 복사본의 이름을 원래대로 바꿨다고 해서 되돌리기가 완료된 것은 아닙니다. 파일을 다시 불러오고 요청을 새로 발생시켜 예상 도메인, 반례, 기본 처리 결과를 확인하세요. 기존 연결에서만 문제가 계속되면 연결을 종료한 뒤 다시 테스트하세요. 새 요청에서도 문제가 발생하면 모드, 규칙, 정책, 연결 경로 순서로 점검하고 같은 규칙을 계속 다른 문법으로 고쳐 쓰지 마세요.