Shadowrocket
규칙 및 설정 참고

설정 구조와 General

설정 파일은 요청의 이름 해석, 매칭 및 처리 방법을 지정하고, 서버 정보는 실제 연결에 필요한 매개변수를 제공합니다. 둘은 서로 대체할 수 없습니다. 파일에 PROXY가 적혀 있어도 사용할 수 있는 서버가 있다는 뜻은 아닙니다. 반대로 서버를 가져왔더라도 특정 규칙 파일이 적용 중이라는 보장은 없습니다. 수정하기 전에 Config에서 현재 사용하는 설정을 확인하고, Home에서 연결 대상을 확인해 ‘어떤 규칙을 사용할지’와 ‘어디에 연결할지’를 따로 기록하세요.

네 구역의 역할

대괄호로 표시된 제목은 설정 구역을 구분합니다. [General]에는 일반 옵션, [Rule]에는 순서대로 검사하는 트래픽 분기 규칙, [Host]에는 이름과 주소의 정적 매핑, [URL Rewrite]에는 조건에 맞는 URL 재작성 또는 리디렉션을 설정합니다. 이 네 구역은 서로 대체할 수 있는 규칙 묶음이 아닙니다. 도메인에 적용할 정책은 보통 Rule에서 지정하고, 도메인을 어떤 주소로 해석할지는 Host 또는 DNS에서 다룹니다.

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

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

[Host]
example.com = 192.0.2.10

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

이 텍스트는 구역 구성과 문법을 보여 주는 예시이며, 그대로 활성화해 사용할 수 있는 완성된 설정이 아닙니다. example.com은 설명용 도메인이고 192.0.2.10은 문서에서 사용하는 예시 주소입니다. 여기서 Host와 URL Rewrite는 형식을 설명하기 위한 것으로, 두 구역을 반드시 함께 활성화해야 한다는 뜻은 아닙니다. 설정을 연습할 때는 먼저 General과 소수의 Rule만 남기고 기본 연결을 확인한 다음, 검증할 구역을 하나씩 추가해 예시 간 간섭을 방지하세요.

일반 옵션은 용도에 맞게 해석하기

dns-server = system은 시스템 DNS 설정을 사용한다는 뜻입니다. 현재 네트워크 동작을 확인하는 출발점으로 삼을 수 있지만, 모든 원격 요청이 반드시 동일한 로컬 리졸버를 거친다고 단정할 수는 없습니다. 서버 프로토콜, 연결 방식 및 요청 경로에 따라 실제 이름 해석 위치가 달라질 수 있습니다. 이름 해석에 문제가 생기면 이 한 줄만 보고 전체 경로를 판단하지 말고 요청 기록의 도메인과 대상 주소도 함께 확인하세요.

bypass-system = true는 시스템 관련 트래픽을 우회하는 옵션입니다. ‘모든 로컬 주소를 직접 연결한다’는 뜻도 아니고 명시적인 IP 대역 규칙을 대신하지도 않습니다. 시스템 트래픽 처리 범위에 영향을 주므로 변경하면 기록에 표시되는 요청 범위가 달라질 수 있습니다. 특정 LAN 대역만 DIRECT로 연결하려는 경우에는 Rule에 해당 대역을 먼저 지정하고 실제 요청을 검증하세요. 관련 없는 General 필드까지 함께 변경하지 마세요.

저장, 적용, 원격 업데이트는 각각 별개의 작업

편집기에서 저장이 완료되면 내용이 기록되었다는 뜻일 뿐, 해당 파일이 선택되었다는 의미는 아닙니다. 수정 후 Config로 돌아와 현재 설정을 확인하고, Global Routing이 Config를 사용 중인지도 확인하세요. 원격에서 관리되는 설정은 로컬 수정과 원본 파일을 구분해야 합니다. 다시 업데이트하면 로컬 내용이 덮어써질 수 있습니다. 오래 유지할 사용자 규칙은 별도로 백업하고 삽입 위치를 기록하세요. 업데이트로 교체될 수 있는 텍스트에 유일한 사본을 보관하지 마세요.

설정 문제를 확인할 때는 먼저 복구할 수 있는 원본을 저장하고 필드 하나만 수정하세요. 변경 전 네트워크 환경, Global Routing, 테스트 도메인 및 예상 정책을 기록한 뒤 같은 요청으로 다시 검증합니다. 결과가 예상과 다르면 해당 필드를 되돌리고 재시험하는 편이 불분명한 옵션을 여러 개 추가하는 것보다 원인을 찾기 쉽습니다. 특히 서로 다른 출처의 General 내용을 통째로 합치지 마세요. 키가 중복되거나 서로 영향을 주는 설정은 결과를 해석하기 어렵게 만듭니다.

Rule과 규칙 유형

Rule의 기본 형식은 ‘유형, 매칭 내용, 정책’이며 각 필드는 영문 쉼표로 구분합니다. FINAL에는 매칭 내용이 필요하지 않으므로 보통 유형과 정책, 두 필드만 사용합니다. 규칙 키워드는 영문 원문 그대로 유지하고, 도메인 필드에는 프로토콜, 경로 또는 쿼리 매개변수를 넣지 마세요. 아래 예시는 현재 Config를 사용하고 PROXY에 이용 가능한 연결 대상이 설정되어 있다고 가정합니다. 그렇지 않으면 매칭이 정확해도 요청은 성공하지 않을 수 있습니다.

DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD

DOMAIN은 하나의 호스트 이름을 정확히 매칭하며, 특정 하위 도메인만 처리할 때 적합합니다. DOMAIN-SUFFIX는 도메인 접미사의 경계를 기준으로 매칭하므로 루트 도메인과 하위 도메인에 주로 사용합니다. 예를 들어 example.com 접미사 규칙은 api.example.com에도 적용되지만, 끝부분의 문자가 같기만 한 모든 도메인을 매칭하는 것은 아닙니다. DOMAIN-KEYWORD는 도메인에 포함된 키워드를 기준으로 매칭합니다. 범위가 대체로 더 넓으므로 함께 매칭될 수 있는 다른 호스트 이름도 확인해야 합니다.

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

이 순서에서는 api.example.com이 DOMAIN에 먼저 매칭되므로 뒤에 있는 DIRECT 규칙은 적용되지 않습니다. example.com에 속한 다른 하위 도메인은 두 번째 줄에서 처리합니다. 세 번째 줄은 앞의 두 규칙에 매칭되지 않은 요청 중 도메인에 example이 포함된 경우에만 적용될 수 있습니다. 이 예시는 일반적인 권장 설정이 아닙니다. 조건을 일부러 겹치게 구성해 하나의 요청이 여러 규칙에 해당할 때 순서가 왜 중요한지 보여 줍니다.

GEOIP와 IP-CIDR

GEOIP는 대상 IP가 주소 데이터베이스에서 어느 지역에 속하는지를 기준으로 매칭합니다. 예: GEOIP,CN,DIRECT. 웹페이지의 언어, 사이트 등록 국가 또는 사용자의 위치를 판단하는 규칙은 아닙니다. 하나의 도메인이 여러 주소로 연결될 수 있고 데이터베이스에도 갱신 및 적용 범위의 한계가 있습니다. 같은 사이트가 네트워크에 따라 다른 정책을 적용받는다면 규칙이 잘못되었다고 단정하기 전에 실제 대상 IP를 비교하세요.

IP-CIDR은 IPv4 주소와 프리픽스 길이를 나타냅니다. 192.168.0.0/16은 해당 주소 범위 전체를 포함하며 192.168.0.0 하나만 매칭하는 것이 아닙니다. IPv4 주소 하나만 지정하려면 /32를 사용할 수 있습니다. IP-CIDR6은 IPv6에 사용합니다. IP 조건을 확인할 때 대상 주소가 이미 있다면 바로 비교할 수 있습니다. 도메인만 있는 요청을 매칭하기 위해 추가 이름 해석이 필요한지는 규칙 옵션과 실제 기록을 함께 확인하세요.

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

no-resolve는 해당 IP 규칙만을 위해 도메인 이름 해석을 새로 시작하지 않도록 하는 옵션입니다. 이미 확인할 수 있는 대상 IP를 무시한다는 뜻도, 도메인 요청이 반드시 이 대역 규칙에 매칭된다는 뜻도 아닙니다. 호스트 이름으로 LAN 서비스를 이용한다면 DOMAIN 규칙을 별도로 지정해야 할 수도 있습니다. 대역을 추가하기 전에 원격 리소스 주소와 겹치는지도 확인하세요. 범위가 클수록 의도하지 않은 요청까지 포함할 가능성이 높습니다.

USER-AGENT와 FINAL의 적용 범위

USER-AGENT는 확인 가능한 요청의 User-Agent 값을 매칭합니다. 앱의 신원을 확실하게 인증하는 방법이 아니며 암호화된 모든 요청에서 앱 이름을 알아낼 수 있다는 뜻도 아닙니다. 요청에 해당 필드가 포함되어 있는지, 값이 보이는지, 내용이 바뀌었는지에 따라 결과가 달라집니다. 특정 호스트 그룹을 안정적으로 처리하려면 도메인 조건을 우선 확인하세요. USER-AGENT 규칙이 매칭되지 않는다는 이유만으로 확인되지 않은 트래픽까지 범위를 넓히지 마세요.

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

FINAL은 앞선 규칙에 매칭되지 않은 요청을 처리하는 기본 규칙으로, 보통 Rule의 마지막에 둡니다. 오류 처리 규칙이 아니므로 앞에서 매칭된 서버 연결이 실패해도 자동으로 이어받지 않습니다. FINAL을 앞쪽에 두면 뒤에 있는 일반 규칙은 검사되지 않을 수 있습니다. 긴 설정을 확인할 때는 먼저 FINAL의 위치를 찾아 원하는 규칙이 모두 앞에 있는지 살펴보세요. 처음부터 한 줄씩 읽는 것보다 빠를 때가 많습니다.

Host와 이름 해석 범위

Host는 ‘이름을 어떤 주소에 연결할지’를, Rule은 ‘요청에 어떤 정책을 적용할지’를 다룹니다. Host에서 주소를 지정해도 DIRECT를 지정한 것이 아니며 서버나 네트워크 제한을 우회한 것도 아닙니다. 매핑이 의도에 맞는지 판단하려면 실제 요청의 호스트 이름, 매핑된 주소, 최종적으로 매칭된 정책을 각각 확인해야 합니다. 주소가 바뀐 것만으로 전체 연결이 정상이라고 볼 수는 없습니다.

정적 매핑의 기본 형식

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

