Shadowrocket
규칙 및 설정 매뉴얼

Global Routing과 규칙 적용 조건

규칙은 요청이 해당 처리 경로로 들어올 때만 의미가 있습니다. 편집을 시작하기 전에 Shadowrocket에서 사용 가능한 서버를 선택했는지, 연결 스위치가 의도한 상태인지, Config에서 수정하려는 설정을 활성화했는지 확인하세요. 파일이 목록에 저장되어 있다고 해서 현재 사용 중인 것은 아닙니다. 텍스트 편집기에 새 내용이 보인다고 해서 실행 중인 연결에 새 설정이 적용된 것도 아닙니다. ‘파일이 존재함’, ‘파일을 선택함’, ‘요청이 새 설정을 사용함’을 나누어 확인하면 적용 문제를 문법 오류로 오해하지 않을 수 있습니다.

Config, Proxy, Direct 구분하기

Global Routing의 설정, 프록시, 직접 연결 모드는 각각 Config, Proxy, Direct입니다. Config는 현재 설정의 규칙에 따라 요청 정책을 결정하며, 이 페이지 예시 대부분은 Config를 전제로 합니다. Proxy는 일반적으로 프록시로 처리할 요청을 프록시 경로로 보내고, Direct는 직접 연결 경로를 사용합니다. 두 모드는 경로를 비교할 때 유용하지만, 사용자 지정 Rule을 한 줄씩 계속 테스트하는 모드로 이해해서는 안 됩니다. 시스템 우회 항목, 로컬 네트워크 예외, 기존 연결도 관찰 결과에 영향을 줄 수 있으므로 모드를 바꾼 뒤에는 요청을 새로 시작해야 합니다.

서버, 구독, 규칙을 구분해서 이해하기

서버 정보는 연결 대상과 사용 프로토콜 및 인증 매개변수를 설명합니다. 구독은 서버 정보를 일괄 관리하는 입력 방식 중 하나이고, 규칙은 각 요청에 적용할 정책을 결정합니다. 서버 구독을 업데이트해도 Rule이 함께 수정되는 것은 아니며, 설정 파일을 가져와도 그 안에서 참조하는 서버가 자동으로 추가되는 것은 아닙니다. 이 문서는 사용자가 이미 자체 구독 또는 서버 정보를 보유하고 있다는 전제로 설명합니다. 앱을 한 번 구매하는 것과 연결 서비스 이용권을 구매하는 것은 별개입니다. 앱 구매와 실제 연결에 필요한 조건은 서로 다르며, 이 사이트는 노드나 구독을 제공·판매·추천하지 않습니다.

Shadowrocket은 Apple 플랫폼용 유료 상용 앱이며, 주로 iPhone과 iPad에서 사용하고 App Store에서만 받을 수 있습니다. 구매 및 설치 방법은 App Store 정품 구매 및 설치 안내에서 확인하세요. 시스템 요구 사항과 구매 가능 여부는 App Store 페이지에 표시된 내용을 기준으로 합니다. 이 문서의 설정 예시는 앱의 동작을 설명하며, App Store 정보를 대신하거나 사용자가 보유한 서버의 이용 가능성을 보장하지 않습니다. 먼저 기본 연결을 확인한 후 트래픽 분기를 조정하면 문제 범위를 명확히 파악할 수 있습니다.

반복 가능한 테스트 조건 만들기

첫 테스트에서는 명확한 대상 도메인 하나만 선택하고 현재 Global Routing 모드, 선택한 서버, 설정 이름, 네트워크 유형을 기록하세요. 사용 가능한 기존 설정으로 접속해 대상이 응답하는지 확인한 다음 규칙 하나를 변경합니다. 구독 업데이트, 네트워크 전환, DNS 수정, 규칙 재정렬을 한꺼번에 하지 마세요. 여러 변수를 동시에 바꾸면 매칭 결과가 달라져도 어떤 설정이 원인인지 알 수 없습니다. 작업 기록은 로컬 메모에 보관하고, 공유할 때는 서버 주소와 인증 정보, 전체 구독 링크를 삭제하세요.

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

위 예시는 일부 규칙만 보여 줍니다. 정확한 도메인 example.com에는 PROXY를 사용하고, 나머지 매칭되지 않은 요청에는 DIRECT를 사용합니다. 모든 환경에 적용할 수 있는 트래픽 분기 방식도 아니며 프록시 서버를 자동으로 준비하지도 않습니다. 대상 페이지가 다른 도메인에도 요청을 보내면 해당 요청은 FINAL로 처리되어 일부 콘텐츠만 표시되고 나머지는 실패할 수 있습니다. 규칙이 임의로 적용되는 것이 아니라 페이지가 여러 개의 독립적인 연결을 사용하기 때문입니다. 검증할 때는 주소창의 기본 도메인만 보고 판단하지 말고 실제 요청 대상을 하나씩 확인하세요.

.conf 설정 파일 구조와 편집 절차

설정 파일은 대괄호로 표시된 섹션 이름에 따라 내용을 구성합니다. General에는 전역 매개변수, Rule에는 위에서부터 확인하는 매칭 규칙, Host에는 도메인과 주소의 로컬 매핑, URL Rewrite에는 조건에 맞는 URL 재작성 또는 거부 처리를 기록합니다. 섹션 이름은 단순한 제목이 아니라 파서가 뒤따르는 행의 용도를 구분하는 표식입니다. 같은 문구라도 잘못된 섹션에 입력하면 의도한 대로 실행되지 않습니다. 편집하기 전에 현재 위치를 확인하세요. 특히 도메인 매핑을 Rule에 쓰거나 일반 설명을 매개변수 섹션에 입력하지 않도록 주의해야 합니다.

전체 구조를 먼저 확인하고 세부 예시를 살펴보세요

[General]
bypass-system = true

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

[Host]
test.example.com = 192.0.2.10

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

