공식 매뉴얼 · 설정 및 규칙

Shadowrocket 규칙 가이드
설정 구조와 매칭 참고

처음 연결할 때는 어디서 시작해야 하나요? 먼저 빠른 시작 가이드에 따라 기존 구독을 가져오고 서버를 선택한 다음 연결을 확인하세요. 이 페이지에서는 이후에 참고할 설정을 체계적으로 살펴봅니다. 설정의 각 섹션이 어떻게 함께 작동하는지, 규칙이 순서대로 매칭되는 이유와 변경 결과를 확인하는 방법을 설명합니다.

이 페이지는 이미 구독이나 서버 정보를 보유하고 있다는 전제로 작성되었습니다. 앱의 일회성 구매와 연결 서비스 요금제는 별개입니다. 이 사이트는 노드나 구독을 제공·판매·추천하지 않습니다. 앱의 출처를 확인하려면 먼저 App Store 정식 앱 확인 안내를 읽어보세요. Shadowrocket을 받을 수 있는 곳은 App Store뿐이며, 기기 호환성 및 시스템 요구 사항은 App Store 페이지의 안내를 따릅니다.

01 설정 파일 구조와 적용 범위

설정과 구독은 같은 내용인가요?

아닙니다. 구독은 보통 서버 연결 정보를 관리하는 데 사용하고, 설정 파일은 요청을 어떻게 처리할지 설명합니다. 예를 들어 어떤 정책을 선택할지, 어떤 도메인 규칙을 적용할지, 특정 DNS 조회나 재작성 동작이 필요한지 등을 정의합니다. 기존 구독을 가져온 뒤 서버 목록에 항목이 표시되더라도 규칙 설정이 적용되었다는 뜻은 아닙니다. 문제를 확인할 때는 Home에서 선택할 수 있는 서버, Config에서 현재 사용하는 설정, Global Routing 상태를 각각 확인해야 합니다. 어느 하나의 확인으로 다른 항목까지 검증했다고 볼 수는 없습니다.

어느 부분부터 살펴봐야 하나요? 먼저 대괄호로 둘러싸인 섹션 이름을 찾고, 그 안의 행을 읽으세요. 섹션마다 문법이 다릅니다. General에는 키-값 설정이, Rule에는 행별 매칭 조건이, Host에는 도메인과 주소 매핑이, URL Rewrite에는 매칭 표현식과 동작이 들어갑니다. 도메인 규칙을 General에 붙여 넣지 마세요. 텍스트가 저장된다고 해서 의도한 기능으로 해석된다는 보장은 없습니다.

[General]
dns-server = system

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

[Host]
portal.example.com = 192.0.2.10

이 최소 예시는 무엇을 나타내나요?

General에서는 시스템 DNS 설정을 사용하고, Rule에서는 예시 도메인 접미사를 먼저 처리한 뒤 주소의 지역 정보를 확인하고 마지막으로 기본 정책을 지정합니다. Host의 주소는 문서 예시용 주소 범위에 속하며 매핑 형식만 보여줍니다. 서버 연결 인증 정보는 없고, 사용 가능한 설정 전체를 담은 것도 아닙니다. PROXY로 실제 연결할 수 있는지는 현재 선택된 서버와 그 매개변수에 달려 있습니다. 예시를 복사할 때는 특정 영문 키워드만 보지 말고 어느 섹션에 있는지도 함께 확인하세요.

되돌릴 수 있도록 편집하려면 어떻게 해야 하나요? Config에서 현재 사용하는 설정을 찾아 원본을 보관한 다음 알아보기 쉬운 이름의 사본을 만드세요. 변경 전 Global Routing 모드, 현재 서버, 검증할 도메인을 기록합니다. 매번 DOMAIN 규칙 하나를 추가하는 식으로 논리적으로 한 부분만 수정하세요. DNS, 서버, 기본 정책을 한꺼번에 바꾸지 마세요. 저장한 뒤 실제 사용 중인 설정이 사본인지 다시 확인하세요. 설정 파일 A를 편집하고 파일 B로 테스트하는 일을 방지할 수 있습니다.

General 설정을 전부 그대로 복사해야 하나요?

그럴 필요 없습니다. General은 기본 동작을 설정하는 섹션이므로 구체적인 문제에 맞춰 항목별로 확인해야 합니다. 기존 설정에는 DNS, 연결 처리, 네트워크 관련 옵션이 이미 들어 있을 수 있습니다. 전체를 교체하면 정상 작동하던 부분까지 바뀔 수 있습니다. 익숙하지 않은 키는 앱 내 편집 화면에서 이름과 허용 값을 확인하고, 의미를 알 수 없다면 기존 값을 유지하세요. 이 가이드는 명확히 설명할 수 있는 예시만 제공하며, 매개변수를 계속 추가해 이른바 범용 설정을 만들도록 권장하지 않습니다.

원격 설정을 업데이트하면 로컬 수정 사항은 어떻게 되나요? 현재 파일이 원격 출처에서 제공된 경우, 업데이트 후 편집 내용이 유지되는지는 앱에서 실제로 확인해야 합니다. 모든 수정 사항이 자동으로 병합된다고 가정하지 마세요. 원본과 로컬 테스트 사본을 보관하고, 업데이트 후 직접 수정한 규칙을 비교하는 편이 안전합니다. 동작이 달라졌다면 서버에 문제가 있다고 바로 판단하지 말고 적용된 파일, 규칙 순서, 기본 설정부터 비교하세요.