왼쪽에는 호스트 이름, 오른쪽에는 주소를 작성합니다. 예시 주소는 설명을 위한 것이며 실제 서비스 주소가 아닙니다. 실제 매핑을 사용하기 전에 직접 관리하는 네트워크나 기존 서비스 자료에서 주소를 확인하세요. 한 번 조회한 결과가 계속 유효하다고 가정해서는 안 됩니다. 여기처럼 이름을 하나씩 지정하면 정확한 이름의 매핑을 도메인 전체에 대한 트래픽 분기 규칙으로 오해할 가능성도 줄어듭니다. 처리할 호스트마다 이름 해석 결과를 따로 확인하세요.

매핑은 주소 정보만 바꾸며 웹페이지의 원래 호스트 이름을 다른 이름으로 자동 변경하지 않습니다. HTTPS에서는 인증서 검증과 서버의 호스트 식별도 여전히 중요합니다. 대상 주소에 연결할 수 있어도 원래 호스트 이름에 맞는 서비스를 제공하지 않으면 인증서 불일치, 엉뚱한 사이트 표시 또는 연결 종료가 발생할 수 있습니다. 이런 문제가 생기면 먼저 매핑을 되돌려 차이를 확인하세요. 주소 오류를 감추려고 검증 요구를 낮추지 마세요.

Host만으로 웹사이트 전체를 고정할 수는 없습니다

하나의 페이지가 여러 호스트를 호출하는 경우가 많습니다. 메인 문서, 이미지, API, 로그인 및 정적 파일이 서로 다른 이름을 사용할 수 있습니다. 메인 호스트만 매핑했다고 해서 다른 리소스도 같은 주소를 사용한다고 볼 수 없습니다. 페이지는 열리지만 일부 콘텐츠가 누락되면 요청 기록에서 실패한 리소스의 실제 호스트를 찾아 매핑과 관련이 있는지 확인하세요. 페이지를 완성하려고 매핑 범위를 무작정 넓히거나, 확인되지 않은 주소 하나에 모든 하위 도메인을 연결하지 마세요.

정적 주소는 원래 DNS가 처리하던 부하 분산 선택에도 영향을 줍니다. 기존 주소는 네트워크, 지역 또는 서비스 상태에 따라 달라질 수 있지만 한 주소로 고정하면 이러한 변화가 로컬 매핑에 자동으로 반영되지 않습니다. 일시적인 문제 해결 과정에서는 특정 이름 해석 결과가 문제인지 확인하는 데 매핑을 활용할 수 있습니다. 장기간 유지하려면 명확한 관리 근거가 있어야 합니다. 직접 관리하지 않고 주소가 바뀔 수 있는 서비스에는 정적 매핑을 영구 해결책으로 사용하지 않는 것이 좋습니다.

DNS, 캐시, 요청 경로를 따로 확인하기

Host를 변경한 직후 기존 페이지를 새로 고치면 새 요청이 아니라 기존 연결이 재사용되는 상황을 관찰할 수 있습니다. 앱, 시스템 및 네트워크 경로에도 캐시가 있을 수 있습니다. 검증하려면 변경 전 주소를 기록하고 관련 페이지를 닫거나 기존 요청을 끝낸 다음 같은 호스트로 새 요청을 보내 새 기록을 확인하세요. 기록에 변화가 없다면 같은 줄을 계속 저장하지 말고 현재 설정이 적용되었는지, 요청이 예상한 경로를 지나는지 확인하세요.

일부 연결은 원격에서 도메인 이름을 해석하고, 앱에 따라 직접 이름을 해석하거나 IP 주소를 바로 사용할 수도 있습니다. 따라서 ‘Host에 호스트 이름을 입력했다’고 해서 ‘모든 연결이 해당 매핑을 사용한다’고 볼 수는 없습니다. 실제 연결 유형에 따라 어느 단계에서 이름과 주소를 확인할 수 있는지 살펴보세요. IP에 직접 접속하는 요청에는 애초에 해당 도메인 조회 과정이 없으므로, 도메인 매핑을 더 추가해도 대상은 보통 바뀌지 않습니다.

Host를 한 번 검증할 때는 호스트 하나만 변경하고 예상 주소를 명확히 한 뒤 복구 기록을 남기세요. 매핑을 제거했을 때 문제가 사라지면 매핑이 문제에 영향을 준다는 점은 확인할 수 있습니다. 다만 주소가 유효하지 않은지, 인증서가 일치하지 않는지, 접근 경로가 끊겼는지는 따로 구분해야 합니다. 원인을 기록한 뒤 매핑을 유지할지 삭제할지 결정하세요. 임시 진단 설정을 장기 설정에 남겨 두면 몇 주 뒤 주소가 바뀌었을 때 원인을 찾기 어려울 수 있습니다.

URL Rewrite

URL Rewrite는 URL 표현식에 맞는 요청을 처리하며, 명확한 HTTP 주소를 HTTPS로 리디렉션할 때 자주 사용합니다. DOMAIN 규칙을 다른 문법으로 작성하는 기능이 아니며 PROXY, DIRECT 또는 REJECT 정책을 대신할 수도 없습니다. 설정하기 전에 목적을 먼저 정하세요. 접속 주소를 바꾸려는 것인지 연결 경로만 바꾸려는 것인지 확인해야 합니다. 특정 도메인에 다른 정책을 적용하려는 경우라면 보통 리디렉션이 아니라 Rule을 수정해야 합니다.

범위가 명확한 리디렉션부터 시작하기

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