여기서 example.com, example.net, test.example.com은 문법 설명을 위한 예시이고 192.0.2.10은 문서용 예시 주소이므로 접속을 기대해서는 안 됩니다. URL Rewrite 예시는 지정된 HTTP 주소를 HTTPS로 리디렉션하지만, 실제 대상에 적합한지는 해당 사이트의 지원 여부에 달려 있습니다. 전체 코드는 각 섹션의 배치 방식을 보여 주며 기존 설정을 통째로 교체하라는 뜻이 아닙니다. 실제로 수정할 때는 필요한 행만 복사하고 각 행이 어떤 요청을 바꾸는지 확인하세요. 현재 파일에서 유효하다고 확인된 다른 설정은 그대로 유지해야 합니다.

Config에서 현재 파일 확인하기

Config에 들어가면 먼저 현재 선택된 설정을 확인한 뒤 해당 파일을 열어 살펴보세요. 화면 상태에 따라 보기, 편집 또는 다른 작업을 할 수 있으며, 구체적인 메뉴는 앱에 표시되는 내용을 기준으로 합니다. 파일 이름이 비슷하다는 이유만으로 같은 내용이라고 판단하지 마세요. 원격 출처에서 저장한 파일, 로컬 사본, 이전에 가져온 파일이 동시에 존재할 수 있습니다. 작업용 사본에는 알아보기 쉬운 이름을 붙이고 용도를 기록하세요. 수정한 뒤에는 목록으로 돌아가 선택 항목이 바뀌지 않았는지 확인한 다음 요청을 테스트합니다.

전체 교체와 일부 항목 추가는 위험 범위가 다릅니다. 전체 교체는 DNS, 우회 설정, 규칙, 재작성 동작을 한꺼번에 바꿀 수 있으므로 설정 파일 전체를 이해한 경우에 적합합니다. 일부 항목만 추가하면 필요한 내용만 반영할 수 있어 문제를 추적하기 쉽습니다. 일부만 추가하더라도 파일 끝에 같은 섹션 이름을 반복해서 붙이지 말고 기존 섹션을 찾아야 합니다. 중복 섹션의 병합 및 덮어쓰기 동작에 의존해 관리하지 마세요. 각 섹션의 역할을 분명히 하고 내용을 정돈하면 편집기 내용과 실행 결과 사이의 혼란을 줄일 수 있습니다.

저장하기 전에 문자와 섹션 경계 확인하기

Rule의 쉼표는 영문 반각 쉼표를 사용하고, 매개변수 대입에는 등호를 사용하며, 대괄호는 여는 쪽과 닫는 쪽을 맞춰야 합니다. 한국어 입력기에서 쉼표, 공백, 따옴표가 비슷하게 생긴 다른 문자로 바뀔 수 있고, 서식이 있는 문서에서 복사하면 보이지 않는 문자가 들어갈 수도 있습니다. 문법은 맞아 보이는데 설명하기 어려운 문제가 생기면 일반 텍스트 편집기에서 섹션 이름, 구분자, 키워드를 다시 입력하고 저장해 테스트하세요. 규칙의 도메인에는 호스트 부분만 입력하고 경로, 쿼리 매개변수, 브라우저에 표시되는 전체 주소는 포함하지 않습니다.

긴 설정은 용도별로 정리하고 짧은 주석을 남기세요. 예를 들어 특정 정확 일치 예외를 접미사 규칙보다 앞에 두는 이유를 별도 행의 샵 기호 주석으로 적을 수 있습니다. 복사할 때 내용이 섞일 수 있으므로 중요한 매개변수를 설명하는 데 복잡한 행 끝 주석에 의존하지 마세요. 주석에는 키워드의 사전적 의미가 아니라 설정을 선택한 이유를 기록합니다. 나중에 다시 볼 때 “특정 대상의 직접 연결 테스트”라고 적혀 있으면 “DIRECT 규칙”보다 해당 행이 여전히 필요한지 판단하기 쉽습니다.

수정 후에는 정상적으로 저장되고 설정이 선택되었는지 확인한 다음 연결 테스트를 새로 시작하세요. 저장에 성공했다는 것은 파일에 기록되었다는 뜻일 뿐 모든 규칙이 매칭된다는 의미는 아닙니다. 문법이 맞는 규칙도 앞선 규칙에 가려져 계속 실행되지 않을 수 있습니다. 수정 전 사본을 보관하고 한 번에 한 항목씩 추가해 검증을 마친 다음 다음 작업을 진행하세요. 섹션 편집 방법을 더 알아보려면 General, Rule, Host, URL Rewrite 섹션 안내를 읽고 이 페이지의 우선순위 항목과 함께 확인하세요.

General, DNS, 시스템 우회 설정의 적용 범위

General의 매개변수는 Rule처럼 특정 도메인의 정책을 하나씩 결정하는 것이 아니라 전체 처리 환경에 영향을 줍니다. 따라서 요청이 예상한 규칙 기록에 나타나지 않는다고 Rule에 더 넓은 조건을 계속 추가해서는 안 됩니다. 먼저 요청이 클라이언트 처리 경로에 들어왔는지, 시스템 우회 설정이 영향을 주는지, 대상 정보가 확인되는지, 도메인이 IP로 정상 해석되는지 살펴보세요. 이러한 선행 조건을 확인한 뒤 규칙 추가 여부를 판단하면 전체 설정을 바로 교체하는 것보다 문제를 찾기 쉽습니다.

bypass-system의 의미와 한계

[General]
bypass-system = true

bypass-system은 시스템 관련 트래픽 일부를 우회할지 제어합니다. ‘모든 로컬 주소에 직접 연결’과 같은 뜻도 아니고, 특정 사이트 접속을 보장하는 만능 스위치도 아닙니다. 시스템 관련 요청은 일반 규칙을 확인하기 전에 처리될 수 있으므로 이 매개변수를 활성화한 뒤 모든 트래픽의 매칭 기록을 Rule에서 찾을 수 있다고 기대해서는 안 됩니다. 기존 설정에 이 항목이 있다면 유지하는 이유부터 확인하세요. 기록을 빠짐없이 보이게 하려고 바로 끄거나 모든 앱의 동작을 바꾸는 설정으로 간주해서는 안 됩니다.

