Shadowrocket 사용자 규칙 우선순위 설정: 위에서 아래로 매칭하고 FINAL로 기본 처리하기

1. 규칙 우선순위: 먼저 일치하는 규칙이 적용됩니다

구성에 따라 라우팅할 때 [Rule] 섹션은 위에서 아래로 검사합니다. 규칙이 일치하면 지정된 정책을 적용하고, 뒤에 있는 ‘더 구체적인 규칙’을 계속 찾지 않습니다. 따라서 규칙 유형 자체에 행 순서를 대신할 공통 우선순위가 있는 것은 아닙니다. DOMAIN을 DOMAIN-SUFFIX 뒤에 작성해도 자동으로 우선순위가 높아지지 않습니다.

예를 들어 api.example.com은 직접 연결하고 example.com의 다른 하위 도메인은 프록시로 보내려면, 해당 도메인에 대한 예외 규칙을 먼저 작성해야 합니다. 아래 도메인은 문법 설명을 위한 예시일 뿐, 서비스 주소나 이용 가능성을 보장하지 않습니다.

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

• api.example.com 요청: 첫 번째 규칙과 일치하므로 DIRECT가 적용됩니다.
• www.example.com 요청: 첫 번째 규칙과 일치하지 않고 두 번째 규칙과 일치하므로 PROXY가 적용됩니다.
• 앞선 규칙에 해당하지 않는 요청: FINAL,DIRECT가 처리합니다.

앞의 두 규칙 순서를 바꾸면 api.example.com도 더 넓은 도메인 접미사 조건에 해당해 먼저 PROXY 규칙에 걸립니다. ‘직접 연결로 설정했는데도 프록시를 거치는’ 문제를 확인할 때는 끝에 같은 규칙을 더 추가하기보다, 대상 규칙 앞에 이미 해당 요청을 처리하는 규칙이 있는지 먼저 확인하세요.

2. Global Routing 확인 후 Config 편집하기

구성 파일에 규칙이 있다고 해서 현재 연결이 반드시 해당 규칙에 따라 라우팅되는 것은 아닙니다. Home → Global Routing에서 현재 모드를 확인한 다음, Config에서 사용 중인 파일을 확인하세요. 아래에서는 이번 검증에 필요한 세 가지 모드만 비교합니다. Scene은 시나리오별 설정에 사용됩니다. 이 글의 규칙을 확인할 때는 모드 전환으로 생기는 변수를 줄이도록 먼저 Config를 선택하세요.

1. 구성 백업

   Config에서 먼저 현재 파일을 복사하거나 내보내 백업하세요. 추가한 몇 줄만 저장하지 말고 복구할 수 있도록 기존 규칙을 보존하세요.

2. 편집 화면 열기

   Config에서 대상 구성의 편집 화면을 열고 [Rule] 섹션을 찾으세요. Home의 서버 연결 매개변수가 아니라 구성 본문을 수정하는지 확인하세요.

3. 규칙 정렬

   단일 도메인 예외를 해당하는 광범위 규칙보다 앞에 배치하세요. 그런 다음 IP 범위와 GEOIP 항목을 확인하고 마지막에 FINAL을 둡니다. 저장 후 해당 파일이 선택되어 있는지 확인하세요.

4. 모드 확인

   Home → Global Routing → Config로 돌아가 기존 서버가 올바르게 선택되어 있는지 확인한 다음 연결을 시작하세요. 시스템 VPN 구성에 대한 승인이 필요하면 시스템 안내를 따르세요.

5. 새 요청 보내기

   대상 페이지를 닫고 다시 방문하세요. 필요한 경우 새 연결을 설정해 이전 연결로 변경된 규칙을 판단하지 않도록 합니다. 대상 도메인, 시간, 매칭 결과를 기록한 뒤 다음 항목을 수정하세요.

3. DOMAIN-SUFFIX, IP-CIDR, GEOIP 배치 방법

규칙이 어떤 대상을 검사하는지와 몇 번째 줄에 배치되는지는 별개의 문제입니다. 도메인 규칙은 호스트 이름을, IP 규칙은 목적지 주소를 확인하고, GEOIP는 IP 데이터베이스를 기준으로 분류합니다. 도메인 요청은 여러 주소로 해석될 수 있으며, 같은 도메인도 네트워크 환경에 따라 다른 주소로 해석될 수 있습니다. 한 번의 IP 매칭 결과를 해당 도메인의 고정된 속성으로 간주하지 마세요.

DOMAIN-SUFFIX 뒤에는 example.com을 입력해야 합니다. https://가 포함된 전체 URL이나 example.com/path를 입력하는 것이 아닙니다. 경로는 URL의 다른 구성 요소이므로 도메인 필드에 붙여 넣어도 ‘이 페이지에만 프록시를 적용’할 수 없습니다. 또한 웹사이트에서 흔히 사용하는 HTTPS 포트 443을 쓴다고 해서 규칙에 포트 조건이 자동으로 추가되는 것도 아닙니다.

no-resolve는 해당 IP 규칙을 매칭하기 위해 도메인 조회를 추가로 실행하지 말라는 뜻입니다. 구성 전체의 DNS를 끄거나 해당 대역이 절대 매칭되지 않는다는 뜻은 아닙니다. 요청에 판단할 수 있는 목적지 IP가 이미 있으면 주소 범위로 계속 확인할 수 있습니다. 도메인만 알고 해당 규칙을 위해 조회를 원하지 않는 경우, 조회를 건너뛰면 요청이 다음 규칙으로 넘어갈 수 있다는 점을 이해해야 합니다.