이 예시는 매칭 표현식, 대상 URL, 상태 코드로 구성됩니다. 앞의 ^는 문자열 시작부터 매칭하고 끝의 $는 문자열 끝까지 매칭합니다. \.은 도메인에 있는 실제 마침표를 나타내며, 정규식의 일반 마침표가 임의의 문자로 해석되는 것을 방지합니다. 이 예시는 지정한 호스트의 HTTP 루트 경로만 매칭해 302 리디렉션을 적용합니다. 해당 호스트의 모든 경로나 쿼리 매개변수를 처리하지는 않습니다.

표현식 범위를 좁게 설정하면 테스트 결과를 해석하기 쉽습니다. 표현식에 도메인만 쓰고 뒤의 내용을 제한하지 않으면 더 많은 경로가 포함될 수 있습니다. 대상도 루트 경로로 고정하면 원래 요청의 경로와 쿼리 정보가 사라질 수 있습니다. 어떤 정보를 유지할지 결정하려면 루트 경로, 하위 경로, 쿼리 매개변수가 있는 요청을 각각 나열하고 표현식을 설계해 검증하세요. 범위가 넓은 조건부터 무작정 시험하지 마세요.

요청에서 확인할 수 있는 정보가 적용 범위를 결정

일반 HTTP URL과 암호화된 연결에서 확인할 수 있는 전체 URL은 같은 조건이 아닙니다. 대상 도메인을 볼 수 있다고 해서 HTTPS 요청의 경로, 쿼리 또는 User-Agent도 읽을 수 있는 것은 아닙니다. 암호화된 트래픽에 관련 처리를 적용할 수 있는지는 별도로 확인해야 합니다. 이 문서의 예시는 명확한 HTTP 요청을 대상으로 하며, 규칙 하나를 적용하려고 인증서 신뢰 설정을 변경하거나 복호화 범위를 넓힐 필요가 없습니다.

브라우저는 기존 보안 정책에 따라 HTTP 요청을 먼저 HTTPS로 업그레이드할 수 있습니다. 그러면 실제 요청은 주소창에 처음 입력한 내용과 달라집니다. 이 경우 예상한 302가 보이지 않는다고 해서 표현식이 잘못되었다고 단정할 수 없습니다. 먼저 매칭 대상인 HTTP 요청이 실제로 전송되었는지 확인하세요. 접속 도구, 브라우저 기록, 사이트 자체의 리디렉션도 관찰 결과에 영향을 줍니다. 테스트 기록에는 최초 요청과 그 뒤에 이어진 요청 체인을 포함해야 합니다.

리디렉션 뒤에는 새로운 요청이 발생

리디렉션을 받으면 클라이언트는 보통 대상 URL에 새 요청을 보냅니다. 새 요청은 주소를 다시 해석하고 규칙의 적용을 다시 받습니다. 원래 요청이 어떤 분기 규칙에 매칭되었더라도 대상 요청에 같은 처리가 그대로 이어진다고 볼 수는 없습니다. 리디렉션 대상의 호스트 이름이 바뀌면 새 호스트가 다른 DOMAIN 또는 DOMAIN-SUFFIX 규칙에 매칭되는지, 이름 해석과 연결이 정상인지 특히 확인하세요.

리디렉션 루프는 로컬 규칙이 주소를 HTTPS로 보내고 서버는 같은 진입점을 원래 HTTP 주소로 되돌리는 것처럼 조건이 충돌할 때 흔히 발생합니다. 계속 이동하거나 로드에 실패하거나 브라우저에 리디렉션 횟수 초과 오류가 나타날 수 있습니다. 이런 경우 새로 추가한 재작성 규칙을 먼저 비활성화하고 원래 사이트의 동작을 확인한 다음, 각 단계에서 반환하는 주소를 살펴보세요. 더 넓은 재작성 규칙을 추가해 증상만 덮지 마세요. 루프의 원인을 찾기 어려워집니다.

로그인, 양식 또는 임시 인증 정보가 포함된 URL을 다룰 때는 특히 주의하세요. 쿼리 매개변수에 민감한 정보가 들어 있을 수 있으므로 테스트 기록을 공유하기 전에 삭제해야 합니다. 요청 방식과 리디렉션 상태 코드의 상호 작용도 주소만 바뀐 것을 보고 추측할 수 없습니다. 처음에는 직접 관리하고 로그인 상태가 필요 없는 일반 페이지로 검증하세요. 표현식이 예상한 요청만 처리하는지 확인한 뒤 실제 상황에 적용할지 판단하세요.

정책과 Global Routing

정책은 요청이 매칭된 뒤 어떻게 처리할지를 지정하고, Global Routing은 현재 전체 트래픽에 어떤 라우팅 모드를 사용할지 정합니다. 문제를 확인할 때는 Global Routing을 먼저 보고 규칙의 정책 필드를 확인하세요. 그렇지 않으면 Rule을 꼼꼼하게 살펴도 현재 처리에 예상대로 적용되지 않는 설정만 계속 검증할 수 있습니다. 한국어 설명에서는 설정, 프록시, 직접 연결이라고 할 수 있으며 각각의 인터페이스 용어는 Config, Proxy, Direct입니다.

PROXY、DIRECT、REJECT

