Shadowrocket
규칙 및 설정 가이드

설정 파일 구조

Shadowrocket 설정 파일은 보통 .conf 형식으로 저장하며, 대괄호로 섹션을 구분하고 각 섹션에 해당 내용을 입력합니다. 모든 설정을 글로 나열한 기록도, 서버 구독과 같은 것도 아닙니다. 파일을 읽을 때는 먼저 섹션 이름을 확인하고 그 안에서 허용되는 항목 형식을 살펴보세요. 같은 문장이라도 섹션에 따라 적용되지 않거나 구문 오류가 될 수 있으므로, 키워드만 보고 설정이 올바르다고 판단하면 안 됩니다.

각 섹션의 역할

[General]에는 일반 동작 및 해석 관련 옵션을 넣으며, 보통 항목 이름, 등호, 값 순으로 작성합니다. [Rule]에는 순서대로 확인하는 트래픽 분기 규칙을 넣으며, 일반적으로 유형, 조건, 정책으로 구성됩니다. [Host]는 지정한 호스트 이름을 주소에 정적으로 연결합니다. [URL Rewrite]는 조건에 맞는 요청 URL을 변경합니다. 파일의 빈 줄 수보다 섹션 이름과 해당 내용의 관계가 중요합니다.

이 네 섹션을 고정된 처리 순서로 이해하면 안 됩니다. 요청이 모든 General 항목을 거친 뒤 Host와 Rewrite를 차례로 통과하는 것은 아닙니다. General은 클라이언트 동작을 변경하고, Host는 이름 해석에 영향을 주며, Rule은 트래픽 정책을 결정하고, Rewrite는 조건에 맞는 요청 URL을 처리합니다. 각 기능의 적용 조건은 서로 다릅니다. 파일에서 섹션의 위치를 바꿔도 네트워크 처리 순서가 달라지는 것은 아니며, 직접적인 우선순위는 Rule 목록의 배열 순서에만 적용됩니다.

[General]
dns-server = system

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

[Host]
# 고정 매핑이 필요할 때만 항목을 추가하세요

[URL Rewrite]
# 대상 요청을 확인한 뒤에만 Rewrite를 추가하세요

구독과 설정 파일은 따로 관리

서버 구독은 주로 연결 항목을 가져오고 업데이트하는 데 쓰이며, 설정 파일은 해당 연결을 요청 처리에 어떻게 적용할지 정의합니다. 직접 구독을 가져온 뒤 Home에 서버가 표시되어도 분기 설정 파일이 활성화된 것은 아닙니다. 반대로 PROXY 규칙이 포함된 파일을 가져와도 연결 가능한 서버가 생기는 것은 아닙니다. 규칙은 읽히지만 연결할 수 없다면 서버 선택과 설정 적용 여부를 각각 확인하세요. 같은 파일을 반복해서 가져오지는 마세요.

원격 설정은 별도로 관리해야 하는 또 다른 항목입니다. 업데이트할 때 로컬 수정 사항이 유지되는지는 실제 업데이트 및 편집 방식에 따라 달라집니다. 중요한 변경 사항은 먼저 복사본으로 저장한 뒤 새로 고침하세요. 구독 업데이트가 규칙을 자동으로 수정해 준다고 가정하거나 서버 구독이 만료되면 로컬 규칙도 손상된다고 단정하지 마세요. 구독 새로 고침은 구독 업데이트 방법을 참고하세요. 이 페이지에서는 설정 자체를 설명합니다.

설정 파일에는 서버 인증 정보, 사설 주소, 요청 기록 관련 설정, Rewrite 대상이 포함될 수 있습니다. 파일을 공유하기 전에 눈에 보이는 서버 이름뿐 아니라 URL 매개변수, 주석, 정적 매핑도 항목별로 확인하세요. 문제 해결에 필요한 경우 보통 관련 규칙 몇 줄과 현재 모드, 오류 현상만 공유하면 됩니다. 전체 구독 주소를 보낼 필요는 없습니다. 예시의 example.com은 설명용 도메인이므로 다른 사람의 실제 서비스 정보로 바꾸어 공개하지 마세요.

편집, 저장 및 활성화

Config에서 수정할 설정을 찾은 다음, 현재 사용 중인 파일인지 확인하고 복구할 수 있는 복사본을 만드세요. 수정이 끝나면 저장한 뒤 현재 선택된 설정이 방금 편집한 파일인지 확인합니다. 파일 이름이 같다고 내용까지 같은 것은 아닙니다. 원격에서 다시 내려받은 파일과 로컬 편집본이 함께 표시될 수도 있습니다. 특히 여러 설정을 시험할 때는 목록의 이름만 보는 것보다 파일 내용을 비교하는 편이 확실합니다.

일반 텍스트를 편집할 때는 영문 쉼표, 대괄호, 등호를 그대로 사용하고 한국어 문장 부호로 바꾸지 마세요. 규칙은 한 줄에 하나씩 작성하고, 주석은 별도 줄에 #으로 시작하세요. 정책 뒤에 설명을 임의로 덧붙이지 마세요. 편집기에서 자동 줄 바꿈이 되어도 실제 개행 문자가 삽입되지 않았다면 대개 하나의 규칙입니다. 복사할 때 긴 주소가 실제로 나뉘지 않았는지 확인해야 항목을 올바르게 읽을 수 있습니다.

처음에는 작은 규칙 집합으로 검증하세요. 먼저 명확한 도메인 조건 하나와 FINAL만 남기고 결과를 확인한 뒤 IP, Host 또는 Rewrite를 추가합니다. 수정 후 문제가 생기면 패치를 계속 덧붙이기보다 복사본을 복원하는 편이 원인을 찾기 쉽습니다. 아래 예시는 각 기능의 일부 동작을 보여줄 뿐, 모든 예시를 한 파일에 합치라는 뜻은 아닙니다. 실제 파일에는 현재 목적에 맞고 용도를 설명할 수 있는 항목만 남겨 두세요.

General 및 DNS

General은 설정 동작을 점검하는 출발점이지만, 이해하지 못하는 항목을 통째로 복사하는 것은 피하세요. 설정 파일을 가져올 수 있다는 것은 텍스트를 읽었다는 뜻일 뿐, 각 항목이 현재 환경에 맞다는 의미는 아닙니다. 먼저 항목이 앱의 어떤 설정에 해당하는지와 관련 설명을 확인한 뒤 기본 동작을 덮어써야 하는지 판단하세요. 네트워크 이름 해석 문제에서는 특히 이름 조회 실패, 주소는 얻었지만 연결할 수 없는 경우, 연결 정책 선택 오류를 구분해야 합니다.