• 서비스에 필요한 구체적인 예외를 먼저 작성한 뒤 해당 도메인 접미사 규칙을 배치하세요. 광범위한 규칙이 예외를 먼저 처리하는 상황을 방지할 수 있습니다.
• 목적지 주소에 따라 구분해야 할 때만 IP 대역을 추가하세요. /32는 단일 IPv4 주소이고 /24는 256개 주소를 포함합니다.
• 범위가 넓은 GEOIP 규칙은 보통 구체적인 예외 뒤에 배치합니다. 이는 관리하기 편한 정렬 방식이지, 클라이언트가 강제하는 규칙 유형별 우선순위는 아닙니다.
• 연결에 도메인이 없고 IP 주소만 사용된다면 DOMAIN-SUFFIX만으로는 매칭할 수 없습니다.

4. PROXY, DIRECT, REJECT, FINAL 작성 방법

규칙 끝에 지정한 정책은 매칭 후 처리 방식을 결정합니다. PROXY는 프록시 경로로 보내고, DIRECT는 목적지에 직접 연결하며, REJECT는 요청을 거부합니다. 이러한 처리 방식은 서버 프로토콜과 별개의 설정입니다. 기존 서버를 Shadowsocks에서 Trojan으로 바꿔도 규칙이 위에서 아래로 매칭되는 기본 순서는 달라지지 않습니다.

아래는 설명을 위한 [Rule] 섹션일 뿐, 기존 설정 전체를 대체할 수 있는 완전한 구성 파일이 아닙니다. 사용 가능한 서버가 이미 있다고 가정한 예시이며, 예시 도메인은 서비스를 제공하지 않습니다. 실제 구성에 적용하기 전에 기존 파일의 정책 이름, 다른 규칙, 필요한 네트워크 범위를 확인하세요.

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

• api.example.com은 example.com에 속하지만 첫 번째 예외 규칙과 먼저 일치하므로 직접 연결됩니다.
• blocked.example.com은 접미사 규칙보다 앞에서 REJECT와 일치합니다. 접속에 실패하는 것은 이 정책의 예상된 결과입니다.
• 192.168.0.0/16은 이 사설 주소 범위만 포함하며 모든 로컬 네트워크를 의미하지 않습니다. 다른 범위는 실제 필요에 따라 따로 확인해야 합니다.
• GEOIP,CN,DIRECT는 목적지 IP의 데이터베이스 분류를 사용합니다. 모든 중국어 웹사이트를 포함한다고 보장하지 않으며, 특정 도메인이 매번 같은 분류를 받는 것도 아닙니다.
• FINAL,PROXY는 앞선 규칙과 일치하지 않은 요청만 처리합니다. 이미 DIRECT와 일치한 요청을 프록시로 바꾸지는 않습니다.

FINAL을 규칙 중간에 넣으면 그 뒤에 오는 분류되지 않은 요청을 먼저 처리해 나머지 규칙이 의도대로 작동하지 않습니다. 관리하기 쉽도록 마지막에 명확한 기본 규칙 하나만 두고, 기존 구성에 FINAL이 중복되어 있지는 않은지 확인하세요.

5. 한 번에 한 가지씩 테스트해 규칙이 적용되지 않는 원인 찾기

‘현재 파일 → 현재 모드 → 요청 대상 → 실제 매칭 → 연결 결과’ 순서로 확인하세요. 웹페이지가 열리는 것은 요청이 한 번 성공했다는 뜻일 뿐, 어떤 경로를 거쳤는지 단독으로 입증하지는 않습니다. 페이지가 열리지 않는 이유도 REJECT, 목적지 서비스 장애, 프록시 연결 문제 등 다양할 수 있습니다. 규칙 매칭 결과와 연결 성공 여부를 구분해 기록하세요.

1. 기준 상태 기록: 같은 네트워크, 기존 서버, 동일한 대상을 유지하고 변경 전 상태를 기록하세요. 서버와 규칙을 동시에 바꾸지 마세요.
2. 한 줄만 수정: 예를 들어 DOMAIN과 DOMAIN-SUFFIX의 순서만 바꾸고 저장한 뒤, 해당 구성을 사용 중인지 확인하고 요청을 다시 보내세요.
3. 요청 정보 확인: 앱의 연결 기록이나 로그에서 이번 요청의 호스트, 목적지 IP, 표시된 정책 정보를 찾으세요. IP만 보인다면 도메인 정보가 있는지 먼저 확인합니다.
4. 페이지의 모든 리소스 확인: 페이지 본문, 이미지, 로그인 API가 서로 다른 도메인을 사용할 수 있습니다. 기본 도메인에 규칙 하나를 추가하는 것만으로 페이지가 의존하는 리소스가 모두 포함되지는 않을 수 있습니다.
5. 변경 사항 되돌려 비교: 방금 수정한 내용을 복원하고 다시 방문하세요. 결과가 변경 사항에 따라 반복적으로 달라지지 않는다면 캐시, 기존 연결, 대상 서비스 상태를 추가로 확인합니다.

구독 업데이트와 구성 편집도 구분해야 합니다. Home에서 기존 서버 구독을 업데이트하면 주로 서버 목록이 갱신됩니다. Config의 원격 구성 업데이트는 구성 본문을 교체할 수 있습니다. 두 작업을 모두 ‘규칙 새로고침’으로 간주해서는 안 됩니다. 원격 구성을 수정하기 전에 로컬 사본을 저장하고, 업데이트 후 예외 규칙과 FINAL이 유지되어 있는지 다시 확인하세요.

6. 규칙 순서와 FINAL 관련 자주 묻는 질문