PROXY는 프록시 경로를 사용한다는 뜻이며 이용 가능한 연결 대상이 이미 있어야 합니다. 특정 서버 주소를 뜻하거나 인증 정보를 자동으로 채우는 값은 아닙니다. DIRECT는 대상에 직접 연결한다는 뜻이지만 대상에 도달할 수 있다는 보장은 없습니다. 현재 네트워크의 라우팅, DNS 및 대상 서비스 상태는 여전히 영향을 줍니다. REJECT는 해당 요청을 거부합니다. 차단할 대상이 명확한 경우 사용하며, 실패한 뒤 다른 경로를 시도하는 기능으로 오해해서는 안 됩니다.

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

예시의 호스트 이름은 세 가지 동작을 설명하기 위한 것입니다. api.example.com은 매칭된 뒤 PROXY를 사용합니다. 연결에 실패해도 자동으로 다음 줄의 DIRECT를 시도하지 않습니다. printer.example.com은 직접 연결하지만 성공 여부는 이름 해석 결과와 현재 네트워크에서 해당 주소에 도달할 수 있는지에 달려 있습니다. blocked.example.com은 명시적으로 거부되므로 요청 실패는 예상된 정책 결과이며 서버 장애로 분류해서는 안 됩니다.

세 가지 전체 라우팅 모드 비교

Proxy에서는 접속되지만 Config에서는 실패한다면 Config에서 어떤 정책에 매칭되었는지 계속 확인해야 합니다. 다만 특정 규칙 키워드가 잘못되었다고 바로 단정해서는 안 됩니다. 두 모드에서 이름 해석 위치, 대상 주소 또는 연결 경로가 다를 수 있습니다. 신뢰할 수 있는 비교를 하려면 호스트, 실제 주소와 처리 정책을 함께 기록해 차이가 어느 단계에서 시작되는지 확인하세요. 페이지가 열렸는지만 기록해서는 안 됩니다.

Direct에서 실패하고 Proxy에서 성공한다고 해서 전체 설정을 PROXY로 바꿔야 하는 것은 아닙니다. LAN 기기, 현재 네트워크에서만 열리는 서비스 및 일부 리소스에는 DIRECT가 필요할 수 있습니다. Global Routing을 임시로 바꾸면 문제 범위를 좁히는 데 도움이 됩니다. 장기 정책은 각 리소스의 요구 사항을 파악한 뒤 Rule에 설정하세요. 비교를 마치면 원래 모드로 되돌려야 이후 새 규칙을 잘못된 모드에서 판단하지 않습니다.

정책 이름과 실제 연결 가능 여부를 따로 확인

일부 설정은 사용자 지정 정책 이름을 참조합니다. 이런 파일을 읽을 때 영어처럼 보이는 값이 모두 기본 제공 정책이라고 가정하지 마세요. 현재 설정에 해당 이름의 정의가 있는지, 어떤 연결 대상을 가리키는지, 대상이 여전히 존재하는지 확인해야 합니다. 기본적인 트래픽 분기부터 익히려면 복잡한 선택 구조를 함께 사용하는 것보다 PROXY, DIRECT, REJECT로 흐름을 먼저 파악하는 편이 좋습니다.

연결 대상이 작동하지 않아도 규칙은 정상적으로 매칭될 수 있습니다. 인증 정보가 바뀌었거나 서버 주소에 일시적으로 연결할 수 없거나 서버가 현재 매개변수를 지원하지 않으면 ‘정책은 올바르게 선택됐지만 연결은 실패’할 수 있습니다. 이때 DOMAIN 매칭 범위를 계속 바꿔도 서버 문제는 해결되지 않습니다. 기존 서비스 자료를 바탕으로 주소, 포트 및 인증 정보를 확인한 뒤 Connectivity Test를 실행하고, 실제 서비스 요청 결과와는 별도로 기록하세요.

마찬가지로 연결 테스트가 성공해도 테스트에 포함된 일부 경로에서 응답을 받았다는 뜻일 뿐, 모든 대상, 프로토콜 및 서비스 작업이 성공한다는 보장은 없습니다. 웹 요청, 장시간 연결 및 다른 전송 방식에는 각각 다른 조건이 적용될 수 있습니다. 특정 서비스만 실패한다면 테스트 한 번이 성공했다는 이유로 서버나 대상 서비스 문제를 완전히 배제하지 말고, 해당 서비스가 사용하는 호스트와 요청 유형부터 확인하세요.

기존 구독에 포함된 서버와 로컬 규칙은 서로 다른 관리 대상입니다. 구독을 업데이트하면 선택할 수 있는 연결 대상이 바뀔 수 있지만 로컬 규칙 순서가 수정되는 것은 아닙니다. Rule을 편집해도 만료된 서버 매개변수는 업데이트되지 않습니다. 업데이트 작업의 차이는 구독 업데이트와 실패 원인에서 확인하세요. 서버 정보 변경과 설정 파일 변경을 혼동하지 않도록 주의하세요.

매칭 순서와 우선순위

Rule은 위에서 아래로 검사하며, 처음 매칭된 규칙이 정책을 결정합니다. ‘더 구체적인 규칙을 우선한다’는 설정 작성 원칙이지 자동 정렬 기능이 아닙니다. DOMAIN이 더 정확하다는 이유만으로 앞에 있는 DOMAIN-SUFFIX를 건너뛰지 않으며 IP-CIDR도 뒤에 있는 도메인 조건보다 자동으로 우선하지 않습니다. 원하는 우선순위를 적용하려면 예외 규칙을 이를 포함하는 넓은 조건보다 앞에 직접 배치해야 합니다.