우회 설정을 확인할 때는 대상이 공용 인터넷 서비스인지, 로컬 네트워크 기기인지, 시스템 구성요소인지 먼저 구분하세요. 공용 도메인은 정확한 DOMAIN 규칙으로 매칭을 확인할 수 있지만 로컬 네트워크 기기는 주소 범위, 네트워크 환경, 시스템 동작의 영향을 함께 받을 수 있습니다. 접속 주소와 현재 Wi-Fi 또는 셀룰러 네트워크를 기록한 다음 필요한 부분만 변경하세요. 로컬 네트워크 대상 하나에만 문제가 있다면 그 대상을 중심으로 검증하고, 전체 시스템 우회 설정을 바꿔 주소·포트·로컬 네트워크 격리 문제를 감추지 마세요.

DNS 해석 결과와 연결 정책은 별개

도메인 규칙은 대상 이름을, IP 규칙은 대상 주소를 판단하며 두 과정 사이에는 흔히 DNS 해석이 있습니다. DNS가 주소를 반환해도 해당 주소에 연결할 수 있다는 뜻은 아닙니다. PROXY를 선택해도 DNS 해석이 반드시 프록시와 동일한 경로를 따른다는 보장은 없습니다. 설정을 확인할 때는 DNS 관련 매개변수, 기존 캐시 여부, 요청 기록에서 실제로 사용된 대상을 각각 살펴보세요. 해석된 주소가 바뀐 것만 보고 도메인 규칙이 적용되지 않았다고 판단하면 DNS 계층과 라우팅 계층을 혼동하게 됩니다.

하나의 도메인이 여러 IPv4 또는 IPv6 주소를 반환할 수 있고, 주소는 네트워크와 시간에 따라 달라질 수 있습니다. 특정 IPv4 주소만 규칙에 포함되어 있으면 다음 DNS 응답에서 IPv6가 선택될 때 다른 정책이 적용될 수 있습니다. 이때마다 확인한 주소를 목록에 추가하기보다는 도메인 규칙으로 요구 사항을 표현할 수 있는지 먼저 살펴보세요. 안정적인 네트워크 대역이나 특정 주소를 제어해야 할 때만 IP-CIDR 또는 IP-CIDR6을 사용합니다. 규칙의 매칭 대상이 실제 요구와 일치해야 우연히 얻은 DNS 결과에 의존하지 않고 관리할 수 있습니다.

no-resolve는 규칙 옵션이지 DNS 스위치가 아닙니다

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
FINAL,PROXY

no-resolve는 일반적으로 IP 유형 규칙에서 사용하며, 해당 규칙을 확인하기 위해 별도의 도메인 해석을 추가로 실행하지 말라는 뜻입니다. 클라이언트 전체에서 DNS를 중지하거나 이후 연결에 해석이 필요 없다는 뜻은 아닙니다. 매칭할 대상 IP를 이미 알고 있다면 규칙이 적용될 수 있습니다. 도메인만 있고 사용할 수 있는 주소가 없다면 이 규칙만으로 판단하지 못해 다음 규칙을 확인할 수 있습니다. 이를 ‘모든 해석 금지’ 또는 ‘모든 도메인을 자동으로 주소 기준 매칭’으로 이해하면 잘못된 결과를 예상하게 됩니다.

no-resolve를 삭제한 뒤에만 특정 대상의 동작이 바뀐다면 옵션의 좋고 나쁨을 단정하기보다 추가 DNS 해석이 원인인지 확인하세요. 해석 전후의 주소, 매칭된 규칙, 최종 정책을 기록한 다음 해당 동작을 유지할지 결정합니다. 특히 도메인 규칙과 GEOIP 규칙이 함께 있으면 앞선 도메인 규칙에서 이미 매칭이 끝나 뒤의 DNS 옵션이 아예 실행되지 않았을 수도 있습니다. 옵션을 검증하려면 요청의 처리 경로가 실제로 그 규칙까지 도달했는지 먼저 확인해야 합니다.

DNS 문제를 확인할 때는 접속이 정상인 대상을 기준으로 삼고, 문제가 특정 도메인에만 발생하는지, 특정 네트워크에서만 발생하는지, IPv6 경로 변화가 동반되는지 확인하세요. 명확한 매개변수 하나만 바꾸고 테스트 결과를 기록합니다. 온라인에서 찾은 General 섹션 전체를 현재 파일에 함부로 덮어쓰지 마세요. DNS, 우회 설정, 기타 전역 옵션이 서로 영향을 줄 수 있습니다. 기본 연결부터 복구해야 한다면 FAQ의 연결 문제 해결 안내를 참고해 DNS와 연결을 별도로 확인하세요.

DOMAIN, 접미사, 키워드, USER-AGENT

도메인 규칙은 무조건 가장 넓은 조건을 쓰기보다 제어하려는 범위에 맞춰 선택하세요. DOMAIN은 정확한 호스트 이름, DOMAIN-SUFFIX는 도메인과 하위 도메인, DOMAIN-KEYWORD는 도메인에서 지정 문자열을 찾을 때 적합합니다. 세 규칙 모두 전체 URL을 매칭하지 않습니다. 경로, 쿼리 매개변수, 페이지 제목, 브라우저에 표시되는 문구는 매칭 범위에 포함되지 않습니다. 먼저 대상 호스트를 확인하고 필요한 최소 범위만 선택하면 불필요한 매칭과 설명하기 어려운 접속 변화를 줄일 수 있습니다.

정확 일치와 접미사 일치

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