최소한의 항목부터 시작

dns-server = system은 시스템이 제공하는 DNS 해석 경로를 사용한다는 뜻입니다. 비교를 위한 기본값으로 적절하지만, 모든 네트워크에서 결과가 같다는 의미는 아닙니다. 시스템에서 사용하는 DNS 서버는 Wi-Fi, 셀룰러 네트워크, 상위 라우터 환경에 따라 달라질 수 있습니다. 테스트할 때는 현재 네트워크도 함께 기록하세요. 같은 파일의 결과가 달라졌다면 설정 저장 실패가 아니라 DNS 경로가 바뀐 것일 수 있습니다.

[General]
dns-server = system

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

이 예시는 도메인 규칙과 시스템 DNS의 관계를 분리해 확인하기 위한 것으로, 모든 상황에 적용할 권장 설정은 아닙니다. 기존 설정에 다른 General 항목이 있어도 예시에 맞추려고 모두 삭제할 필요는 없습니다. 먼저 백업하고 한 번에 항목 하나만 바꿔 실패 현상이 달라지는지 확인하세요. 앱의 전역 설정과 파일 항목이 실제로 어떻게 적용되는지는 현재 앱 화면과 요청 기록을 기준으로 판단해야 합니다. 한 가지 예시만으로 모든 옵션의 우선 적용 관계를 추측하지 마세요.

설정의 불리언 값, 주소 목록, 숫자 매개변수는 각각 해당 항목의 형식을 따라야 합니다. 값 뒤에 설명용 한국어를 붙이지 말고, 다른 소프트웨어에서 같은 이름으로 쓰는 항목의 값을 그대로 가져오지도 마세요. 특히 프록시 우회, 라우트 제외, DNS 설정은 이름이 비슷해 보여도 서로 다른 계층에 영향을 줍니다. 트래픽이 클라이언트에 들어오지 않는다면 Rule 순서를 계속 조정해도 예상한 변화가 생기지 않습니다.

도메인 해석과 규칙 매칭

DOMAIN 및 DOMAIN-SUFFIX는 알려진 호스트 이름을 조건으로 판단할 수 있으며, IP-CIDR 및 GEOIP에는 대상 주소 정보가 필요합니다. 클라이언트가 IP 규칙을 확인하기 위해 도메인을 해석하는 경우 DNS에 실패하면 해당 조건이 예상대로 평가되지 않을 수 있습니다. 규칙에 no-resolve가 있으면 해당 IP 조건만을 위해 추가 해석을 요청하지 않는다는 뜻입니다. 요청 전체에서 DNS를 금지하거나 모든 연결을 숫자 주소로 강제하는 것은 아닙니다.

앱이 IP에 직접 연결하거나 자체 방식으로 주소를 얻는 경우에는 클라이언트가 원래 도메인 이름을 알지 못할 수도 있습니다. 브라우저 주소창에 도메인이 보인다고 해서 모든 하위 연결에 사용할 수 있는 도메인 정보가 포함된다고 단정하지 마세요. 웹페이지는 여러 리소스 호스트에 동시에 요청할 수 있습니다. 요청 기록을 확인할 때는 주 사이트, 정적 리소스, API 요청을 각각 구분하고 실제 규칙이 도메인과 주소 중 무엇을 기준으로 처리하는지 살펴보세요.

이름 해석이 성공해도 연결은 실패할 수 있습니다. 현재 경로에서 반환된 주소에 도달할 수 없거나 PROXY에 사용하는 서버가 해당 대상에 연결하지 못할 수 있습니다. DNS를 바꾼 뒤 현상이 잠시 달라졌다고 해서 원인이 해결된 것은 아닙니다. 주소 캐시, 연결 재사용, 대상의 복수 주소 응답이 관찰 결과에 영향을 줄 수 있습니다. 같은 네트워크에서 테스트를 반복하고 실제 연결 주소를 비교하세요. 웹페이지가 처음 열렸는지만 비교하지 마세요.

IPv6, 캐시 및 검증 범위

IPv6를 지원하는 네트워크에서는 여러 주소 유형의 결과가 함께 반환될 수 있습니다. IPv4 대역 규칙만 작성해도 IPv6 연결까지 자동으로 처리되는 것은 아닙니다. 반대로 주소 유형을 제한해도 잘못된 라우팅이나 이름 해석을 고칠 수는 없습니다. 문제를 확인할 때 먼저 실패한 연결이 어떤 주소 유형을 사용하는지 살펴본 뒤 IP-CIDR6를 추가할지, 상위 네트워크 지원을 확인할지 결정하세요. 듀얼 스택의 모든 이상을 도메인 규칙 탓으로 돌리지 마세요. 도메인 조건과 주소 도달 가능성은 별개의 문제입니다.

캐시 때문에 방금 수정한 설정이 적용되지 않은 것처럼 보일 수 있습니다. DNS 캐시는 해석 결과를 저장하고, 브라우저나 앱은 기존 연결을 재사용할 수도 있습니다. 새 규칙을 저장했다고 기존 연결이 반드시 처음부터 다시 매칭되는 것은 아닙니다. 검증 전에 관련 요청을 종료하고, 필요하면 클라이언트를 다시 연결한 뒤 새 요청을 보내세요. 페이지를 연속으로 새로 고침해도 DNS 해석과 연결이 완전히 새로 시작된다고 볼 수 없습니다. 기록의 시간과 대상 주소가 더 유용한 단서입니다.

여러 도메인을 해석할 수 없다면 먼저 작동했던 General 기본 설정으로 복원하고 현재 네트워크를 확인하세요. 특정 도메인만 문제가 있다면 철자, Host 매핑, 해당 도메인의 실제 해석 결과를 확인합니다. 같은 대상이 Direct에서는 열리고 Proxy에서는 실패한다면 서버 경로를 점검하고 DNS 경로를 계속 바꾸지 마세요. 전체 연결 문제 해결 순서는 연결은 켜졌지만 인터넷이 안 될 때를 참고하세요.

도메인 규칙 유형

도메인 조건은 사이트나 서비스 이름을 기준으로 트래픽을 분기할 때 적합합니다. 자주 사용하는 DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD는 같은 의미의 표현이 아닙니다. 매칭 범위가 차례로 넓어지며, 잘못 매칭될 가능성도 달라집니다. 먼저 호스트 이름 하나, 도메인과 그 하위 도메인, 특정 문자열을 포함하는 모든 호스트 중 무엇을 대상으로 할지 정하세요. 그런 다음 가장 범위가 좁은 조건으로 구현하세요. 넓은 키워드부터 작성하고 예외를 많이 추가하는 방식은 피하는 것이 좋습니다.