같은 요청을 기준으로 한 줄씩 확인하기

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

api.example.com을 예로 들면 첫 번째 줄에 정확히 매칭되므로 뒤의 도메인 접미사, 키워드, IP 지역 및 FINAL은 이 요청의 정책을 결정하지 않습니다. www.example.com은 첫 번째 줄에 매칭되지 않고 두 번째 줄의 접미사 규칙에 매칭되어 DIRECT를 사용합니다. 앞의 두 줄에 모두 매칭되지 않을 때만 세 번째 키워드 규칙이 적용될 수 있습니다. 줄별로 검토할 때는 ‘조건 충족 여부’와 ‘매칭 후 동작’을 두 칸으로 나눠 기록하면 키워드만 보고 건너뛰는 일을 줄일 수 있습니다.

두 번째 줄을 첫 번째 줄보다 위로 옮기면 api.example.com이 접미사 규칙에 먼저 매칭되어 기존의 정확한 예외가 적용되지 않습니다. DOMAIN의 매칭 기능이 달라진 것이 아니라 검사 순서가 바뀐 결과입니다. 이 점을 이해하면 새 규칙이 전혀 적용되지 않는 상황에서 파일 끝에 같은 조건을 계속 추가하기보다 해당 요청을 이미 처리하는 상위 규칙이 있는지 먼저 살펴볼 수 있습니다.

넓은 규칙과 좁은 규칙의 배치

흔히 명확한 예외를 먼저 두고, 도메인 그룹이나 범위가 넓은 조건을 배치한 뒤 필요한 IP 규칙을 두고, 마지막에 FINAL을 둡니다. 다만 이는 관리하기 편한 구성 방식일 뿐 모든 상황에 적용되는 고정 순서는 아닙니다. 관리하는 특정 네트워크 대역을 반드시 직접 연결해야 한다면 관련된 넓은 조건보다 앞에 놓아야 할 수도 있습니다. 핵심은 요구 사항을 먼저 명확히 하고 실제 요청과 겹치는 조건을 확인하는 것이며, 한 가지 순서를 기계적으로 따라 하는 것이 아닙니다.

하나의 대상이 도메인 조건과 IP 조건을 동시에 충족할 수 있습니다. 예를 들어 지정한 도메인 접미사에 속하면서 해석된 주소가 특정 GEOIP 범위에 포함될 수 있습니다. 어느 규칙이 최종 적용되는지는 실제로 확인할 수 있는 정보와 규칙 순서에 따라 달라집니다. IP 규칙에 no-resolve를 추가했다면 도메인만 있는 요청에서 추가 이름 해석을 수행하는지도 고려해야 합니다. 텍스트에 적힌 순서와 요청 당시 아직 확인할 수 없는 정보를 혼동하지 마세요.

FINAL은 다시 시도하는 규칙이 아닙니다

FINAL은 앞선 규칙에 아직 매칭되지 않은 요청만 처리합니다. 어떤 규칙이 이미 PROXY를 선택한 뒤 서버 연결이 실패하더라도 ‘매칭되지 않은 요청’이 되는 것은 아니므로 Rule에서 다음 DIRECT나 FINAL을 찾지 않습니다. 대체 연결 기능이 필요하면 해당 연결 또는 정책 설정이 실제로 지원하는 방식을 확인하세요. 오류 복구를 기대하며 FINAL을 반복해서 추가하지 마세요. Rule은 선택을 담당하고 연결 실패는 선택 이후 단계에서 발생합니다.

문제 해결 시 ‘원하는 규칙에 매칭되지 않음’과 ‘원하는 규칙에 매칭됐지만 실행에 실패함’을 구분해야 합니다. 전자는 호스트, 규칙 유형, 순서 및 현재 설정을 확인하고 후자는 연결 대상, 이름 해석 결과 및 대상 서비스를 확인하세요. 두 상황을 섞으면 트래픽 분기 범위를 바꾸면서 요청 경로까지 의도치 않게 달라질 수 있습니다. 결과적으로 한 번 성공하더라도 실제 원인을 설명하기 어려워집니다.

긴 규칙을 관리할 때는 각 예외가 어떤 넓은 규칙을 덮어쓰는지와 유지하는 이유를 기록해 두세요. 중복 내용을 삭제하기 전에는 도메인뿐 아니라 전체 필드를 비교해야 합니다. 같은 도메인이라도 정책이 다르거나 같은 대역에 다른 옵션이 붙어 있다면 불필요한 중복이 아닐 수 있습니다. 정리 후에는 미리 선택한 대표 요청으로 확인하세요. 정확한 예외 하나, 일반 하위 도메인 하나, FINAL에 도달해야 하는 대상 하나를 포함하는 것이 좋습니다.

자주 쓰는 설정과 변경 절차

아래에서는 요구 사항별로 설정 예시를 나눠 설명합니다. 각 조각은 하나의 주요 목적만 보여 주며, 모두 합치면 어떤 네트워크에서나 사용할 수 있는 설정이 되는 것은 아닙니다. 사용하기 전에 처리할 대상을 직접 지정하고 기존 서버 정보를 유지한 뒤 현재 파일의 다른 규칙이 먼저 매칭되지 않는지 확인하세요. 기존 설정에 FINAL이 있다면 필요한 예외는 원래의 마지막 규칙보다 앞에 배치하세요. 서로 겹치는 끝부분 규칙을 새로 덧붙이지 마세요.