DOMAIN,api.example.com,DIRECT는 해당 호스트 이름만 정확히 판단하며 www.example.com이나 api.example.com의 하위 도메인을 자동으로 포함하지 않습니다. DOMAIN-SUFFIX,example.com,PROXY는 example.com과 그 하위 도메인에 적용됩니다. 위 예시에서는 api.example.com이 정확 일치 규칙에 먼저 매칭되어 DIRECT를 사용하고, example.com 범위의 다른 호스트는 접미사 규칙으로 처리됩니다. 접미사 규칙을 앞에 두면 정확한 예외 규칙이 실행되지 않습니다. 이것이 규칙 순서가 중요한 이유입니다.

접미사 매칭은 도메인 경계를 기준으로 하며 임의의 문자열 검색으로 보면 안 됩니다. example.com 범위에 적용하려면 해당 도메인을 접미사로 사용하세요. 브라우저 주소에 표시되는 프로토콜을 앞에 붙이거나 끝에 슬래시를 넣지 않습니다. DOMAIN-SUFFIX,example.com은 이름에 “example.com” 문자열이 포함된 모든 도메인을 매칭하는 규칙이 아닙니다. 실제 요구가 문자열 포함 여부라면 DOMAIN-KEYWORD를 명시적으로 사용하고 범위가 지나치게 넓지 않은지 추가로 확인하세요.

키워드 규칙은 오매칭 범위부터 확인하세요

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

DOMAIN-KEYWORD,example,PROXY는 도메인에 example 문자열이 포함되는지 확인하므로 example.com 접미사 규칙보다 범위가 넓습니다. 접미사가 다른 도메인이나 소유자가 다른 도메인도 함께 매칭될 수 있으므로 줄 수를 줄이려고 이미 확인한 정확한 도메인 규칙을 대체하는 용도로는 적합하지 않습니다. 특정 사이트의 기능 전체에 적용하려면 실제 요청 기록에서 필요한 호스트를 추출해 용도를 하나씩 확인한 뒤 접미사 규칙으로 합칠지 결정하세요. 범위가 지나치게 넓은 규칙은 문법 오류를 일으키기보다 관련 없는 요청의 정책을 눈에 띄지 않게 바꾸는 경우가 많습니다.

USER-AGENT의 확인 범위

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

USER-AGENT는 확인할 수 있는 User-Agent 문자열을 기준으로 매칭하며, 예시의 ExampleClient는 와일드카드 패턴을 설명하기 위한 값입니다. 앱 이름으로 트래픽을 선택하는 기능이 아니며 기기에 설치된 모든 앱을 자동으로 식별하지도 않습니다. 암호화된 요청의 HTTP 헤더는 일반 연결 정보만으로 바로 읽을 수 없는 경우가 많으므로 적용 여부는 요청 유형과 확인 가능한 정보에 달려 있습니다. 어떤 앱의 웹 요청이 한 번 매칭되었다고 해서 앱의 모든 연결이 같은 방식으로 처리된다고 단정하지 마세요. 매칭을 늘리려고 복호화 범위를 임의로 확대해서도 안 됩니다.

도메인 규칙을 검증할 때는 리디렉션된 대상과 페이지가 의존하는 도메인도 함께 확인하세요. 페이지를 열면 기본 도메인에 먼저 접속한 다음 로그인 도메인으로 이동하고 이미지, API, 정적 리소스를 요청할 수 있습니다. 각각의 연결은 별도로 판단됩니다. 로그인만 실패한다면 홈페이지 규칙을 반복해서 바꾸기보다 로그인 절차에서 실제로 사용되는 호스트를 먼저 확인하세요. 요청 기록에 IP만 보인다면 도메인 정보를 확인할 수 있는지 살펴보세요. 이름이 없는 요청을 DOMAIN 규칙이 적용되지 않은 증거로 해석해서는 안 됩니다.

정확한 규칙으로 검증 가능한 최소 구성을 만든 뒤 실제 결과에 따라 접미사 규칙으로 합치는 방법을 권장합니다. 항목을 하나 추가할 때마다 대상에 접속하고 관련 없는 대상 하나와 비교해 예상한 요청만 바뀌었는지 확인하세요. 기존 규칙을 삭제하기 전에 매칭 순서를 기록해 해당 규칙에 의존하는 예외까지 함께 지우지 않도록 합니다. 자주 바뀌는 서비스 도메인은 이름이 비슷하다는 이유로 관계를 추측하지 말고 현재 요청을 기준으로 관리하세요. 이름이 비슷해도 같은 정책을 사용해야 한다는 뜻은 아닙니다.

IP-CIDR, IP-CIDR6, GEOIP

IP 규칙은 대상 주소를 판단하며 웹사이트 운영자나 서비스 특성을 판별하지 않고 주소가 해당 서비스를 제공한다고 보장하지도 않습니다. IP-CIDR은 IPv4 대역, IP-CIDR6은 IPv6 대역, GEOIP는 주소 데이터베이스에 따른 지역 분류를 처리합니다. 명확한 주소 범위를 표현하거나 도메인 규칙 뒤에 보조 조건으로 사용할 수 있습니다. 요구 사항이 ‘특정 도메인에 특정 정책을 적용’하는 것이라면 보통 도메인 규칙이 더 직접적입니다. 현재 확인한 IP 한두 개를 웹사이트의 영구 주소로 간주하면 규칙의 적용 범위가 금방 부족해집니다.

CIDR의 접두사 길이 이해하기

[Rule]
IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR6,2001:db8::10/128,DIRECT,no-resolve
FINAL,PROXY

IPv4의 /32는 단일 주소, /16은 앞의 16비트로 정해지는 주소 범위를 의미합니다. IPv6의 /128은 단일 주소입니다. 접두사 길이가 짧을수록 일반적으로 더 많은 주소를 포함합니다. 예시의 192.0.2.10과 2001:db8::10은 문서용 주소이므로 실제 대상으로 사용할 수 없습니다. 실제 값을 입력할 때는 주소와 접두사가 함께 나타내는 범위를 확인하세요. 앞부분이 대상 주소와 비슷해 보이는지만 봐서는 안 됩니다. 잘못 지정한 넓은 네트워크 대역은 관련 없는 연결에 큰 영향을 줄 수 있으며, 범위가 너무 넓다고 자동으로 경고하지 않습니다.