메모에는 어떤 내용을 적으면 좋나요? 규칙의 목적, 테스트 대상, 되돌리는 방법을 기록할 수 있습니다. 공개할 예시에는 본인의 구독 주소, 비밀번호나 다른 연결 인증 정보를 넣지 마세요. 문제 해결 정보를 공유할 때는 섹션 이름, 키워드, 순서를 남기면 됩니다. 민감한 항목을 제거한 뒤에는 스크린샷이나 텍스트에 쿼리 매개변수가 남아 있는지도 확인하세요. 설정은 실행 가능한 네트워크 동작을 정의하는 문서이지, 단순히 저장해 두는 텍스트 목록이 아닙니다.

02 도메인 규칙의 매칭 범위

DOMAIN과 DOMAIN-SUFFIX는 어떻게 선택하나요?

도메인 하나만 정확히 처리하려면 DOMAIN을, 루트 도메인과 하위 도메인을 함께 처리하려면 DOMAIN-SUFFIX를 사용하세요. 예를 들어 DOMAIN,api.example.com,PROXY는 해당 도메인만 대상으로 하며 다른 호스트 이름까지 자동으로 포함하지 않습니다. DOMAIN-SUFFIX,example.com,PROXY는 example.com과 그 하위 도메인에 적용됩니다. 두 규칙의 차이는 대상 범위이지 연결 속도가 아니며, 어느 한 문법이 본질적으로 우선하는 것도 아닙니다.

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

위의 두 행은 왜 서로 충돌하지 않나요? 첫 번째 행은 api.example.com을 먼저 매칭해 예외적으로 PROXY를 사용합니다. 두 번째 행은 같은 도메인 영역의 나머지 요청을 처리합니다. 순서를 바꾸면 범위가 넓은 접미사 규칙이 먼저 매칭되어 정확한 예외가 작동하지 않을 수 있습니다. 규칙을 작성할 때는 예외를 먼저, 공통 범위를 나중에 적으세요. 범위와 순서를 명확히 이해해야 같은 루트 도메인 아래의 요청마다 정책이 달라지는 이유를 설명할 수 있습니다.

키워드	매칭 대상	주요 범위
`DOMAIN`	정확한 도메인	다른 하위 도메인은 자동으로 포함하지 않음
`DOMAIN-SUFFIX`	도메인 접미사	루트 도메인과 하위 도메인을 포함
`DOMAIN-KEYWORD`	도메인에 포함된 키워드	서로 다른 도메인까지 범위가 확장될 수 있음

DOMAIN-KEYWORD를 신중하게 써야 하는 이유는 무엇인가요?

지정한 키워드가 도메인에 포함되어 있는지를 기준으로 판단할 뿐, 웹사이트의 소속을 판별하지는 않습니다. 짧은 단어는 서로 관련 없는 여러 도메인에 들어갈 수 있습니다. 브랜드명이나 일반적인 단어를 키워드로 사용하면 매칭 범위가 넓어질 수 있습니다. example.com만 처리하려는 경우에는 보통 정확한 도메인 규칙이나 접미사 규칙을 사용하세요. 도메인에서 흔한 단어 하나를 떼어 키워드로 삼는 방법은 적절하지 않습니다. 규칙이 매칭된다는 것과 매칭 범위가 의도에 맞는다는 것은 별개의 문제입니다.

[Rule]
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECT

이 예시는 키워드 정책을 권장하나요? 아닙니다. 문법을 보여주기 위한 예시입니다. 실제로 사용하기 전에 포함하려는 도메인과 제외하려는 도메인을 각각 몇 개씩 적어 키워드가 제외 대상까지 잘못 매칭하지 않는지 확인하세요. 범위를 분명하게 제한할 수 없다면 DOMAIN 또는 DOMAIN-SUFFIX를 사용하세요. 규칙을 유지 관리할 때는 특히 여러 사람이 읽거나 오랫동안 사용할 설정이라면, 줄 수를 줄이는 것보다 ‘왜 매칭되는지’를 정확히 설명할 수 있는 것이 중요합니다.

도메인 규칙에 전체 URL을 적어야 하나요?

아닙니다. 도메인 조건에는 https://, 포트, 경로, 쿼리 매개변수를 넣지 않습니다. api.example.com은 도메인이지만 https://api.example.com/account는 전체 URL입니다. 후자를 DOMAIN의 매개변수로 그대로 사용할 수 없습니다. 페이지 경로에 따라 요청을 구분하려는 것은 다른 문제이며, 도메인 규칙 뒤에 슬래시를 붙인다고 해결되지 않습니다. 먼저 입력을 도메인, 포트, 경로로 나눈 다음 현재 규칙 유형이 해당 요소를 확인할 수 있는지 살펴보세요.

같은 웹페이지에서도 정책이 달라지는 이유는 무엇인가요? 웹페이지는 메인 사이트, 이미지, API, 다른 리소스 도메인에 동시에 요청을 보낼 수 있습니다. 주소 표시줄에 보이는 도메인에만 규칙을 추가해도 모든 리소스에 자동으로 적용되지는 않습니다. 확인할 때는 페이지 이름으로 추측하지 말고 실제 요청 대상 도메인을 살펴보세요. 일부 콘텐츠가 로드되지 않으면 먼저 실패한 리소스의 도메인을 찾고 필요한 범위에만 규칙을 추가하세요. 하나의 리소스 때문에 모호한 키워드 규칙으로 범위를 넓히지 마세요.

도메인 규칙이 예상대로 매칭되지 않는 이유는 무엇인가요? 요청이 IP 주소를 직접 사용하거나 앱에서 확인할 수 있는 대상 정보가 예상과 다를 수 있습니다. 먼저 기록에 해당 도메인이 실제로 있는지 확인한 뒤 조건의 오타를 살펴보세요. 대소문자, 불필요한 공백, 복사 과정에서 들어간 전각 문장 부호도 확인해야 합니다. 규칙의 기본 개념은 규칙 키워드 입문에서 더 살펴볼 수 있습니다. 실제 문제 해결에서는 앱에서 확인한 요청 대상을 기준으로 판단하세요.