DOMAIN 정확히 일치

DOMAIN,example.com,PROXY는 호스트 이름 example.com에 PROXY를 적용한다는 뜻입니다. api.example.com이 같은 사이트에 속한다고 해서 해당 하위 도메인까지 자동으로 포함하지는 않습니다. 정확 일치 규칙은 로그인 API, 다운로드 호스트, 확인된 특정 요청을 별도로 처리할 때 적합합니다. 범위를 설명하고 기록과 대조하기 쉽지만, 사이트에서 새 리소스 도메인을 추가하면 규칙을 보완할지 다시 판단해야 합니다.

규칙의 도메인에는 프로토콜, 포트, 경로를 넣지 마세요. 전체 URL을 DOMAIN에 입력하면 URL에 해당하는 내용이 호스트 조건에 섞입니다. example.com의 특정 페이지에 접속할 때 규칙은 경로 문자를 기준으로 판단하지 않습니다. 같은 호스트의 두 경로만 구분하려는 경우 도메인 규칙만으로는 처리할 수 없습니다. 먼저 앱에 적합한 요청 처리 기능이 있는지 확인하세요. DOMAIN에 경로를 넣으면 일부만 매칭될 것이라고 기대하지 마세요.

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

이 예시에서는 api.example.com이 먼저 정확 일치 규칙에 매칭되어 DIRECT로 처리되고, example.com에 속한 나머지 호스트는 뒤에 있는 접미사 규칙을 따릅니다. 이 결과는 배열 순서에서 비롯되며 DOMAIN이 DOMAIN-SUFFIX보다 본래 우선하는 것은 아닙니다. 두 줄의 순서를 바꾸면 앞에 있는 접미사 규칙이 해당 호스트에 먼저 적용됩니다. 그 규칙에 매칭되지 않은 요청만 뒤의 조건을 확인합니다.

DOMAIN-SUFFIX의 도메인 경계

DOMAIN-SUFFIX,example.com,PROXY는 example.com 자체와 www.example.com, api.example.com 같은 하위 도메인을 매칭합니다. 도메인 접미사의 경계를 기준으로 처리하므로 임의의 문자열 끝부분을 비교하는 것으로 이해하면 안 됩니다. notexample.com은 example.com의 하위 도메인이 아닙니다. 접미사 규칙을 작성하기 전에 브라우저에서 복사한 전체 주소가 아니라 실제로 포함해야 할 도메인을 입력했는지 확인하세요.

와일드카드처럼 보이게 하려고 접미사 앞에 별표를 임의로 붙이지 마세요. 규칙 유형에 매칭 방식이 이미 지정되어 있으므로 example.com만 입력하면 됩니다. 접미사가 짧을수록 적용 범위가 대체로 넓어집니다. 공용 접미사나 범위가 매우 넓은 조직 도메인을 지정하면 관련 없는 요청까지 영향을 받을 수 있습니다. 설정을 관리할 때는 넓은 규칙의 목적을 주석으로 남겨 나중에 여전히 필요한지 판단할 수 있게 하세요.

한 웹사이트의 리소스가 모두 기본 도메인에 있는 것은 아닙니다. 이미지, 결제, 인증, 파일 다운로드에 별도 도메인을 사용할 수 있습니다. 주 도메인의 접미사를 추가한 뒤에도 일부 기능이 실패한다면 DOMAIN-SUFFIX 자체가 작동하지 않는다는 뜻은 아닙니다. 요청 기록에서 실패한 호스트를 찾아 해당 서비스에서 실제로 사용하는지 확인한 뒤 범위가 명확한 조건을 추가하세요. 페이지에 보이는 브랜드명만으로 리소스 도메인을 추측하지 마세요.

DOMAIN-KEYWORD의 사용 범위

DOMAIN-KEYWORD,example,PROXY는 도메인에 example이 포함된 경우를 매칭하므로 접미사 조건보다 범위가 넓고, 같은 조직과 관계없는 호스트도 포함할 수 있습니다. 안정적인 이름 규칙이 있고 그 적용 범위를 받아들일 수 있는 경우에 사용하세요. 짧거나 흔한 단어, 브랜드 약칭을 키워드로 쓰면 예상치 못한 결과가 발생하기 쉽습니다. 특히 차단에 사용하면 관련 없는 서비스까지 사용할 수 없게 될 수 있으므로 주의하세요.

기존 설정을 정리할 때는 먼저 키워드 규칙에 현재 매칭되는 호스트를 나열한 다음, 몇 개의 정확 일치 또는 접미사 규칙으로 바꿀 수 있는지 판단하세요. 목적은 단순히 줄 수를 늘리는 것이 아니라 모호한 의도를 검증 가능한 범위로 바꾸는 것입니다. 일시적인 문제 해결에는 이미 확인한 전체 호스트 이름을 우선 사용하세요. 검증을 마친 뒤 범위를 넓힐지 결정하면 우연한 매칭을 완전한 해결책으로 오해하지 않을 수 있습니다.

세 유형은 조건만 지정할 뿐 요청의 최종 성공 여부를 결정하지 않습니다. PROXY에 매칭되어도 사용 가능한 서버가 필요하고, DIRECT에 매칭되어도 현재 네트워크에 의존하며, REJECT에 매칭되면 요청이 거부됩니다. 기록에 규칙 매칭이 표시되면 정책과 연결 경로를 점검하세요. 도메인 표기를 계속 바꿀 필요는 없습니다. 요청 기록 자체가 없다면 요청이 클라이언트에 들어왔는지, 이전 연결을 재사용하고 있는지도 확인하세요.

IP 및 식별 범위

주소 규칙은 명확한 대상 IP나 네트워크 대역을 처리할 때 사용합니다. 일반적인 유형은 IP-CIDR, IP-CIDR6, GEOIP입니다. 이 규칙들은 네트워크 범위를 표현하며 도메인 소속 조직과 같은 의미가 아니고, 앱 동작 전체를 식별하는 기능도 아닙니다. 같은 서비스에서 여러 주소를 쓸 수 있고, 공유 주소 하나에 여러 도메인이 연결될 수도 있습니다. 작성하기 전에 제어 대상이 이름인지 네트워크 대역인지 식별 가능한 요청 유형인지 판단해 서로 다른 기준을 섞지 마세요.