로컬 네트워크 규칙을 작성할 때도 실제 사용 중인 네트워크 대역부터 확인하세요. 192.168.0.0/16은 흔히 쓰이는 사설 주소 범위 중 하나일 뿐 모든 로컬 네트워크 주소를 나타내지 않습니다. IPv6의 로컬 범위도 용도가 서로 다릅니다. 기기 접속에 실패하면 클라이언트 정책 외에도 Wi-Fi에서 기기 간 통신을 허용하는지, 대상 서비스 포트가 열려 있는지, 대상이 특정 네트워크 인터페이스에서만 연결을 받는지 확인하세요. DIRECT는 직접 연결 경로를 선택할 뿐 로컬 네트워크 권한을 대신하거나 존재하지 않는 서비스가 응답하게 만들지 않습니다.

GEOIP는 주소 분류이며 도메인 표시는 아닙니다

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

GEOIP,CN,DIRECT는 데이터베이스에서 CN으로 분류된 대상 주소에 DIRECT를 적용한다는 뜻입니다. 도메인 접미사나 페이지 언어를 기준으로 판단한다는 뜻은 아닙니다. 하나의 도메인이 여러 지역에 분산된 서비스 주소를 사용할 수 있고 데이터베이스 업데이트가 늦어질 수도 있으므로 조직의 소재지만 보고 모든 연결이 동일한 GEOIP 조건에 매칭될 것이라 추측하지 마세요. 특정 서비스에 항상 같은 정책이 필요하다면 GEOIP보다 앞에 명확한 도메인 규칙을 추가해 간접적인 주소 분류에 의존하지 않도록 하세요.

GEOIP와 DNS의 관계는 현재 요청 정보를 함께 확인해야 합니다. 대상이 도메인뿐이라면 주소를 판단하기 위해 사용 가능한 DNS 결과가 필요할 수 있습니다. 앱이 IP에 직접 연결한다면 이미 매칭 대상 주소가 있을 수 있습니다. IP 유형 규칙에 no-resolve를 추가하면 규칙 자체를 판단하기 위한 추가 DNS 해석이 실행되지 않아 동작이 달라질 수 있습니다. 최종 정책만 보지 말고 대상 이름, 주소, 매칭된 규칙을 함께 기록하세요. 앞선 도메인 규칙이 이미 매칭되었다면 GEOIP는 아예 적용되지 않습니다.

IPv4와 IPv6를 따로 검증하기

같은 서비스가 IPv4와 IPv6 주소를 모두 제공할 수 있으며 앱과 시스템은 네트워크 조건에 따라 한쪽을 선택합니다. IP-CIDR만 작성해도 해당 IPv6 대상까지 자동으로 포함되는 것은 아닙니다. 한 번 성공했다고 다른 주소 체계에서도 같은 동작을 한다는 뜻은 아닙니다. 네트워크를 바꾼 뒤 정책이 달라진다면 실제 연결에 사용된 주소 체계를 확인하고 관련 IP-CIDR6 규칙이 있는지 살펴보세요. 특정 주소 체계를 끄는 것을 모든 문제의 해결책으로 삼지 말고 규칙 범위와 네트워크 경로 중 어디에서 문제가 발생했는지 먼저 확인하세요.

공유 주소와 동적 DNS 결과도 고려해야 합니다. 여러 도메인이 하나의 주소를 공유하면 그 주소에 지정한 규칙이 해당 도메인 모두에 영향을 줍니다. 반대로 도메인이 자주 다른 주소를 사용하면 예전 규칙이 더 이상 매칭되지 않을 수 있습니다. 단일 사이트만 제어하려는 경우 도메인 조건으로 범위를 표현하는 편이 일반적으로 더 쉽습니다. 공유 주소의 영향 범위를 감수할 수 있거나 대상에 IP로 직접 접속하는 경우에만 주소 규칙을 주요 조건으로 사용하세요. 관리할 때는 대역의 출처와 용도를 기록해 근거를 설명할 수 없는 항목이 장기간 남지 않도록 합니다.

권장 확인 순서는 실제 대상 주소 확인, 규칙 적용 범위 계산, no-resolve 및 앞선 규칙 확인, 연결 결과 관찰입니다. 규칙이 제대로 매칭되는데 접속에 실패한다면 대역을 무작정 넓히기보다 대상에 연결 가능한지, 포트와 선택 경로가 맞는지 확인하세요. IP 규칙은 분류 문제를 다룰 뿐 연결 자체를 보장하지 않습니다. 안정된 상태로 돌아가야 한다면 최근 추가한 주소 규칙을 되돌리고 기존 도메인 규칙과 비교하세요. 전체 설정을 한꺼번에 지우는 것보다 원인을 파악하기 쉽습니다.

PROXY, DIRECT, REJECT와 매칭 우선순위

Rule은 일반적으로 위에서 아래 순서로 확인하며, 규칙이 매칭되어 정책이 정해지면 뒤에 있는 일반 규칙을 계속 찾지 않습니다. 키워드가 ‘더 정확하다’고 자동으로 우선순위가 높아지는 것은 아닙니다. 뒤에 있는 DOMAIN 규칙이 DOMAIN-SUFFIX보다 정확하더라도 앞선 규칙이 이미 매칭되면 그 규칙을 건너뛰지 않습니다. 관리할 때는 명확한 예외를 먼저 두고 넓은 범위의 규칙을 배치한 다음 FINAL을 마지막에 둡니다. 우선순위는 도메인 길이, 키워드 이름, 편집 시점이 아니라 우선 파일에 적힌 순서로 결정됩니다.

세 가지 정책의 역할