03 IP, GEOIP와 USER-AGENT

IP-CIDR의 슬래시 뒤 숫자는 무엇을 뜻하나요?

네트워크 접두사 길이로, 주소 범위를 정하는 값입니다. 포트나 규칙 우선순위가 아닙니다. IPv4에서 /32는 단일 주소를 뜻하며 /24는 흔히 256개 주소가 포함된 네트워크 블록을 나타냅니다. 범위가 넓을수록 더 많은 대상이 포함될 수 있습니다. 작성하기 전에 단일 호스트를 처리할지 네트워크 전체를 처리할지 확인하세요. 주소가 비슷해 보인다는 이유만으로 접두사 길이를 임의로 줄이지 마세요. 범위가 잘못되면 관련 없는 요청까지 같은 정책을 따를 수 있습니다.

[Rule]
IP-CIDR,192.0.2.25/32,DIRECT
IP-CIDR,198.51.100.0/24,PROXY
IP-CIDR6,2001:db8::/32,DIRECT
FINAL,DIRECT

이 주소로 서비스를 테스트할 수 있나요? 안 됩니다. 문서에 사용하는 예시 주소입니다. 첫 번째 행은 단일 주소 규칙, 두 번째 행은 IPv4 네트워크 범위, 세 번째 행은 IPv6 접두사를 보여줍니다. IP-CIDR6과 IP-CIDR은 서로 다른 주소 계열을 처리합니다. IPv4 규칙 하나를 작성해도 같은 서비스의 IPv6 주소까지 자동으로 포함되지는 않습니다. 기기가 두 주소 계열을 모두 할당받는다면 실제 요청에 사용된 대상을 확인하세요. 주소 계열이 바뀐 현상을 규칙이 무작위로 작동하지 않는 것으로 오해하지 않도록 주의해야 합니다.

no-resolve는 언제 고려해야 하나요?

IP 규칙은 도메인에서 주소를 조회한 다음 범위를 확인하는 과정과 관련될 수 있습니다. no-resolve는 해당 규칙을 위해 별도로 도메인을 조회하지 않겠다는 의도를 나타냅니다. 앱 전체에서 DNS를 중지한다는 뜻도, 요청에 주소 정보가 절대 나타나지 않는다는 보장도 아닙니다. 요청 자체가 IP이거나 사용할 수 있는 주소가 이미 있다면 실제 조건에 따라 매칭을 판단해야 합니다. 사용하기 전에 이 규칙이 이미 알고 있는 주소만 처리할지, 도메인 조회 결과까지 범위에 포함할지 정하세요.

[Rule]
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

모든 IP 규칙에 같은 옵션을 붙이지 않는 이유는 무엇인가요? 이 옵션은 도메인 요청이 해당 규칙에 도달했을 때의 처리 조건을 바꿉니다. 조회 결과를 통해 식별하려는 대상에 추가 조회를 제한하면 이후 FINAL을 사용하는 경우가 늘어날 수 있습니다. 반면 이미 알려진 IP의 예외만 처리하려는 경우에는 목적에 맞을 수 있습니다. 한 대상을 기준으로 변경 전후의 기록을 비교하세요. 옵션이 많을수록 설정이 완전해진다는 식으로 작성하지 마세요. 사용할 수 있는 문법도 현재 앱에서 확인해야 합니다.

GEOIP는 웹사이트가 어느 지역에 속하는지 나타내나요?

아닙니다. GEOIP는 대상 IP의 지리적 위치 데이터에 따라 판단하며 웹사이트의 언어, 등록 정보, 페이지 내용으로 결과를 추론하지 않습니다. CDN을 사용하는 도메인은 서로 다른 주소로 확인될 수 있고 네트워크를 바꾸면 위치 판정도 달라질 수 있습니다. GEOIP,CN,DIRECT는 해당 지역 정보에 매칭된 요청에 DIRECT를 적용한다는 뜻입니다. ‘중국어 웹사이트는 모두 직접 연결’하거나 ‘특정 도메인은 앞으로 계속 같은 정책을 사용한다’는 의미가 아닙니다.

도메인 규칙을 GEOIP보다 앞에 둬야 하는 경우는 언제인가요? 도메인에 특정 정책을 적용하고 주소 변화가 판단에 영향을 주지 않게 하려면 명확한 도메인 예외를 앞쪽에 배치하세요. GEOIP는 넓은 주소 분류에 적합하지만 모든 세밀한 규칙을 대신할 수는 없습니다. 같은 서비스가 네트워크마다 다르게 동작한다면 먼저 조회된 주소와 매칭된 규칙을 비교한 뒤 도메인 예외를 추가할지 결정하세요. 지역 범위를 계속 조정하는 방식은 피하는 것이 좋습니다.

USER-AGENT로 앱별 트래픽을 안정적으로 분기할 수 있나요?

USER-AGENT를 범용적인 앱 식별 방법으로 간주해서는 안 됩니다. 이 규칙은 시스템의 앱 이름이 아니라 요청에서 확인할 수 있는 해당 필드를 매칭합니다. 암호화된 연결에서 필드를 확인할 수 있는지, 요청에 필드가 포함되는지에 따라 규칙이 작동할 가능성이 달라집니다. 여러 앱이 같은 문자열을 쓸 수 있고, 한 앱도 서로 다른 문자열을 보낼 수 있습니다. 먼저 실제 필드를 확인한 다음 매칭 표현식을 검토하세요.

[Rule]
USER-AGENT,ExampleClient*,DIRECT
FINAL,PROXY

이 예시는 USER-AGENT의 위치와 와일드카드 문법만 보여줍니다. ExampleClient라는 실제 요청이 있다는 뜻은 아닙니다. 기록에서 확인 가능한 필드가 없다면 이미 확인된 도메인이나 주소 조건을 우선 사용하세요. 이 규칙이 매칭되도록 하려고 암호화된 트래픽의 처리 범위를 넓히지 마세요. 규칙 조건을 확인할 수 없는 문제와 서버를 사용할 수 없는 문제는 서로 다르므로 각각 확인해야 합니다.