같은 도메인에서 특정 호스트만 예외 처리

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

특정 API에는 PROXY를 사용하고 같은 도메인의 다른 호스트에는 DIRECT를 적용하는 경우입니다. 구체적인 규칙을 넓은 규칙보다 먼저 두는 것이 핵심입니다. 테스트할 때는 api.example.com과 실제로 존재하는 다른 하위 도메인을 각각 방문해 서로 다른 정책이 적용되는지 확인하세요. API 요청이 성공했다는 것만으로 예외가 올바르게 적용됐다고 볼 수는 없습니다. 전체 Proxy 모드에서도 성공할 수 있기 때문에 접미사 규칙이 실제로 사용됐는지 별도로 확인해야 합니다.

API에서 리디렉션이 발생하거나 페이지가 다른 도메인을 호출하면 후속 요청도 확인해야 합니다. 첫 요청에 정확한 예외가 적용됐다는 것은 그 요청 하나의 처리가 올바르다는 뜻입니다. 여러 독립 호스트가 함께 동작하는 서비스는 실제 기록을 바탕으로 하나씩 정리하세요. 화면에 보이는 진입점 하나가 전체 리소스 목록이라고 가정하지 마세요. 범위를 넓히기 전에 추가하려는 호스트가 해당 서비스에 실제로 필요한지 확인해야 합니다.

LAN 대역과 호스트 이름은 각각 설정

[Rule]
DOMAIN,printer.example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
FINAL,PROXY

이 예시는 호스트 이름과 주소 대역을 각각 직접 연결하도록 지정합니다. 호스트 이름에는 예시가 아니라 직접 관리하는 환경의 실제 이름을 입력하세요. no-resolve를 사용하는 대역 규칙은 모든 도메인이 이름 해석 후 매칭된다는 보장이 아니므로, 명확한 LAN 호스트 이름은 별도 규칙으로 지정할 수 있습니다. 테스트 전에 기기에 접근할 수 있는 네트워크에 실제로 연결되어 있는지도 확인하세요. DIRECT는 다른 곳의 LAN으로 가는 경로를 자동으로 만들어 주지 않습니다.

같은 주소 범위가 다른 관리 네트워크에서도 사용된다면 대역 규칙이 용도가 다른 대상까지 포함할 수 있습니다. 특히 여러 네트워크에서 사설 주소가 겹치는 경우, 주소가 ‘내부 네트워크처럼 보인다’는 이유만으로 경로를 결정해서는 안 됩니다. 접속할 기기, 실제 네트워크 및 대상 주소를 먼저 정리하고 필요한 범위만 지정하세요. 기기 하나만 대상으로 한다면 처음부터 큰 대역을 포함하기보다 더 좁은 프리픽스를 고려할 수 있습니다.

주소 지역에 따른 분기와 마지막 기본 규칙

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

이 예시는 정확한 예외 하나, 주소 지역 조건 하나, 기본 규칙 하나를 보여 줍니다. 웹사이트의 콘텐츠나 언어에 따라 분류하는 규칙은 아닙니다. 여러 주소를 사용하는 서비스는 해석된 IP가 달라지면 GEOIP 결과도 달라질 수 있습니다. URL만 기록하지 말고 실제 주소도 포함해 테스트하세요. 요구 사항이 특정 도메인 그룹에 관한 것이라면 명시적인 도메인 규칙이 더 쉽게 해석될 수 있지만, 실제 리소스와 네트워크 조건에 따라 판단해야 합니다.

FINAL에서 PROXY를 선택하려면 사용자가 이용 가능한 서버를 보유하고 있으며 일치하지 않은 요청을 해당 경로로 보내려는 상황이어야 합니다. 관리 목적이 다르다면 다른 기본 정책을 선택할 수 있지만, 명시적으로 지정하지 않은 다수의 요청에 영향을 준다는 점을 고려해야 합니다. FINAL 변경은 영향 범위가 큰 작업입니다. 페이지 하나가 열리는지만 보지 말고 일상적으로 사용하는 대표 리소스도 함께 검증하세요.

보관, 수정, 검증, 복구

1. 현재 설정 원문을 저장하고 선택한 파일, Global Routing 및 연결 대상을 기록합니다.
2. ‘지정한 호스트를 DIRECT에서 PROXY로 변경’처럼 검증 가능한 요구 사항을 하나 작성합니다.
3. 기존 규칙을 검색해 해당 호스트를 가장 먼저 처리할 수 있는 조건을 찾고 삽입 위치를 정합니다.
4. 한 곳만 수정해 저장한 뒤 현재 설정이 여전히 이 파일인지 확인합니다.
5. 새 요청을 보내 매칭 규칙, 대상 주소, 정책 및 실제 결과를 확인합니다.
6. 결과가 예상과 다르면 원문을 복구하고 같은 대상을 재시험한 뒤 차이를 기록합니다.

복구용 파일을 자동 업데이트 중인 원본과 혼용하지 마세요. 특히 구독이나 원격 설정을 업데이트한 뒤 사용자 규칙이 예상한 위치에 남아 있는지, 규칙이 참조하는 연결 대상이 바뀌었는지 다시 확인해야 합니다. 업데이트가 완료되어도 가져오기 작업이 끝났다는 뜻일 뿐 기능 검증을 대신하지 않습니다. 수정할 내용이 많다면 한 번에 전체 설정을 덮어쓰기보다 작동하는 상태를 단계별로 보관해야 문제를 일으킨 변경을 찾기 쉽습니다.