PROXY는 매칭된 요청을 프록시 경로로 보내며, 일반적으로 현재 선택된 사용 가능한 서버나 설정에서 명시적으로 지정한 정책이 필요합니다. DIRECT는 직접 연결 경로를 사용하지만 로컬 네트워크와 대상의 연결 가능 여부에 따라 결과가 달라집니다. REJECT는 매칭된 요청을 거부하며 다른 대체 경로로 보내거나 웹페이지를 다른 콘텐츠로 바꾸지 않습니다. 세 가지는 처리 결과이지 서비스 품질 등급이 아닙니다. 실패한 요청을 PROXY나 DIRECT로 바꾸는 것은 경로만 변경할 뿐 인증, 대상 서비스, 프로토콜 매개변수 문제를 자동으로 해결하지 않습니다.

예외 규칙으로 순서 이해하기

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

위 예시는 로그인 호스트와 metrics 호스트를 먼저 처리하고, 나머지 example.com 범위를 확인한 뒤 GEOIP를 검사하고 마지막에 FINAL로 처리합니다. DOMAIN-SUFFIX를 맨 앞에 두면 두 호스트가 먼저 접미사 규칙에 매칭되어 DIRECT와 REJECT가 적용되지 않습니다. 긴 설정을 읽을 때는 새로 추가한 행만 검색하지 말고 대상 요청을 기준으로 앞에서부터 이를 덮을 수 있는 조건을 모두 확인하세요. 규칙이 존재한다는 것은 해당 행이 텍스트에 있다는 뜻일 뿐 실행 경로가 그 행까지 도달한다는 보장은 아닙니다.

FINAL 위치가 기본 처리 범위를 결정합니다

FINAL에는 도메인이나 주소 조건을 지정하지 않으며 FINAL,정책 형식으로 작성합니다. 앞선 규칙에 매칭되지 않은 요청을 처리하므로 일반적으로 Rule의 마지막에 둡니다. 중간에 FINAL을 두면 뒤의 일반 규칙이 실행되지 않을 수 있습니다. FINAL을 여러 번 작성해도 뒤에 있는 기본 처리가 기대한 대로 동작하지 않을 수 있습니다. FINAL,PROXY와 FINAL,DIRECT 중 무엇을 선택할지는 현재 사용 목적과 가능한 연결 경로에 따라 결정하세요. 어느 하나만 정답이라고 생각해서는 안 됩니다. 예시의 선택은 구조 설명을 위한 것이며 실제 서비스 환경에 대한 판단을 대신하지 않습니다.

REJECT는 적용 범위를 더욱 신중하게 제한해야 합니다. 통계 용도로 보이는 도메인도 설정, 로그인 상태, 기타 필수 요청에 사용될 수 있습니다. 이름만 보고 거부하면 페이지 일부가 로드되지 않거나 앱이 간헐적으로 실패할 수 있습니다. 거부 규칙을 추가하기 전에 실제 매칭 대상과 영향 범위를 확인하고 되돌릴 방법을 준비하세요. 검증할 때는 대상 요청이 거부되는지만 보지 말고 정상 기능에 영향이 있는지도 확인합니다. 기능에 문제가 생기면 최근에 추가한 REJECT 항목부터 되돌려 확인하세요. 처음 판단이 잘못된 상태에서 예외를 더 추가해 문제를 덮지 마세요.

정책 이름과 실제 연결 경로 구분하기

이 페이지에서는 이해하기 쉽도록 PROXY, DIRECT, REJECT 같은 기본 정책 키워드를 사용합니다. 기존 설정에 사용자 지정 정책 이름이 있다면 해당 정의가 실제로 존재하는지, 최종적으로 어떤 서버나 선택 방식으로 이어지는지 확인하세요. 이름에 지역이나 용도가 들어 있다고 해서 실제 연결 경로를 알 수 있는 것은 아닙니다. 서버가 삭제되었거나 구독 업데이트로 항목이 바뀌었거나 현재 선택 항목이 예상과 다르면 같은 규칙도 다른 연결 결과를 낼 수 있습니다. 표시 이름만으로 추측하지 말고 정책 참조부터 확인한 다음 서버를 살펴보세요.

순서를 조정할 때는 ‘정확한 예외, 접미사 범위, 주소 조건, 최종 기본 처리’ 순서로 구성하고 대상 세 개 이상으로 검증하는 것을 권장합니다. 예외에 매칭되어야 하는 대상, 넓은 범위에 매칭되어야 하는 대상, FINAL로 처리되어야 하는 대상을 각각 확인하면 예외가 가려지는 문제와 기본 처리가 앞당겨지는 문제를 함께 찾을 수 있습니다. 설정 파일 두 개를 비교할 때 행 수부터 세지 말고 같은 대상이 각 파일에서 처음 만나는 유효 규칙을 비교하세요. 규칙이 길다고 더 정확한 것은 아닙니다. 모든 규칙에 분명한 목적이 있어야 오래 관리하고 문제 발생 시 되돌리기 쉽습니다.

Host와 URL Rewrite의 역할 구분

Host는 도메인 해석에 사용하는 주소 매핑을 변경하고, Rule은 요청에 적용할 정책을 결정하며, URL Rewrite는 조건에 맞는 URL을 처리합니다. 서로 다른 계층의 기능이므로 대체해서는 안 됩니다. 도메인을 특정 주소로 매핑해도 DIRECT 경로를 사용하게 되는 것은 아닙니다. HTTP 주소를 HTTPS로 리디렉션해도 대상이 PROXY를 사용한다는 뜻은 아닙니다. 문제를 확인할 때는 ‘대상 이름, 해석된 주소, 규칙 정책, 요청 처리’ 순서로 각 계층을 살펴보세요. 한 계층의 변화 때문에 다른 계층의 설정을 잘못 수정하지 않도록 주의해야 합니다.

Host 매핑은 이름을 주소로 연결합니다