04 Global Routing과 연결 정책

Config, Proxy, Direct와 규칙의 정책은 같은 뜻인가요?

완전히 같지는 않습니다. Global Routing은 전체 라우팅 모드를 선택하는 곳입니다. 규칙 끝의 PROXY, DIRECT, REJECT는 특정 규칙이 매칭됐을 때 적용할 처리 정책입니다. 인터페이스 이름은 Config, Proxy, Direct로 표기하고 규칙 키워드는 설정 문법에 따라 대문자로 씁니다. 문제를 확인하기 전에 전체 모드를 먼저 살펴보세요. Rule의 조건과 순서가 정확해도 현재 설정 규칙을 따르는 모드가 아니면 예상한 결과를 확인하기 어려울 수 있습니다.

인터페이스 모드	설명	확인할 항목
Config	구성	현재 설정의 규칙에 따라 정책을 선택
Proxy	프록시	프록시 경로를 비교할 때 사용하며 규칙 검증을 대신하지 않음
Direct	직접 연결	직접 연결 경로를 비교할 때 사용

위 표는 어떤 상황에서도 모든 트래픽이 똑같이 처리된다는 뜻인가요? 아닙니다. 네트워크 연결 상태, 시스템 동작, 설정에 포함된 관련 옵션이 실제 요청에 영향을 줄 수 있습니다. 표에서 구분하는 것은 라우팅 방식을 확인하는 메뉴입니다. Rule을 검증하려면 Config로 돌아가세요. 두 연결 경로를 잠시 비교하려면 Proxy 또는 Direct를 사용할 수 있지만, 테스트가 끝나면 원래 모드로 되돌리고 기록에 모드 변경 과정을 남겨야 합니다.

PROXY는 특정 서버 하나를 뜻하나요?

그렇게 이해해서는 안 됩니다. PROXY는 프록시를 통해 처리한다는 뜻이며 실제로 어느 서버를 사용할지는 현재 선택과 설정을 함께 확인해야 합니다. 규칙에서 PROXY가 매칭된 것은 라우팅 정책이 선택되었다는 의미일 뿐, 서버 주소, 포트, 인증 또는 전송 매개변수가 올바르다는 뜻은 아닙니다. 이미 보유한 서버 정보를 사용할 때는 원래 자료와 항목별로 대조하세요. 인증 오류를 해결하려고 DOMAIN-SUFFIX를 반복해서 바꾸지 마세요. 서로 다른 계층의 문제입니다.

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

DIRECT는 Shadowrocket을 끄는 것과 같은가요? 아닙니다. DIRECT는 매칭된 요청을 직접 연결하도록 선택한다는 뜻입니다. 앱의 연결 스위치가 꺼진 것도 아니고 다른 요청까지 같은 경로를 사용한다는 뜻도 아닙니다. Config 모드에서는 일부 요청이 DIRECT를, 다른 요청이 PROXY를 사용할 수 있습니다. 특정 요청을 판단할 때는 해당 요청의 매칭 결과를 확인하세요. 시스템 상태 표시줄이나 연결 스위치만 보고 특정 대상의 연결 경로를 판단하지 마세요.

연결 시간 초과를 해결하는 데 REJECT를 써도 되나요?

적절하지 않습니다. REJECT는 매칭된 요청을 적극적으로 거부하는 정책이며, 보통 시작하지 않으려는 연결에 사용합니다. 대체 서버가 아니며 시간 초과 후 자동으로 복구하는 기능도 아닙니다. 도메인에 REJECT를 추가하면 관련 페이지 리소스나 앱 기능에 영향을 줄 수 있습니다. 테스트할 때는 거부 대상이 메인 페이지인지, API인지, 보조 리소스인지 확인하세요. 화면 일부가 비어 있더라도 반드시 오류인 것은 아닙니다. 거부 규칙의 결과일 수 있습니다.

최소한의 정책 테스트는 어떻게 설계하나요? 알아보기 쉬운 대상 하나를 선택하고 규칙 앞부분에 정확한 DOMAIN 규칙을 추가하세요. 먼저 DIRECT로 설정해 확인한 다음 PROXY로 바꿔 비교합니다. 서버, DNS, 네트워크는 그대로 두고 정책 하나만 비교하세요. 두 경로 모두 실패하면 도메인 조회, 대상 접근성, 서버 매개변수를 확인해야 합니다. 한쪽 경로만 성공한다면 실패한 경로를 추가로 살펴보세요. 설정 파일 전체를 바로 다시 작성하지 마세요.

앱 구매만으로 PROXY를 사용할 수 없는 이유는 무엇인가요? App Store에서 앱을 한 번 구매해도 사용자의 서버 연결 정보가 자동으로 입력되지는 않습니다. 앱의 출처, 서버 상태, 규칙 선택을 각각 확인해야 합니다. 구매 및 복원 문제는 문제 해결을, 프로토콜 매개변수는 프로토콜 필드 설명을 참고하세요. 이 장에서는 정책과 모드만 설명하며 연결 서비스 정보를 제공하지 않습니다.

05 매칭 순서, 예외와 FINAL

규칙은 유형별로 자동 정렬되나요?

아닙니다. Rule은 위에서 아래로 확인하며 매칭되면 해당 정책을 적용하는 구조입니다. DOMAIN이 더 구체적이라는 이유만으로 DOMAIN-SUFFIX 앞에 자동 배치되지는 않습니다. 뒤에 있는 규칙이 앞의 규칙을 자동으로 덮어쓰지도 않습니다. 파일을 자동으로 최적의 결과를 계산하는 태그 모음이 아니라 순서가 있는 판단 과정으로 보고 편집하세요. 매칭 결과를 설명하려면 파일을 위에서부터 읽으며 조건에 처음으로 맞는 규칙을 찾아야 합니다.

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