검증과 문제 해결

검증의 목표는 연결 스위치가 켜져 있는지만 확인하는 것이 아닙니다. 특정 요청이 예상한 설정을 사용하고, 예상한 조건에 매칭되며, 해당 경로를 통해 결과를 얻는지 확인해야 합니다. 테스트 대상을 하나 정하고 ‘서버, Global Routing, DNS, 규칙, 대상 서비스’ 순서로 점검하세요. 각 단계를 마칠 때 확인된 사실과 아직 배제하지 못한 원인을 기록합니다. 한 번의 테스트에서 구독 업데이트, 서버 변경, DNS 수정까지 동시에 하지 마세요.

연결 대상부터 실제 요청까지

먼저 사용자가 보유한 서버의 주소, 포트, 인증 및 프로토콜 매개변수를 확인한 뒤 Connectivity Test를 실행해 기본 연결 상태를 살펴보세요. 테스트에 실패하면 Rule 순서를 즉시 바꾸기보다 현재 네트워크와 서비스 정보를 먼저 확인하세요. 응답이 있으면 실제 서비스 요청을 보내 특정 호스트만 실패하는지 확인합니다. 기본 테스트와 실제 서비스 요청은 서로 다릅니다. 전자에서 응답을 받았다고 해서 후자에 필요한 모든 경로와 매개변수가 올바르다는 뜻은 아닙니다.

그다음 Global Routing을 확인하세요. 현재 모드가 Proxy 또는 Direct라면 상태를 기록한 뒤 Config로 전환해 규칙을 검증합니다. Config에서 결과가 예상과 다르면 실제 요청의 호스트 이름과 대상 주소가 사전에 정한 테스트 대상과 일치하는지 확인하세요. 페이지가 리디렉션되거나 별도의 API를 호출할 수 있습니다. 오류가 발생한 호스트가 주소창의 호스트와 다를 수 있으므로 진입 도메인에 규칙을 계속 추가하는 데 그치지 마세요.

기록을 바탕으로 세 가지 실패 유형 구분

첫 번째는 규칙이 예상대로 매칭되지 않는 경우입니다. 현재 설정이 잘못됐거나 매칭 내용을 잘못 작성했거나 상위 규칙이 먼저 처리했을 수 있습니다. 두 번째는 정책은 올바르지만 연결에 실패하는 경우입니다. 서버 연결 가능 여부, 주소 및 대상 서비스를 확인해야 합니다. 세 번째는 이름 해석 단계의 문제입니다. 도메인이 주소로 해석되는지, 주소가 예상과 맞는지, Host가 결과를 덮어쓰는지 비교해야 합니다. 세 유형을 나누면 수정 범위를 크게 줄일 수 있습니다.

기록에 REJECT가 표시되면 설정으로 돌아가 해당 조건을 찾아 원래 해당 대상을 차단하려고 했는지 확인하세요. DIRECT가 표시되지만 해당 리소스가 기존 원격 연결을 통해서만 접근 가능하다면 정책 의도를 살펴보세요. PROXY가 표시되는데 서버 인증에 실패한다면 먼저 기존 서비스 정보를 확인해야 합니다. 오류 메시지는 원인을 찾는 단서일 뿐, 실제 매칭 규칙과 연결 대상을 확인하는 과정을 건너뛸 수는 없습니다.

On Demand와 규칙 분기를 따로 검증

On Demand는 조건에 따라 연결 또는 연결 해제를 수행하고, Rule은 연결이 작동하는 동안 요청을 처리합니다. 자동 연결이 실행되지 않았다고 해서 먼저 도메인 규칙이 잘못됐다고 판단하지 마세요. 현재 네트워크가 On Demand 조건을 충족하는지, 연결이 실제로 이루어졌는지 확인해야 합니다. 반대로 연결이 이루어졌다고 모든 요청이 PROXY를 사용한다는 뜻은 아닙니다. Config에서는 일부 요청이 DIRECT 또는 REJECT로 처리될 수 있습니다.

자동 동작을 검증할 때는 먼저 수동으로 연결해 같은 설정에서 요청이 올바르게 처리되는지 확인한 뒤, 네트워크를 전환했을 때 자동 연결이 실행되는지 따로 테스트하세요. 전환 전후의 네트워크, 연결 상태 및 요청 시간을 기록하고 조건과 Rule을 동시에 변경하지 마세요. 자세한 시나리오는 On Demand의 Wi-Fi, 셀룰러 네트워크 및 도메인 조건을 참고하세요. 백그라운드 연결 설정은 백그라운드 배터리 소모와 연결 유지 안내를 참고하세요.

자주 확인하는 질문

문제 해결 기록을 공유하기 전에 구독 전체 주소, 인증 정보, 개인 네트워크 이름 및 기타 민감한 내용을 삭제하세요. 보통 정보를 가린 호스트, 규칙 유형, 정책 및 오류 발생 단계만으로도 문제를 설명할 수 있습니다. 점검이 끝나면 임시로 바꾼 Global Routing을 원래대로 되돌리고, 더 이상 필요 없는 Host 또는 재작성 테스트 항목을 삭제한 뒤 검증을 마친 설정을 다시 저장하세요. 비슷한 문제가 생기면 이 기준 설정을 먼저 참고해 항목별로 재시험할 수 있습니다.