[Host]
test.example.com = 192.0.2.10

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

예시에서는 test.example.com을 문서용 주소로 매핑하고 별도의 DOMAIN 규칙으로 DIRECT를 선택합니다. 두 행은 역할이 다르므로 한 행을 생략하면 같은 동작을 기대할 수 없습니다. 실제로 사용할 때는 주소를 직접 관리하거나 정확한 정보를 확인한 유효한 대상으로 바꾸고 해당 서비스가 이 도메인을 처리할 수 있는지 확인하세요. Host는 아무 도메인이나 아무 주소에 연결하면 정상 접속이 되는 도구가 아닙니다. 서버의 수신 상태, 사이트의 도메인 식별 방식, 인증서 일치 여부는 대상 서비스에 달려 있습니다.

HTTPS에서는 특히 인증서와 호스트 이름의 관계를 확인해야 합니다. DNS 해석 주소가 예상대로 바뀌어도 클라이언트는 요청에 포함된 도메인을 기준으로 인증서를 확인하며 매핑만으로 인증서가 자동으로 맞춰지지 않습니다. 인증서 오류를 숨기려고 검증을 끄지 마세요. 대상 주소가 정확한지, 서비스가 해당 도메인을 제공하는지, 네트워크 인증 페이지 같은 요인이 있는지 확인해야 합니다. IP 주소로 직접 접속해 콘텐츠가 보였다고 해서 원래 도메인을 사용한 HTTPS 요청도 성공한다고 단정할 수 없습니다.

URL Rewrite는 확인 가능한 요청 정보부터 살펴보세요

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

위 예시는 정규식으로 http://example.com/로 시작하는 URL을 매칭한 뒤 302 방식으로 HTTPS에 리디렉션합니다. 시작 부분의 캐럿은 문자열의 시작을 지정하고 도메인의 점은 역슬래시로 이스케이프해 정규식에서 임의의 문자로 처리되지 않게 합니다. 대상 사이트가 실제로 HTTPS를 지원해야 합니다. 그렇지 않으면 사용할 수 없는 다른 주소로 요청을 보낼 뿐입니다. 이 예시는 문법 설명을 위한 것이며 모든 사이트에 재작성 규칙을 적용해야 한다는 뜻도, 암호화된 트래픽 내부를 항상 확인할 수 있다는 뜻도 아닙니다.

URL Rewrite에 사용할 수 있는 정보는 클라이언트가 가져올 수 있는 요청 정보에 따라 달라집니다. 일반적인 암호화 연결에서는 전체 경로와 요청 헤더가 모든 규칙에 자동으로 노출되지 않습니다. 일반 HTTP를 매칭하는 예시를 임의의 HTTPS 요청에 그대로 적용한 뒤 설정이 작동하지 않는다고 판단하지 마세요. 더 깊은 요청 처리가 필요하다면 추가 조건과 보안 영향을 이해해야 합니다. 기본적인 트래픽 분기에는 이 매뉴얼에서 해당 기능을 활성화할 것을 요구하지 않습니다. 특정 도메인의 연결 경로만 바꾸려면 보통 Rule의 도메인 조건이 더 적합합니다.

정규식 범위와 리디렉션 루프

정규식은 도메인 접미사 매칭보다 유연하지만 범위를 지나치게 넓게 작성하기도 쉽습니다. 시작 위치를 제한하지 않거나 점을 이스케이프하지 않거나 도메인 경계를 넘는 와일드카드를 사용하면 관련 없는 URL까지 처리될 수 있습니다. 먼저 프로토콜과 정확한 호스트를 지정한 다음 경로 범위를 정하세요. 범위를 넓힐 때마다 매칭되어야 하는 요청과 매칭되면 안 되는 요청을 하나씩 비교합니다. 정규식의 의미를 확신할 수 없다면 정확한 예시부터 사용하세요. 의미를 모르는 긴 정규식을 기존 설정에 추가하거나 복사한 출처의 설명만 믿고 적용 범위를 추측하지 마세요.

사이트가 리디렉션을 추가로 실행할 수도 있습니다. 로컬 규칙이 주소를 다른 대상으로 바꾼 뒤 사이트가 다시 원래 주소로 돌려보내면 리디렉션 루프가 발생해 페이지가 계속 이동하거나 브라우저에 리디렉션이 너무 많다는 오류가 표시될 수 있습니다. 이때는 관련 재작성 규칙을 일시적으로 제거하고 사이트의 원래 동작을 확인한 뒤 범위를 줄일지 아예 취소할지 판단하세요. 기존 루프를 덮으려고 새로운 리디렉션을 계속 추가하지 마세요. 각 단계의 출발점과 도착점을 정리해야 문제가 발생한 지점을 찾을 수 있습니다.

Host와 URL Rewrite를 관리할 때는 각각 따로 테스트하는 것이 좋습니다. 먼저 정상 DNS 해석과 재작성 없는 상태로 기본 연결을 확인한 다음 매핑 하나만 활성화하고 마지막으로 재작성 하나를 검증합니다. Host 매핑을 제거한 후에는 요청을 새로 시작하고 기존 캐시의 영향을 고려하세요. 재작성을 끈 뒤에도 브라우저에 남은 리디렉션 결과를 재사용하지 않아야 합니다. 매번 실제 대상과 첫 번째 매칭 규칙을 기록하면 어느 계층에서 변화가 발생했는지 확인할 수 있습니다. 트래픽 분기에 필요하지 않은 매핑이나 재작성은 간결하게 유지해 숨은 의존성과 문제 해결 비용을 줄이세요.

설정 검증, 흔한 오해, 되돌리기 절차