이 예시를 행별로 읽으려면 어떻게 하나요? 먼저 대상이 api.example.com인지 확인합니다. 맞으면 PROXY를 사용하며 뒤의 접미사 규칙으로 결과를 바꾸지 않습니다. 아니라면 대상이 example.com 도메인 범위에 속하는지 확인하고, 이어서 주소 예외와 GEOIP를 살펴봅니다. 앞의 규칙에서 아무것도 매칭되지 않을 때 FINAL이 처리합니다. 이 순서는 유지 관리 방법도 보여줍니다. 구체적인 예외를 먼저, 범위 분류를 나중에 두고 기본 처리를 마지막에 배치하세요. 각 규칙을 그 위치에 둔 이유를 설명할 수 있어야 합니다.

FINAL을 신중하게 정해야 하는 이유는 무엇인가요?

FINAL은 앞선 규칙에 매칭되지 않은 요청에 적용되는 최종 정책입니다. 주석도 아니고 오류가 날 때만 쓰는 예비 항목도 아닙니다. 설정의 범위가 불완전하면 많은 요청이 여기에 도달할 수 있습니다. FINAL,DIRECT와 FINAL,PROXY는 서로 다른 기본 경로를 선택합니다. 모든 상황에 맞는 단일 정답은 없습니다. 정하기 전에 규칙이 주로 어떤 대상을 나열하는지, 목록에 없는 요청은 어떤 경로를 따라야 하는지 판단하세요. 익숙해 보이는 마지막 행을 그대로 복사하지 마세요.

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

이 간단한 설정은 어떤 방식으로 구성되나요? 예시에 나열된 도메인만 프록시로 보내고 나머지는 DIRECT로 처리합니다. ‘명시적으로 허용한 대상만 직접 연결’하려는 경우에는 앞부분의 규칙을 다시 구성하고 적절한 기본 정책을 선택해야 합니다. FINAL만 바꾸고 모든 동작이 여전히 예상대로라고 가정해서는 안 됩니다. 기본 정책을 바꾸면 목록에 없는 모든 대상에 영향을 주므로 테스트 범위도 넓혀야 합니다. 최소한 예외 하나와 목록에 없는 대상 하나를 확인하세요.

중복 규칙을 추가하면 매칭이 더 정확해지나요?

아닙니다. 앞에 같은 조건의 규칙이 이미 있다면 뒤에 중복 행을 추가해도 보통 문제가 해결되지 않습니다. 정책이 서로 다르면 나중에 관리하는 사람이 뒤의 설정이 적용되는 것으로 오해할 수 있습니다. 중복을 삭제하기 전에 조건이 실제로 같은지 확인하세요. 예를 들어 DOMAIN과 DOMAIN-SUFFIX는 중복 규칙이 아닙니다. 목적에 따라 ‘정확한 예외’, ‘도메인 범위’, ‘주소 범위’, ‘최종 정책’으로 묶을 수 있지만 보기 좋게 정리하려고 검증된 우선순위를 바꾸지는 마세요.

규칙을 추가한 뒤 앞선 규칙이 가리는지 어떻게 확인하나요? 대상 도메인을 사용해 첫 행부터 시뮬레이션하고 새 규칙보다 앞에 더 넓은 조건이 매칭되는지 찾으세요. 그런 조건이 있다면 새 규칙을 위로 옮길지, 기존 규칙의 범위를 좁힐지 판단합니다. 새 규칙을 모두 파일 끝에 넣지 마세요. 특히 FINAL 뒤에 배치해 기본 처리 전에 적용되길 기대해서는 안 됩니다. 범위가 겹치는 규칙은 변경 기록에 어떤 규칙이 예외인지, 왜 우선하는지 분명히 적으세요.

규칙 순서를 바꿨는데 기존 연결에 바로 반영되지 않는 이유는 무엇인가요?

규칙 판단은 연결 생성과 관련이 있습니다. 이미 연결된 장기 연결이나 재사용 연결은 이전 처리 결과를 이어갈 수 있습니다. 설정을 저장한 뒤 새 요청을 시작해 테스트하세요. 중요한 작업에 영향이 없음을 확인한 경우 필요하면 다시 연결합니다. 기존 연결을 재사용하는 페이지를 새로고침하는 것만으로 저장에 실패했다고 판단하지 마세요. 비교할 때는 요청, 네트워크, 서버를 동일하게 유지하고 기존 연결의 지속과 새 연결의 잘못된 규칙 매칭을 구분해야 합니다.

규칙 변경이 다른 요청에 영향을 주지 않았다는 것을 어떻게 확인하나요? 대상 예외뿐 아니라 같은 접미사를 사용하는 다른 하위 도메인, 관련 없는 도메인 하나, 주소 대상 하나도 테스트하세요. 가장 중요하게 생각하는 요청 하나만 검증하면 넓은 규칙의 영향을 놓치기 쉽습니다. 유지 관리 기록에는 민감한 정보가 든 설정 전체 대신 변경 전후의 관련 부분을 남기세요. 다음에 결과가 달라져도 범위, 순서, 환경 중 무엇이 바뀌었는지 바로 확인할 수 있습니다.

06 DNS, Host와 주소 판별 범위

도메인이 조회되는지와 규칙이 매칭되는지는 같은 문제인가요?