IP-CIDR 및 IP-CIDR6

CIDR은 슬래시 뒤의 프리픽스 길이로 주소 범위를 나타냅니다. IPv4에서 192.168.0.0/16은 해당 사설 주소 대역을 포함하고, 192.0.2.10/32는 IPv4 주소 하나만 나타냅니다. 프리픽스 길이는 포트나 임의의 범위 번호가 아닙니다. 네트워크 범위에 맞는 주소를 입력하세요. 호스트 주소와 이해하지 못하는 프리픽스를 임의로 조합하면 더 넓은 네트워크에 규칙이 적용될 수 있습니다.

[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
IP-CIDR6,2001:db8::10/128,PROXY,no-resolve
FINAL,PROXY

IPv6에는 IP-CIDR6를 사용하며, 주소 하나는 /128로 표현할 수 있습니다. 예시의 2001:db8::10은 문서용 주소이며 실제 서버가 아닙니다. fc00::/7은 IPv6 로컬 주소 범위로, 이런 규칙이 필요한지는 네트워크 구성에 따라 달라집니다. DIRECT를 지정해도 시스템이 대상에 연결할 수 있다고 보장되지는 않습니다. 로컬 라우팅, 기기 방화벽, 서비스 수신 주소, 클라이언트의 트래픽 처리 범위가 모두 결과에 영향을 줍니다.

LAN 프린터나 관리 페이지에 연결할 수 없다면 먼저 실제 대상 주소로 접속하고 있는지 확인한 다음 요청이 클라이언트에 들어오는지 살펴보세요. 일부 주소를 시스템이 직접 처리한다면 Rule에 표시되지 않는 것이 정상일 수 있습니다. 반대로 사설 대역에 DIRECT를 추가해도 모든 기기를 자동으로 찾을 수 있는 것은 아닙니다. 자동 검색에 사용하는 브로드캐스트 또는 멀티캐스트와 특정 주소에 일반 연결을 설정하는 방식은 서로 다르므로 따로 검증하세요.

GEOIP 및 no-resolve

GEOIP,CN,DIRECT는 대상 IP의 지리 분류 결과가 CN인 경우 매칭합니다. 이는 주소 데이터베이스의 분류를 확인할 뿐, 웹페이지 언어, 사용자 위치, 도메인 접미사, 사이트 운영 주체를 판별하는 규칙은 아닙니다. 데이터베이스가 최신이 아닐 수 있고 서비스 주소도 바뀔 수 있으므로 GEOIP를 특정 사이트가 항상 같은 정책을 따르게 하는 보장으로 생각하면 안 됩니다. 예외 처리가 필요한 도메인이 확실하다면 앞에 정확 일치 규칙을 두는 편이 확인하기 쉽습니다.

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

no-resolve가 있는 IP 규칙은 이 조건을 판단하기 위해 주소 정보가 없는 도메인을 추가로 해석하지 않습니다. 요청 대상이 원래 IP이거나 이미 사용할 수 있는 주소 정보가 있다면 매칭될 수 있습니다. 따라서 이 매개변수는 “모든 IP 규칙 건너뛰기”도 아니고 특정 규칙의 우선순위를 높이는 기능도 아닙니다. 추가 해석과 그에 따른 의존성을 감수할지에 따라 사용할지 결정하세요.

도메인 규칙과 GEOIP를 함께 사용하면 앞의 도메인 조건이 매칭된 뒤에는 뒤에 있는 지리 조건이 해당 요청의 정책을 결정하지 않는 경우가 일반적입니다. 특정 도메인을 항상 PROXY로 처리하려면 명시적 예외를 넓은 주소 분류 규칙보다 앞에 두세요. 해석 단계를 줄이겠다는 이유로 모든 규칙에 기계적으로 no-resolve를 추가하면 DNS 결과에 의존하는 분기 의도가 적용되지 않을 수 있습니다. 최적화 전에 먼저 올바르고 재현 가능한 기준을 만드세요.

USER-AGENT의 확인 가능 범위

USER-AGENT는 식별 가능한 요청 헤더 내용으로 매칭하며, 앱 이름을 기준으로 하는 규칙이 아닙니다. 클라이언트가 해당 HTTP 정보를 읽을 수 있는 경우에 사용합니다. 예시 USER-AGENT,ExampleClient*,DIRECT는 패턴으로 요청 헤더를 매칭합니다. 여기에 적힌 이름은 설명용 값이며 실제 기록에 같은 내용이 있을 때만 의미가 있습니다. 휴대폰 홈 화면의 앱 이름을 입력한다고 앱별 트래픽이 자동으로 분기되는 것은 아닙니다.

일반적인 HTTPS 연결에서는 요청 헤더가 암호화되어 있으므로 네트워크 연결 정보만으로 User-Agent를 읽을 수 있다고 볼 수 없습니다. 규칙을 매칭시키기 위해 추가 콘텐츠 처리 기능을 켜거나 인증서를 설치하지 마세요. 일반적인 트래픽 분기에는 관찰 가능한 도메인 및 주소 조건을 우선 사용하세요. 요청 단위 매칭은 확인 가능한 범위, 처리 조건, 개인정보 영향을 충분히 이해한 경우에만 고려하고, 통제 가능한 대상에서 먼저 검증해야 합니다.

USER-AGENT 규칙이 한 번도 매칭되지 않으면 요청 헤더를 확인할 수 있는지, 패턴이 실제 문자열과 일치하는지, 앞선 규칙이 이미 매칭되었는지, 기존 연결을 재사용하고 있는지 순서대로 확인하세요. 매칭되지 않는다고 바로 프로토콜 미지원으로 단정하거나 넓은 키워드로 문제를 덮지 마세요. 규칙이 매칭할 수 있는 항목은 설정 파일에 조건을 얼마나 많이 작성했는지가 아니라 클라이언트가 해당 시점에 얻은 정보에 따라 달라집니다.

정책 및 실행 모드

규칙의 마지막 주요 항목은 일반적으로 정책입니다. PROXY, DIRECT, REJECT는 서로 다른 처리 결과를 나타내지만 같은 정보를 담고 있지는 않습니다. PROXY에는 사용 가능한 프록시 경로가 필요하고, DIRECT는 현재 네트워크로 직접 연결하며, REJECT는 요청을 거부합니다. 이 용어를 이해하기 전에 현재 Global Routing 선택을 확인하세요. Config 모드로 요청을 처리하고 있지 않으면 Rule 내용이 올바르더라도 설정이 적용되지 않을 수 있습니다. 파일을 계속 수정하면 문제 해결만 더 복잡해집니다.

PROXY, DIRECT 및 REJECT

PROXY는 매칭된 트래픽을 프록시 경로로 처리한다는 뜻입니다. 일반적인 기본 설정에서는 Home에서 현재 선택한 서버를 사용하므로 먼저 해당 서버에 연결할 수 있는지 확인하세요. Rule의 PROXY에는 서버 주소, 비밀번호, 프로토콜 매개변수가 포함되지 않습니다. 모든 줄에 입력해도 잘못된 포트, 인증 정보, 서버 상태가 자동으로 수정되지는 않습니다. 연결에 실패하면 “규칙이 매칭됨”과 “프록시 연결 성공”을 별개의 사실로 기록하세요.

DIRECT는 해당 프록시 경로를 사용하지 않고 대상에 직접 접속한다는 뜻입니다. 모든 시스템 네트워크 동작을 우회한다는 의미는 아닙니다. 현재 네트워크의 DNS, 기본 라우트, 다른 VPN 설정, 상위 네트워크 제한이 여전히 연결에 영향을 줍니다. LAN 리소스에 DIRECT를 사용할 때는 기기가 해당 대역에 실제로 접속 가능한 네트워크에 있는지도 확인하세요. 셀룰러 네트워크로 전환하면 기존에 접속할 수 있던 사설 주소도 이 규칙만으로는 계속 사용할 수 없는 경우가 많습니다.

REJECT는 매칭된 요청을 거부하며 범위가 분명하고 차단해도 되는 대상에 사용할 수 있습니다. 문제를 해결하는 정책은 아니며 도메인 이름만 보고 유해한 콘텐츠라고 판단할 수도 없습니다. 규칙 범위가 넓으면 페이지의 본문은 표시되어도 로그인, 인증 코드, 파일 전송이 실패할 수 있습니다. 차단 규칙을 추가한 뒤에는 홈페이지가 열리는지만 보지 말고 전체 작업 과정을 확인하세요. 예외를 계속 추가하기보다 복구 방법을 마련해 두는 편이 중요합니다.

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

Global Routing의 세 가지 모드

Global Routing의 Config 모드는 현재 설정에 따라 트래픽을 분기합니다. Proxy 모드는 해당 모드의 적용 범위에 들어오는 요청에 프록시 경로를 사용합니다. Direct 모드는 직접 연결 경로를 사용합니다. 세 가지는 실행 모드이지 Rule에 작성하는 세 가지 규칙이 아니며, PROXY, DIRECT, REJECT와 일대일로 대응하지 않습니다. 특히 Direct 모드가 현재 파일 맨 앞에 규칙 하나를 자동으로 추가한다는 뜻은 아닙니다.

표의 모드가 시스템 권한을 우회하거나 제외 항목을 처리하고 다른 네트워크 경계를 넘을 수 있다는 뜻은 아닙니다. 요청이 클라이언트에 들어오지 않으면 모드를 바꿔도 경로가 달라지지 않을 수 있습니다. 화면에 Scene 같은 항목이 있다면 해당 항목의 설정에 따라 실제 상태를 확인하세요. 이름만 보고 현재 어떤 규칙이 적용되는지 추측하지 마세요. 문제 해결 시에는 명확한 Config, Proxy 또는 Direct 모드로 돌아가 기록과 대조하세요.

Config에서 실패하고 Proxy에서 성공하더라도 분기 또는 설정 관련 부분을 확인해야 한다는 뜻일 뿐, 도메인 규칙이 잘못되었다고 바로 단정할 수는 없습니다. DNS, Host, 거부 규칙, 기본 정책도 차이를 만들 수 있습니다. Proxy에서도 실패하면 선택한 서버와 대상 경로를 먼저 확인하세요. 모드를 바꿀 때마다 새 연결을 만들고 같은 대상을 테스트해야 비교 결과를 해석할 수 있습니다.

사용자 지정 이름과 실제 대상

일부 설정은 정책 그룹이나 특정 서버 이름을 규칙 대상으로 사용합니다. 이 이름은 현재 설정에서 확인 가능한 객체와 일치해야 하며 임의의 레이블을 뜻하지 않습니다. 다른 사람의 파일에 있는 그룹 이름만 남기고 해당 정의를 포함하지 않으면 가져오기 오류나 실행 문제가 발생할 수 있습니다. 기본 문제 해결에서는 복사본에서 이해하고 있는 내장 정책을 사용해 범위를 좁힌 뒤, 사용자 지정 정책이 실제로 지원되는지 확인하면서 단계적으로 복구하세요. 복잡한 구성을 한 번에 전부 옮기지 마세요.

설정을 확인할 때 PROXY만 검색하지 마세요. 규칙이 이름이 비슷한 정책 그룹을 가리키고 그룹에서 최종 선택한 서버가 Home의 현재 항목과 다를 수 있습니다. 규칙 대상, 그룹 선택, 최종 연결 서버를 모두 확인하세요. “프록시”라는 단어만 보고 경로가 같다고 판단하면 안 됩니다. 문제를 공유할 때는 사설 서버 식별자를 중립적인 이름으로 바꿔도 되지만 객체 간 관계는 유지해야 문제 해결 단서가 사라지지 않습니다.

모드 테스트를 마치면 원래 사용하려던 모드로 돌아가 현재 설정이 계속 선택되어 있는지 확인하세요. Proxy로 임시 전환해 웹페이지가 열렸다고 해서 Config의 문제가 해결된 것은 아닙니다. 모드를 다시 전환하지 않으면 직접 연결 예외도 원래 의도대로 작동하지 않을 수 있습니다. 처음 서버를 선택하고 연결을 켜는 순서는 시작 가이드를 참고하세요. 이 페이지에서는 모드와 규칙의 관계를 설명합니다.

매칭 순서와 기본 규칙

Rule을 읽는 핵심 원칙은 위에서 아래로 확인하는 것입니다. 모든 조건에 점수를 매긴 뒤 가장 정확한 결과를 고르는 것이 아니라, 먼저 유효하게 매칭된 규칙이 정책을 결정합니다. 규칙 유형, 조건 길이, 정책 이름 자체가 우선순위를 높이지 않습니다. 요청이 특정 경로를 따른 이유를 확인하려면 먼저 매칭될 수 있는 첫 번째 규칙을 찾고, 그 결과로 뒤쪽 항목이 결정에 참여하지 않았는지 확인하세요. 파일에서 대상 도메인이 마지막으로 나온 곳만 검색하지 마세요.

예외를 넓은 조건보다 먼저

example.com 및 하위 도메인은 기본적으로 PROXY로 처리하되 api.example.com은 DIRECT로 보내려면 정확한 예외를 접미사 조건보다 앞에 둡니다. 이는 관리하기 쉬운 구성 방식이지 필수 구문 규칙은 아닙니다. 반대로 모든 하위 도메인에 같은 정책을 적용하려는 경우 앞선 규칙에 가려지는 정확 일치 항목을 남겨둘 필요가 없습니다. 실제 효과가 없는 규칙을 삭제하면 관리자가 해당 규칙이 여전히 요청을 제어한다고 오해하지 않습니다.

[Rule]
# 정확한 예외를 먼저 매칭
DOMAIN,api.example.com,DIRECT

# 같은 도메인의 나머지 요청을 이어서 처리
DOMAIN-SUFFIX,example.com,PROXY

# 마지막으로 그 밖의 요청을 처리
FINAL,DIRECT

특히 키워드 규칙의 위치에 주의하세요. 위쪽에 DOMAIN-KEYWORD,example,REJECT를 넣으면 api.example.com이 먼저 거부되어 뒤의 DIRECT가 결과를 바꾸지 못합니다. 예상치 못한 결과가 발생하면 대상 주변 몇 줄만 보지 말고 해당 규칙보다 앞에 있는 넓은 조건을 확인하세요. 규칙이 많을수록 각 그룹의 범위와 예외를 주석으로 설명해야 합니다. 규칙 유형 이름이 설명을 대신하지는 않습니다.

주소 규칙도 같은 방식으로 확인합니다. 도메인의 명확한 조건이 매칭되면 뒤에 있는 GEOIP는 이번 요청의 정책을 결정하지 않습니다. 앞선 IP 조건에 주소 정보가 필요하다면 해석 동작도 매칭 여부에 영향을 줍니다. 순서를 정할 때 논리적 적용 범위뿐 아니라 필요한 정보를 사용할 수 있는지도 고려하세요. 먼저 원하는 동작을 정의한 뒤 해석 비용을 따져야 합니다. 조회를 한 번 줄이려고 중요한 예외를 작동하지 않는 위치로 옮기지 마세요.

FINAL은 나머지 요청을 처리하는 규칙

FINAL,PROXY는 앞선 규칙에 매칭되지 않은 요청을 PROXY로 처리한다는 뜻입니다. FINAL에는 도메인이나 주소 조건을 추가하지 않으며 뒤의 텍스트가 정책입니다. 관련 규칙 목록의 끝에 배치하세요. 너무 앞에 두면 기본 규칙에 도달한 요청에 뒤쪽 항목은 의미가 없어집니다. 파일에 FINAL이 여러 개 있다면 단계별 대체 규칙처럼 생각하지 말고, 의도가 분명한 마지막 기본 규칙 하나로 정리하세요.

FINAL에 DIRECT와 PROXY 중 무엇을 쓸지는 설정 목표에 따라 달라지며, 어느 한쪽이 본래 올바른 것은 아닙니다. 많은 직접 연결 예외와 FINAL,PROXY를 조합하는 방식과 소수의 프록시 도메인 및 FINAL,DIRECT를 조합하는 방식은 기본 적용 범위가 서로 다릅니다. 설정 파일 두 개를 비교할 때는 앞의 예외 목록과 마지막 정책을 함께 살펴보세요. FINAL 한 줄만 비교하면 대부분의 요청을 실제로 결정하는 조건을 놓쳐 작성자의 의도를 잘못 이해할 수 있습니다.

기본 규칙은 연결 실패 시 자동으로 경로를 전환하지 않습니다. 요청이 PROXY에 매칭된 뒤 연결에 실패해도 클라이언트가 뒤의 DIRECT나 다른 FINAL을 계속 시도하지 않습니다. 후속 규칙은 예비 서버 목록이 아닙니다. 서버 수준에서 선택하고 복구하는 기능이 필요하다면 해당 선택 방식을 확인하세요. 같은 도메인 뒤에 다른 정책을 한 줄 더 추가하는 방식으로 해결하려 하지 마세요. 분기 판단과 연결 실패 후 처리를 구분하는 것이 규칙 동작을 이해하는 핵심입니다.

충돌, 중복 및 규칙 통합

조건과 정책이 완전히 같은 규칙을 반복하면 대개 읽기만 불편해집니다. 조건은 같지만 정책이 다른 경우에는 어느 규칙이 앞에 있는지, 왜 유지해야 하는지 확인하세요. 예외와 넓은 조건의 관계가 바뀌므로 Rule 전체를 단순히 알파벳순으로 정렬하면 안 됩니다. 정리하기 전에 명확한 차단, 단일 도메인 예외, 도메인 목록, 주소 대역, 기본 규칙처럼 용도별로 묶고 실제로 같은 중복 항목만 정리하세요.

설정 두 개를 합칠 때 두 번째 Rule 섹션과 FINAL을 첫 번째 설정 뒤에 그대로 붙이지 마세요. 먼저 각각의 의도를 정리하고, 서로 덮어쓰는 도메인, 다른 정책 이름, 중복 기본 규칙이 있는지 확인한 뒤 설명 가능한 목록으로 구성하세요. 원격 규칙이 바뀌면 새 조건이 적용 범위를 넓혔는지도 다시 점검해야 합니다. 이전에 작동했다고 업데이트 뒤에도 매칭 관계가 같다는 보장은 없습니다.

순서를 검증할 때는 복사본에 충돌하는 조건 그룹 하나만 남기고 같은 대상으로 새 요청을 반복해 기록의 매칭 유형과 정책을 확인하세요. 위쪽의 넓은 규칙을 삭제한 뒤 결과가 달라졌다면 규칙이 서로 덮어쓴 것이 원인일 가능성이 큽니다. 결과가 그대로라면 잘못된 파일을 편집했거나 Config가 아닌 모드를 사용 중인지 확인하세요. 규칙을 계속 맨 위로 옮기는 것보다 규칙 집합을 줄여 근거를 확인하는 편이 안정적인 결론에 도움이 됩니다.

Host 및 URL Rewrite

Host와 URL Rewrite는 모두 접속 결과를 바꿀 수 있지만 서로 다른 계층에서 작동합니다. Host는 호스트 이름에 주소를 지정하고 URL Rewrite는 조건에 맞는 요청 URL을 변경합니다. 둘 다 프록시 서버 선택을 대신하지 않으며 구독 내용을 입력하는 용도도 아닙니다. 문제 해결 시 Rule과 분리해서 확인하세요. 요청이 DIRECT에 올바르게 매칭되어도 Host가 오래된 주소를 가리키면 실패할 수 있고, 요청이 먼저 변경되어 이후 기록에 다른 도메인이 표시될 수도 있습니다.

Host의 정적 매핑

Host 섹션의 일반적인 정적 매핑은 example.com = 192.0.2.10처럼 작성합니다. 왼쪽은 호스트 이름, 오른쪽은 주소이며 프로토콜이나 웹페이지 경로를 입력하지 않습니다. 여기의 192.0.2.10은 문서용 주소이므로 실제 사이트에 사용할 수 없습니다. 실제 설정에는 관리 권한이 있거나 확인된 주소를 입력하고, 고정 매핑이 필요한 호스트에만 적용하세요. 웹사이트의 모든 리소스 도메인이 같은 주소라고 추측하지 마세요.

[Host]
# 문서 예시 주소입니다. 형식 설명에만 사용하세요
example.com = 192.0.2.10
api.example.com = 192.0.2.20

정적 매핑은 해석 결과를 바꿀 뿐 TLS에서 사용하는 사이트 식별 정보까지 자동으로 바꾸지는 않습니다. HTTPS에 접속할 때 대상 서버는 해당 도메인을 올바르게 처리하고 유효한 인증서를 제공해야 합니다. 도메인을 응답 가능한 주소에 연결했다고 페이지가 정상적으로 열리는 것은 아닙니다. 다른 서비스의 주소라면 인증서 오류, 기본 페이지 표시, 연결 거부가 발생할 수 있습니다. 잘못된 매핑을 감추려고 인증서 검사를 무시하지 말고 올바른 대상으로 복원하세요.

Host는 포트 설정을 대신하지 않습니다. 한 서버에서 포트마다 서로 다른 서비스가 실행될 수 있으며 정적 호스트 매핑은 이름과 주소의 관계만 설명합니다. 앱이 잘못된 포트에 연결하는 문제라면 해당 연결 설정이나 대상 URL에서 수정해야 합니다. 문제를 확인할 때 원래 호스트 이름, 해석된 주소, 실제 포트를 각각 기록하고 대조하세요. 도메인이 해석되는지만 확인해서는 최종 연결이 올바른 서비스에 도달하는지 알 수 없습니다.

URL Rewrite의 조건과 결과

URL Rewrite 규칙은 일반적으로 정규식으로 매칭할 URL을 지정한 다음 대체 대상과 동작을 설정합니다. 아래 예시는 지정한 설명용 도메인의 HTTP 주소를 HTTPS로 리디렉션하고 매칭된 경로를 유지합니다. 형식 설명을 위한 예시이므로 복사하기 전에 매칭 범위와 대체 결과를 이해해야 합니다. 해당 요청 내용을 확인할 수 없는 환경에서는 규칙을 작성해도 모든 연결이 처리되는 것은 아닙니다.

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

정규식에서 ^는 시작 위치를 고정하고, \.는 문자 그대로의 점을 나타내며, (.*)는 뒤에 오는 내용을 캡처합니다. 대체 문자열의 $1은 첫 번째 캡처 그룹을 참조합니다. 점을 이스케이프하지 않으면 매칭 범위가 넓어질 수 있고 호스트 경계가 없는 표현식은 의도하지 않은 대상을 포함할 수 있습니다. 규칙을 쉽게 적용하려고 경계를 삭제하지 마세요. 구체적인 요청마다 어떤 결과로 바뀌는지 확인해야 합니다.

리디렉션으로 클라이언트가 새 주소에 다시 접속할 수 있으므로 무한 반복이 발생하지 않는지 확인하세요. 예를 들어 한 규칙은 주소 A를 B로 바꾸고 다른 규칙은 B를 A로 바꾸면 접속이 복구되는 대신 요청이 반복됩니다. 쿼리 매개변수가 포함된 경우 인증이나 페이지 이동에 필요한 값이 캡처 범위에 보존되는지도 확인하세요. 간단하고 통제 가능한 HTTP 대상을 사용해 검증하고 로그인이나 결제 흐름에는 바로 적용하지 마세요.

적용 범위와 되돌리는 방법

일반 HTTPS에서는 경로와 요청 헤더가 암호화되므로 클라이언트가 대상 도메인을 알고 있어도 전체 URL을 읽을 수 있는 것은 아닙니다. 이 장에서는 Rewrite를 위해 인증서나 콘텐츠 복호화 설정을 추가하라고 안내하지 않습니다. 특정 호스트에 PROXY와 DIRECT 중 어느 정책을 적용할지가 목적이라면 Rule을 사용하는 편이 간단합니다. 확인 가능한 요청 URL을 변경해야 하는 경우에만 Rewrite를 고려하고 더 강력한 도메인 분기 규칙처럼 무분별하게 함께 사용하지 마세요.

문제를 확인할 때 Host 매핑과 Rewrite 항목을 각각 비활성화하세요. 두 섹션을 한꺼번에 삭제한 뒤 한쪽이 잘못되었다고 단정하지 마세요. 먼저 원래 이름 해석 상태로 복원해 대상 주소를 검증하고, Rewrite 없이 요청을 테스트한 다음 변경 사항을 하나씩 복구하면서 처음 차이가 생긴 단계를 기록하세요. 이 방법으로 오래된 주소, 정규식 범위, 반복 리디렉션, 대상 서비스 동작을 구분할 수 있으며 정상적인 리디렉션을 프록시 연결 오류로 오해하지 않을 수 있습니다.

오래 유지하는 매핑과 Rewrite 규칙은 정기적으로 다시 확인해야 합니다. 서비스 이전 후 고정 IP가 더 이상 유효하지 않을 수 있고, 웹사이트 경로 변경 뒤에는 기존 정규식이 매칭되지 않거나 새로운 경로까지 포함할 수 있습니다. 주석에 용도와 검증 방법을 적되 실제 인증 정보는 넣지 마세요. 용도를 설명할 수 없는 항목은 오래된 설정에서 가져왔다는 이유만으로 계속 유지하지 말고 복사본에서 비활성화한 뒤 결과를 확인하세요. 관리의 목표는 동작을 이해하고 복구할 수 있도록 하는 것입니다.

설정 검증 및 관리

설정 검증의 목적은 규칙을 계속 늘리는 것이 아니라 매번 변경하는 이유를 관찰할 수 있게 하는 것입니다. 시작하기 전에 현재 네트워크, Global Routing 모드, 선택한 서버, 설정 파일을 기록한 다음 안정적이고 명확한 테스트 대상을 선택하세요. 이런 조건이 동시에 바뀌면 결과가 어떤 수정에서 비롯되었는지 판단하기 어렵습니다. 정상 작동하는 기본 설정 복사본을 보관하고 새 규칙은 테스트용 복사본에서 확인한 뒤 일상 연결에 사용하세요.

설명 가능한 최소 설정 만들기

최소 설정에는 테스트할 조건과 명확한 FINAL만 남기고 모든 섹션을 한꺼번에 포함하지 않아도 됩니다. 도메인 예외를 테스트할 때는 Host와 Rewrite를 넣지 말고, DNS를 확인할 때는 주소 조건을 많이 섞지 마세요. 장기적으로 최소 규칙만 사용하라는 뜻이 아니라 같은 현상의 원인이 될 수 있는 요소를 줄이기 위한 방법입니다. 각 줄의 목적을 한 문장으로 설명할 수 있어야 유지, 이동, 삭제 여부를 판단하기 쉽습니다.

[General]
dns-server = system

[Rule]
# 지정한 호스트가 프록시 경로를 사용하는지 확인
DOMAIN,example.com,PROXY
FINAL,DIRECT

예시 설정은 지정한 조건에서의 동작만 보여주며 모든 접속 요구에 적합하다는 뜻은 아닙니다. 사용 전에 서버가 정상적으로 연결되는지 확인하고 Config 모드에서 테스트하세요. 설명용 도메인에 접속할 필요가 없다면 본인이 접근 권한을 가진 문제 대상의 호스트 이름으로 바꾸되 호스트 이름만 입력하세요. 테스트가 성공하면 다른 규칙을 단계별로 복구하고 매번 다시 검증하세요. 이렇게 하면 문제를 처음 유발한 변경을 바로 찾을 수 있습니다.

LAN 문제에서는 자동 검색 목록만 보는 것보다 확인된 주소로 서비스 포트를 테스트하는 편이 유용합니다. 웹페이지 문제라면 본문, 로그인, 정적 리소스를 구분해서 확인하세요. 페이지 하나가 열려도 사이트 전체가 같은 정책으로 처리된다는 뜻은 아닙니다. 기록에서 실제로 실패한 요청을 골라 호스트 이름, 주소, 시간을 확인하고 동시에 발생한 모든 백그라운드 연결을 오류의 일부로 간주하지 마세요.

근거에 따라 실패 단계 구분

첫 번째 단계는 요청이 클라이언트에 들어왔는지 확인하는 것입니다. 기록이 전혀 없다면 먼저 연결 스위치, 시스템 권한, 트래픽 처리 범위, 기존 연결 재사용을 확인하세요. 이때 규칙부터 수정하지 마세요. 처음 권한을 요청하는 문제가 있다면 VPN 구성 추가 안내를 참고하세요. 요청이 보이면 두 번째 단계로 넘어가 도메인 또는 주소 정보가 충분한지, 현재 파일의 순서에 따라 예상한 규칙이 실제로 매칭되었는지 확인합니다.

세 번째 단계에서는 정책 이후의 연결 경로를 확인합니다. PROXY에 매칭되었지만 실패했다면 선택한 서버, 프로토콜 매개변수, 대상 연결 상태를 점검하세요. DIRECT에서 실패했다면 현재 네트워크와 대상 서비스를 확인하고, REJECT에 매칭되었다면 의도한 차단인지 먼저 판단하세요. Connectivity Test로 서버 연결 상태를 확인할 수 있지만 테스트 대상과 실제 서비스 대상은 다르므로 모든 웹페이지에 접속할 수 있다는 증거는 아닙니다. 도구 결과와 실제 요청을 따로 기록하세요.

네 번째 단계에서는 캐시와 상태 차이를 제외합니다. 수정한 뒤 저장하고 해당 파일이 계속 선택되어 있는지 확인하세요. 이전 요청을 종료하고 필요하면 다시 연결한 다음 같은 대상에 접속합니다. 비교할 때 네트워크를 그대로 유지하고 Wi-Fi에서 셀룰러로 전환하는 동시에 서버까지 바꾸지 마세요. 한 네트워크에서만 문제가 발생하면 해당 네트워크의 DNS와 라우팅 차이를 먼저 확인하세요. 모든 네트워크에서 문제가 생기면 설정의 공통 부분이나 대상 서비스 자체를 점검합니다.

백업, 업데이트 및 문제 기록

관리 기록에는 “네트워크 수정” 같은 결론만 남기지 말고 변경 목적, 관련 규칙, 검증 방법을 구체적으로 적으세요. 예를 들어 “지정한 호스트의 DOMAIN 예외를 접미사 조건 앞에 옮긴 뒤 새 연결을 만들어 DIRECT 매칭을 확인함”이라고 기록하면 단순히 “규칙 이동으로 해결”이라고 쓰는 것보다 재현하기 쉽습니다. 공유할 기록에서는 사설 구독 매개변수와 인증 정보를 지우고 문제를 설명하는 데 필요한 구조와 비식별 처리한 대상만 남기세요.

원격 설정을 업데이트하기 전에 로컬 변경 사항을 저장하세요. 업데이트 후에는 파일 길이만 보지 말고 General, Rule, Host, Rewrite에 실질적인 변화가 있는지 비교합니다. 서버 구독 업데이트는 항목이 여전히 있는지, 현재 선택이 바뀌었는지 별도로 확인하세요. 두 종류의 업데이트를 혼동하지 마세요. 직접 관리하는 설정 파일을 사용한다면 자동 업데이트 내용과 수동 예외를 어떻게 관리할지 정해 다음 새로 고침에서 방금 수정한 내용이 덮어써지지 않도록 하세요.

복구해야 한다면 정상 작동이 확인된 설정 복사본으로 전환한 뒤 모드와 서버를 다시 확인하세요. 마지막 줄 하나만 되돌렸다고 모든 상태가 복원되었다고 생각하지 마세요. 복원 후 같은 대상으로 다시 검증하고 계속 시험할지 결정하세요. 원인을 찾기 어렵다면 자주 묻는 질문의 분류를 참고하고 최소한의 재현 절차를 함께 확인하세요. 설치 및 앱 획득 문제는 다운로드 페이지의 설치 허용 안내에서 다룹니다. 이 페이지의 규칙 수정은 시스템 설치 및 권한 설정 절차를 대신하지 않습니다.