설정은 ‘파일, 매칭, 연결, 서비스’ 네 단계로 검증하세요. 파일 단계에서는 선택 항목과 문법을 확인하고, 매칭 단계에서는 요청이 예상한 규칙에 맞는지 살펴봅니다. 연결 단계에서는 선택한 경로로 통신이 가능한지 확인하고, 서비스 단계에서는 로그인, API, 페이지 콘텐츠가 모두 정상인지 확인합니다. 앞 단계가 성공해도 다음 단계까지 성공하는 것은 아닙니다. 예를 들어 DOMAIN이 예상대로 PROXY에 매칭되었더라도 서버 인증이 실패하면 연결 단계의 문제입니다. 페이지 본문은 열리는데 API가 실패한다면 다른 요청을 계속 살펴봐야 하며 브라우저에서 페이지가 열리는지만 확인해서는 안 됩니다.

최소 테스트 세트로 규칙 확인하기

정확한 예외 규칙에 매칭될 도메인 하나, 접미사 범위에 매칭될 도메인 하나, FINAL로 처리될 비교 대상 하나를 준비하세요. 설정을 저장한 뒤 Global Routing이 Config인지 확인하고 대상 요청을 새로 시작한 다음 앱에서 제공하는 연결 또는 요청 기록을 확인합니다. 화면에 표시되는 구체적인 필드는 앱 상태에 따라 다를 수 있으므로 확인 가능한 대상, 정책, 서버, 오류 정보를 기록하세요. 기록에 세부 정보가 모두 표시되지 않는다면 관찰에 한계가 있음을 인정해야 합니다. 필드가 보이지 않는다고 규칙이 실행되지 않았다는 증거로 삼아서는 안 됩니다.

가능하면 새 연결로 테스트하세요. 이미 수립된 장기 연결, 페이지 캐시, 앱의 백그라운드 세션은 기존 상태를 계속 사용해 방금 수정한 규칙이 적용되지 않는 것처럼 보이게 할 수 있습니다. 관련 앱의 진행 중인 요청을 중지한 뒤 필요에 따라 연결을 다시 수립하고 다른 설정은 그대로 유지하세요. 결과가 한 번 바뀌지 않았다고 모든 규칙 순서를 바로 조정하지 마세요. 새 요청이 실제로 시작되었는지, 대상이 리디렉션을 거쳤는지 먼저 확인해야 합니다. 스위치를 자주 바꾸기보다 테스트 조건을 반복 가능하게 유지하는 것이 원인 파악에 도움이 됩니다.

증상에 따라 범위 좁히기

모든 대상에 연결할 수 없다면 개별 도메인 규칙부터 살펴보기보다 연결 스위치, 시스템 VPN 설정 상태, 현재 서버, 기본 네트워크를 먼저 확인하세요. Connectivity Test는 테스트한 연결 상태를 파악하는 데 도움이 될 수 있지만 한 번의 성공으로 모든 서비스, 프로토콜, 대상의 연결을 보장하지는 않습니다. 첫 연결 절차는 기본 서버 선택 및 Connectivity Test 확인에서 살펴보세요. 특정 사이트만 문제가 있다면 실제 요청과 규칙 매칭을 따라가며 원인을 확인합니다.

특정 규칙만 작동하지 않는 것 같다면 먼저 위에 더 넓은 DOMAIN-SUFFIX, DOMAIN-KEYWORD, 주소 규칙이 있는지, FINAL이 너무 앞에 있는지 확인하세요. 그다음 키워드, 반각 쉼표, 대상 이름, 정책 참조를 살펴봅니다. 규칙은 제대로 매칭되는데 결과가 다르다면 ‘올바른 규칙 선택’과 ‘연결 성공 여부’를 분리해 확인하세요. 연결 실패를 해결하려고 같은 의미의 규칙을 계속 추가하지 마세요. 여러 규칙이 같은 실패 경로를 가리키면 설정만 복잡해지고 근본 원인은 바뀌지 않습니다.

명확한 상태로 되돌릴 수 있어야 합니다

수정하기 전에 현재 사용 가능한 파일의 사본을 보관하고 선택한 서버와 Global Routing 상태를 기록하세요. 문제가 생기면 가장 최근에 바꾼 항목부터 되돌립니다. 변경 범위가 너무 크다면 사용 가능하다고 확인한 설정으로 돌아간 다음 같은 대상으로 다시 테스트하세요. 되돌린 뒤에도 실패한다면 네트워크 환경 변화, 사용할 수 없게 된 서버 정보, 대상 서비스 자체의 문제 등 규칙 외의 원인일 수 있습니다. 백업 파일도 변경되었다고 단정하지 말고 연결 단계부터 계속 확인하세요.

원격 출처의 설정을 업데이트하기 전에 로컬 수정이 덮어써질 수 있는지 확인하세요. 직접 추가한 정확 일치 예외와 수정 이유를 따로 기록하고 업데이트 후 항목별로 대조합니다. 새 파일에 이전 내용이 반드시 유지될 것이라고 가정해서는 안 됩니다. 구독 업데이트와 설정 업데이트도 별도로 진행하고 각각 서버 목록과 규칙 결과를 검증하세요. 가져오기 메뉴는 Subscribe, Add Server, QR 코드 및 클립보드 가져오기 안내에서 확인해 연결 정보를 가져오는 문제를 Rule 해석 오류와 혼동하지 않도록 하세요.

마지막으로 공유할 수 있는 최소한의 문제 설명을 정리하세요. 기기의 현재 네트워크 유형, Global Routing 모드, 문제가 발생한 공개 대상, 예상 정책, 실제 관찰 결과, 관련 규칙 몇 개를 포함하면 됩니다. 비밀번호, 전체 구독 링크, 인증 정보, 개인 접속 기록은 삭제하세요. 순서 문제를 설명하기 위해 설정 파일 전체를 공개할 필요는 없습니다. 더 확인할 내용은 FAQ에서 항목별로 살펴보고 기본 절차가 아직 끝나지 않았다면 튜토리얼로 돌아가세요. 신뢰할 수 있는 설정은 각 규칙의 목적이 분명하고 결과를 검증할 수 있으며 문제가 생겼을 때 정확히 되돌릴 수 있어야 합니다.