아닙니다. DNS는 도메인에서 주소를 확인하는 과정이고, 규칙은 요청에 어떤 정책을 적용할지 결정합니다. 서로 영향을 줄 수 있지만 서로를 대신하지는 않습니다. DOMAIN을 올바르게 작성해도 대상의 주소를 확인할 수 있다는 보장은 없으며, 주소 조회에 성공해도 PROXY 연결 매개변수가 올바르다는 뜻은 아닙니다. 문제를 확인할 때는 요청에 사용된 도메인, 확인된 주소, 매칭된 규칙, 연결 경로를 차례로 나누어 살펴보고 어느 단계에서 실패했는지 판단하세요.

General의 DNS 설정은 어떻게 바꿔야 하나요? 먼저 기존 값을 유지하고 현상을 기록한 뒤 변경 항목 하나만 따로 테스트하세요. 아래의 system은 시스템 DNS 설정을 사용한다는 문법 예시이지 모든 네트워크에 적용할 고정 권장값이 아닙니다. 특정 네트워크에 별도의 조회 조건이 필요한 경우 해당 네트워크와 앱 내 설정을 기준으로 확인하세요. DNS 관련 설정을 여러 개 동시에 바꾸면 결과가 개선되더라도 어느 항목이 실제로 영향을 줬는지 알기 어렵습니다.

[General]
dns-server = system

[Host]
portal.example.com = 192.0.2.10

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

Host를 사용하면 도메인 규칙이 주소 규칙으로 바뀌나요?

그렇게 이해해서는 안 됩니다. Host는 지정된 도메인에 매핑 결과를 제공하고 Rule은 라우팅 조건을 설명합니다. 위 예시에서는 주소 매핑과 DIRECT 정책을 각각 별도로 지정합니다. Host를 작성했다고 자동으로 DIRECT가 적용되는 것은 아닙니다. 테스트할 때도 요청에서 확인한 도메인, 주소, 최종 매칭 결과를 살펴봐야 합니다. 대상이 IP 주소를 직접 사용한다면 도메인을 대상으로 한 Host 항목은 모든 요청에 매칭되는 와일드카드가 아닙니다.

Host를 먼저 고려할 만한 상황은 무엇인가요? 예를 들어 이미 내부 도메인의 올바른 주소를 알고 있으며 관리되는 테스트 환경에서 조회 결과의 차이를 확인하려는 경우입니다. 사용하기 전에 매핑 주소가 대상 서비스와 일치하는지, 되돌리는 방법을 알고 있는지 확인하세요. 예시 주소를 실제 웹사이트의 대체 주소로 사용할 수는 없습니다. 공용 도메인에 임의의 낯선 IP를 지정하면 서비스가 일치하지 않거나 인증서 오류, 연결 실패가 발생할 수 있습니다. Host는 아무 주소나 대상 서비스로 바꾸는 기능이 아닙니다.

주소를 매핑했는데도 인증서 오류가 발생하는 이유는 무엇인가요?

HTTPS에서는 IP에 연결할 수 있어야 할 뿐 아니라 서버가 요청된 도메인에 올바른 인증서와 서비스를 제공해야 합니다. Host는 조회 결과를 바꾸지만 서버가 제공하는 콘텐츠를 자동으로 바꾸거나 도메인 검증을 없애지는 않습니다. 인증서 오류가 발생하면 먼저 매핑을 원래대로 되돌려 비교한 다음 주소가 잘못되었거나 다른 서비스에 연결된 것은 아닌지 확인하세요. 일반적인 DNS 문제 해결 방법으로 인증 요구 사항을 낮추지 마세요.

DNS와 GEOIP가 함께 영향을 받는 이유는 무엇인가요? GEOIP는 주소를 기준으로 판단하지만 도메인 조회 결과는 네트워크, 조회 서비스, 서버 측 트래픽 분산에 따라 달라질 수 있습니다. 같은 도메인에서 서로 다른 IP가 반환되면 주소의 지역 분류도 달라질 수 있습니다. 이는 GEOIP가 도메인 규칙을 자동으로 바꾼다는 뜻이 아닙니다. 특정 도메인에 반드시 같은 정책을 적용해야 한다면 동적으로 바뀌는 서비스의 주소를 강제로 고정하기보다 앞쪽에 명확한 도메인 예외를 추가하는 방법을 검토하세요.

캐시와 IPv6는 검증에 어떻게 반영해야 하나요?

캐시 때문에 변경 후 첫 번째 관찰 결과가 예상과 다를 수 있고 기존 연결은 이전 주소를 계속 사용할 수도 있습니다. 테스트 전에 현재 조회 결과를 기록하고 새 연결을 시작한 뒤 앱에서 제공하는 캐시 처리 방법을 따르세요. 대상 주소를 확인하지 않은 채 스위치만 반복해서 누르지 마세요. 요청이 사용하는 조회 정보는 그대로일 수 있습니다. 비교할 수 있는 결과를 얻으려면 같은 네트워크에서 비슷한 시간대에 두 차례 테스트하세요.

IPv6 주소 계열도 별도로 확인해야 합니다. IPv4용 IP-CIDR 규칙만 작성했다고 해서 IPv6 요청에도 같은 범위가 적용된다는 뜻은 아닙니다. Host에 매핑을 하나 추가해도 모든 주소 획득 방식이 의도대로 처리된다는 보장은 없습니다. 먼저 요청에서 IPv6를 사용하는지 확인한 다음 IP-CIDR6과 도메인 규칙 중 어느 쪽이 목적에 맞는지 검토하세요. 주소 계열을 확인하기도 전에 네트워크 기능 전체를 끄거나 켜는 것을 첫 번째 해결 방법으로 삼지 마세요.

07 URL Rewrite의 용도와 제한

URL Rewrite와 Rule은 각각 무엇을 바꾸나요?

Rule은 주로 연결에 적용할 정책을 결정하고, URL Rewrite는 매칭된 URL에 지정된 재작성 동작을 적용합니다. 요청을 다른 URL로 리디렉션한다고 PROXY 경로를 지정하는 것은 아닙니다. 도메인에 DIRECT를 지정해도 페이지 경로가 바뀌지는 않습니다. 경로에 따라 요청을 처리하려면 전체 URL을 DOMAIN에 넣지 말고 재작성이 실제로 필요한지 먼저 확인하세요. 두 섹션을 함께 사용할 수는 있지만 효과는 각각 검증해야 합니다.

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

이 예시는 무엇을 나타내나요? 처음은 매칭 표현식, 가운데는 대상 주소, 마지막은 리디렉션 상태 코드입니다. http://example.com/으로 시작하는 요청을 지정된 HTTPS 주소로 리디렉션하는 예입니다. 점 앞의 백슬래시는 정규식에서 도메인의 점을 문자 그대로 매칭하게 하고, 맨 앞의 ^는 URL의 시작 위치부터 확인하도록 합니다. 구조를 설명하기 위한 예시일 뿐 모든 웹사이트에 그대로 적용할 수 있는 범용 규칙은 아닙니다.

표현식의 범위를 제한해야 하는 이유는 무엇인가요?

정규식에서 점, 별표, 괄호 같은 기호에는 각각 고유한 의미가 있으며 항상 화면에 보이는 문자 그대로를 뜻하지는 않습니다. 이스케이프하지 않은 점은 어떤 문자든 매칭할 수 있고 시작 경계가 없으면 예상하지 못한 위치에서 매칭될 수 있습니다. 작성하기 전에 매칭되어야 하는 예와 매칭되지 않아야 하는 예를 정리하고 하나씩 확인하세요. 도메인이 비슷해 보여도 표현식이 해당 도메인에만 적용된다는 보장은 없습니다. 범위가 넓을수록 로그인, API, 리소스 로드에 미치는 영향을 추적하기 어려워집니다.

대상 주소도 꼼꼼히 확인해야 하는 이유는 무엇인가요? 리디렉션은 요청이 다음에 접속할 위치를 바꾸므로 대상 도메인, 경로, 쿼리 매개변수가 페이지 동작에 영향을 줄 수 있습니다. 특정 경로를 모두 홈페이지로 보내면 원래 페이지 위치와 매개변수가 유지되지 않을 수 있습니다. 캡처한 내용을 유지해야 할 때만 앱에서 지원하는 대체 문법을 검토하고 범위를 좁힌 사본에서 테스트하세요. 의미를 모르는 표현식을 장기간 사용할 설정에 통째로 붙여 넣지 마세요.

일반 규칙에서 HTTPS 경로를 바로 확인할 수 있나요?

가능하다고 단정할 수 없습니다. HTTPS는 요청 내용을 암호화하므로 일반적인 도메인 라우팅 정보만으로 전체 URL 경로를 확인할 수 있는 것은 아닙니다. 경로에 대한 재작성이 적용되지 않았다면 도메인 매칭 범위를 계속 넓히기보다 현재 요청의 내용이 확인 가능한 조건인지 먼저 판단하세요. 요청별 처리 조건은 앱에서 확인해야 합니다. 이 페이지에서는 복호화 관련 설정을 일반적인 트래픽 분기의 필수 단계로 다루지 않으며, 한 번의 재작성을 위해 시스템 신뢰 설정을 임의로 바꾸는 것도 권장하지 않습니다.

특정 도메인만 프록시로 보내려는 경우 어떻게 해야 하나요? Rule로 돌아가 명확한 DOMAIN 또는 DOMAIN-SUFFIX 규칙을 사용하면 됩니다. URL Rewrite를 추가할 필요는 없습니다. 요청 URL을 실제로 변경해야 하고 요청 내용을 확인할 수 있는지와 대상의 동작을 검증할 수 있을 때만 관련 섹션을 고려하세요. 요청 내용에 가까이 개입하는 기능일수록 범위를 신중히 제한해야 합니다. 단순한 라우팅 목적은 우선 간단한 라우팅 규칙으로 표현하세요.

리디렉션 반복과 경로 변경은 어떻게 확인하나요?

먼저 새로 추가한 재작성 행을 잠시 제거하고 설정 사본에서 원래 요청이 복구되는지 확인하세요. 재작성 대상이 같은 표현식에 다시 매칭되면 리디렉션이 반복될 수 있습니다. 표현식 자체가 순환하지 않더라도 서버가 자체 규칙에 따라 원래 주소로 되돌릴 수 있습니다. 화면의 최종 결과만 보지 말고 시작 URL, 리디렉션 대상, 실패가 발생한 위치를 기록하세요. 원인을 쉽게 확인할 수 있도록 한 번에 하나의 재작성 규칙만 남기세요.

HTTP를 HTTPS로 바꾸면 항상 성공하는 것은 왜인가요? 대상 서비스가 해당 도메인과 경로의 HTTPS를 실제로 지원하고 인증서와 서버 설정도 올바르게 구성되어 있어야 합니다. 재작성만으로 서비스에 새 프로토콜 기능이 추가되지는 않습니다. 리디렉션 후 연결에 실패하면 대상 주소 자체를 별도로 테스트한 다음 표현식이 잘못되었는지 판단하세요. URL 변경과 연결 정책은 각각 확인해야 하므로 FINAL이나 GEOIP를 바꿔 이 문제를 가리지 마세요.

08 설정 검증, 문제 해결과 장기 유지 관리

변경 사항이 실제로 적용됐는지 어떻게 확인하나요?

먼저 테스트 조건을 확인한 다음 결과를 살펴보세요. 현재 네트워크, 서버, Global Routing, 적용된 설정을 기록하고 완전한 도메인 하나를 골라 새 요청을 시작합니다. 그런 다음 앱에서 확인할 수 있는 연결 또는 로그 정보에서 대상 도메인, 대상 주소, 매칭 규칙, 정책을 확인하세요. 표시되는 구체적인 항목은 앱 내 정보를 따릅니다. 페이지가 열린 것은 결과 중 하나일 뿐이며 어떤 정책을 사용했는지, 설정 전체가 올바른지를 단독으로 증명하지는 않습니다.

테스트 대상은 어떻게 골라야 하나요? 최소한 세 종류가 필요합니다. 방금 수정한 정확한 대상, 범위가 비슷하지만 바뀌면 안 되는 대상, FINAL이 처리해야 하는 대상입니다. 테스트 후에는 각각 예상 결과와 실제 결과를 기록하세요. 하나만 확인하면 범위가 넓은 규칙의 오매칭을 놓치기 쉽습니다. 주소 규칙이라면 요청에 IPv4와 IPv6 중 어느 것을 사용했는지 추가로 확인하세요. 재작성 규칙이라면 시작 URL과 이동 후 주소를 기록해야 합니다.

관찰된 현상	우선 확인할 항목	다음 비교 항목
새 규칙이 매칭되지 않음	적용된 설정, 모드, 앞선 규칙	정확한 대상과 새 연결
PROXY가 매칭됐지만 연결 실패	서버 상태와 연결 매개변수	같은 대상의 직접 연결 경로
일부 리소스만 실패	실제 리소스 도메인과 거부 규칙	메인 사이트와 실패한 리소스를 각각 테스트
네트워크를 바꾸면 결과가 달라짐	조회된 주소, 주소 계열, 네트워크 조건	같은 대상에서 두 번 얻은 결과를 기록

Connectivity Test로 무엇을 확인할 수 있나요?

앱 내 테스트 조건에서의 연결 상태를 참고할 수 있지만 모든 웹사이트, 프로토콜, 전송 조건이 정상이라는 뜻은 아닙니다. 특정 서버의 테스트는 통과했는데 특정 도메인에 연결할 수 없다면 해당 요청의 조회, 규칙, 실제 연결 과정을 확인해야 합니다. 테스트에 실패했다면 테스트 조건과 서버 정보부터 점검하세요. 한 번의 결과를 고정적인 성능 결론으로 기록하지 말고 숫자 하나로 대상 요청의 확인을 대신하지 마세요.

문제 해결 범위를 어떻게 좁혀야 하나요? 마지막으로 정상 작동을 확인한 설정 사본으로 돌아가 새 변경 이후 문제가 생겼는지 판단하세요. 되돌린 뒤 문제가 해결된다면 변경 사항을 하나씩 다시 적용합니다. 되돌려도 실패한다면 현재 네트워크와 보유한 서버 정보를 확인하세요. 이렇게 하면 설정 변경과 환경 변화를 먼저 구분할 수 있습니다. 서버 변경, DNS 수정, FINAL 변경을 한꺼번에 한 뒤 다시 시도하지 마세요. 접속이 복구되더라도 어떤 변경이 영향을 줬는지 알 수 없게 됩니다.

스위치를 반복해서 켜고 끄는 대신 오류를 어떻게 읽어야 하나요?

먼저 주소 조회 단계, 연결 설정 단계, 대상 서비스 응답 단계를 구분하세요. 주소를 얻지 못했다면 도메인과 DNS를 확인하고, 주소는 있지만 연결이 실패하면 경로와 서버 매개변수를 살펴보세요. 연결된 뒤 서버 오류가 나타난다면 대상 서비스 자체의 상황도 고려해야 합니다. 일부 메시지는 더 많은 맥락이 있어야 판단할 수 있으므로 단어 하나만 보고 결론을 내리지 마세요. 오류가 발생한 대상과 모드를 기록하는 것이 자주 다시 연결한 뒤 ‘될 때도 있고 안 될 때도 있다’고만 기억하는 것보다 유용합니다.

도움을 요청할 때 어떤 정보를 제공해야 하나요? iPhone 또는 iPad 중 어떤 기기를 사용하는지, 현재 모드, 관련 규칙의 순서, 실패한 대상, 이미 수행한 비교 테스트를 설명하세요. 구독 주소, 비밀번호, UUID나 다른 인증 정보를 공개하지 마세요. 스크린샷의 쿼리 매개변수도 제거해야 합니다. 도메인은 예시 이름으로 바꿔도 되지만 정확한 매칭 여부, 접미사 관계, 규칙 순서는 유지해야 분석에 필요한 문제 구조가 보존됩니다.

규칙이 계속 쌓이지 않도록 장기적으로 관리하려면 어떻게 해야 하나요?

규칙을 추가할 때마다 목적과 검증 범위를 명확히 기록하고 앞선 규칙에 완전히 가려진 중복 항목은 정기적으로 정리하세요. 임시 문제 해결 규칙은 검증이 끝난 뒤 유지할지 삭제할지 결정해 일시적인 테스트가 기본 동작으로 남지 않도록 합니다. 원격 설정이나 기존 구독을 업데이트한 뒤에는 규칙 파일과 서버 목록을 각각 확인하세요. 두 항목의 업데이트 시점이나 변경 범위가 같다고 가정하지 마세요. 앱 업데이트는 App Store에서 진행하며 구체적인 요구 사항은 App Store 페이지의 안내를 따릅니다.

다른 매뉴얼 페이지는 언제 참고하면 되나요? 처음 가져오기와 연결 과정은 빠른 시작 가이드로 돌아가세요. 인터페이스 용어는 용어집에서, 구매·복원 및 자주 발생하는 현상은 문제 해결에서 확인할 수 있습니다. 이 페이지의 핵심 흐름은 언제나 ‘설정 구조 확인, 매칭 범위 축소, 우선순위 확인, 실제 요청 검증’입니다. 한 번에 관찰 가능한 문제 하나씩 해결해야 이후 설정도 설명하고 되돌릴 수 있습니다.