Shadowrocket 규칙 설정 방법: 위에서부터 매칭, FINAL 기본 처리와 PROXY / DIRECT / REJECT

1. Global Routing을 확인하고 규칙 적용 여부 판단하기

Shadowrocket의 서버 선택, Config 파일, 전역 라우팅은 서로 다른 설정입니다. Home에서 서버를 선택해도 요청이 반드시 프록시를 통과하는 것은 아닙니다. Config에 규칙을 저장해 두었더라도 현재 라우팅 모드에서 해당 규칙을 사용한다고 볼 수 없습니다. 문제를 확인할 때는 먼저 Home → Global Routing으로 이동해 현재 선택을 확인하세요.

이 글의 규칙에 따라 트래픽을 분기하려면 Config(구성에 따른 라우팅)를 선택하세요. Proxy(프록시)와 Direct(직접 연결)는 비교 확인용으로 적합하며, 이 모드에서 연결된 결과만으로 특정 Config 규칙의 매칭 여부를 판단해서는 안 됩니다. Scene은 상황별 라우팅에 사용됩니다. Scene을 사용하는 경우 현재 Scene의 설정도 확인해야 하며, 이 글의 Config 테스트 조건과 같다고 단정할 수 없습니다.

2. 규칙은 위에서부터 적용되며, 구체성에 따라 자동 정렬되지 않습니다

규칙 목록은 순서에 따라 판단하는 절차이지, 정밀도를 자동으로 비교하는 집합이 아닙니다. 요청이 앞쪽 규칙과 일치하면 뒤에 있는 일반 규칙으로 다시 정책을 선택하지 않습니다. 따라서 전체 호스트명이 접미사보다 구체적이라는 점은 규칙을 배치할 때 고려할 사항일 뿐, 앱이 우선순위를 자동으로 조정해 준다는 뜻은 아닙니다.

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

이 예시에서 api.example.com 요청은 첫 번째 줄과 일치해 DIRECT가 적용됩니다. www.example.com은 첫 번째 줄과 일치하지 않지만 두 번째 줄과 일치하므로 PROXY가 적용됩니다. 두 조건에 모두 해당하지 않는 요청에만 FINAL이 적용됩니다. 여기서 [Rule]은 텍스트 Config의 규칙 섹션 제목이며, 각 규칙 앞에 반복해서 추가하는 내용이 아닙니다.

3. DOMAIN-SUFFIX, IP-CIDR, GEOIP의 매칭 대상

일반적인 조건 규칙은 보통 “규칙 유형,매칭 값,정책” 형식으로 작성하며 영문 쉼표로 구분합니다. 도메인 자리에는 호스트명만 입력하고 https://, 경로, 쿼리 매개변수는 넣지 않습니다. 예를 들어 주소의 /account는 DOMAIN-SUFFIX의 매칭 대상이 아닙니다. 이러한 규칙은 웹페이지 콘텐츠 필터링과도 다릅니다.

no-resolve는 정책명이 아니라 추가 옵션입니다. IP 규칙에 사용하면 이 규칙의 매칭을 위해 도메인을 IP로 능동적으로 조회하지 않습니다. 요청의 대상이 처음부터 IP인 경우에는 주소 범위를 계속 판단할 수 있습니다. 따라서 이 옵션이 붙은 IP 규칙이 도메인 요청과 일치하지 않는다고 해서 주소 범위가 잘못되었다고 단정할 수는 없습니다.

• 전체 호스트명에 대한 예외는 관련 DOMAIN-SUFFIX보다 앞에 둡니다. 예를 들어 먼저 api.example.com을 처리하고, 그다음 전체 example.com을 처리합니다.
• 로컬 네트워크 주소 범위는 실제 네트워크에 맞게 입력하세요. 192.168.0.0/16은 모든 가정이나 사무실 네트워크에 적용할 수 있는 범용 대체값이 아닙니다. 네트워크에 따라 다른 사설 주소 범위를 사용할 수도 있습니다.
• GEOIP는 데이터베이스와 대상 IP를 기준으로 동작합니다. 분산형 서비스를 제공하는 도메인은 지역이 다른 IP로 해석될 수 있으므로, 사이트 이름만 보고 반드시 GEOIP,CN에 매칭된다고 판단할 수 없습니다.
• 텍스트 Config를 확인할 때는 영문 구두점을 사용하세요. FINAL,PROXY와 쉼표 대신 한글 문장부호를 사용한 텍스트는 같은 구문이 아닙니다.

4. PROXY, DIRECT, REJECT와 FINAL 조합하기

PROXY는 일치한 요청을 프록시 경로로 보내고, DIRECT는 대상에 직접 연결하며, REJECT는 해당 요청을 차단합니다. 규칙에 PROXY를 작성해도 서버가 생성되거나 연결 정보가 제공되지는 않습니다. 사용하려면 먼저 본인의 서버 또는 구독 정보를 가져오고 해당 프록시 경로를 사용할 수 있는지 확인해야 합니다. 이 사이트는 노드, 구독 또는 서비스 제공업체를 제공·판매·추천하지 않습니다.

FINAL은 기본 처리 규칙이며 “모든 요청에 이 정책을 강제로 적용한다”는 뜻이 아닙니다. 앞선 규칙과 일치하지 않은 요청에만 적용됩니다. 일치하지 않은 요청을 프록시로 보내려면 FINAL,PROXY, 직접 연결하려면 FINAL,DIRECT를 작성하세요. 두 설정은 서로 다른 분기 방식이며 모든 네트워크에 통용되는 정답은 없습니다.

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

이 Config는 네 가지 결과를 보여 줍니다. 지정한 API는 직접 연결하고, 지정한 하위 도메인 범위는 차단하며, 나머지 예시 도메인은 프록시로 보내고, 어떤 규칙에도 일치하지 않는 요청은 직접 연결합니다. blocked.example.com의 REJECT는 전체 example.com 프록시 규칙보다 앞에 두어야 합니다. 그렇지 않으면 접미사 규칙이 먼저 매칭됩니다. 이 내용은 학습용 최소 규칙 섹션이며 모든 용도의 설정을 대체하지 않습니다.

마지막에 FINAL을 두 개 작성하면 안 되는 이유

앞의 FINAL이 나머지 요청을 이미 처리하므로 뒤의 FINAL이 두 번째 선택지가 되지는 않습니다. 프록시 연결이 실패해도 요청이 다음 FINAL을 시도하는 것은 아닙니다. 장애 처리가 필요하다면 중복된 기본 처리 규칙을 추가하지 말고 프록시나 정책 그룹 설정을 확인하세요.

5. Config에서 규칙을 수정하고 새 연결로 확인하기

먼저 현재 Config를 백업한 다음 결과를 명확히 확인할 수 있는 규칙을 수정하세요. 아래 경로는 모바일의 Home / Config 화면을 기준으로 합니다. 편집 메뉴는 플랫폼에 따라 다를 수 있지만, 확인할 핵심은 “어떤 파일을 편집 중인지, 어떤 파일이 활성화되어 있는지, Global Routing이 어떤 모드인지”입니다. 서버 구독 업데이트와 규칙 파일 편집은 별개의 작업입니다.

1. Config 백업

   Config로 이동해 현재 활성화된 파일을 확인한 다음 사본을 저장하거나 백업을 내보내세요. 원격 Config를 다시 다운로드하면 로컬 수정 사항이 덮어써질 수 있으므로 테스트 전에 복원할 수 있는 버전을 보관해야 합니다.

2. 규칙 편집

   Config에서 해당 파일의 편집 메뉴를 열어 규칙 편집 화면으로 이동합니다. 일반 텍스트 편집기를 사용하는 경우 [Rule] 섹션을 찾으세요. 구체적인 예외를 포괄적인 규칙보다 앞에 두고, 목록 마지막의 FINAL을 확인합니다. 기존 규칙 섹션에 제목을 반복해서 붙여 넣지 마세요.

3. 라우팅 모드 확인

   저장한 뒤 해당 Config가 활성화되어 있는지 확인하고 Home → Global Routing → Config로 돌아갑니다. Home에서 사용할 수 있는 본인의 서버가 선택되어 있는지도 확인한 다음 연결을 시작하세요.

4. 새 연결 만들기

   기존 테스트 페이지나 앱 연결을 종료한 뒤 테스트 권한이 있는 대상에 다시 접속하세요. 기존 장기 연결은 이전 경로를 계속 사용할 수 있습니다. 같은 연결을 재사용하는 페이지를 새로고침하는 것만으로는 수정이 적용되지 않았다고 판단할 수 없습니다.

5. 연결 기록 확인

   연결 기록을 열고 호스트명이나 IP로 방금 생성된 요청을 찾아 실제 정책과 표시된 규칙 정보를 확인하세요. 한 번에 순서 한 곳만 바꾸고, 변경 전후 결과를 기록해 여러 변수가 동시에 달라지지 않게 하세요.

예를 들어 본인이 관리하는 테스트 도메인에 정확히 일치하는 REJECT 규칙을 임시로 추가해 관련 접미사 규칙보다 앞에 두면 새 연결이 차단되어야 합니다. DIRECT로 복구한 뒤 직접 연결이 성공하는지도 확인하세요. 판단할 때는 연결 기록을 기준으로 삼아야 합니다. 캐시 때문에 차단된 페이지에 이전 내용이 표시될 수 있고, 페이지의 타사 리소스는 전혀 다른 도메인을 사용할 수도 있습니다.

6. 사용자 규칙 문제 해결과 자주 묻는 질문

마지막으로 정해진 순서에 따라 확인하세요. 라우팅 모드, 활성 Config, 처음 일치한 규칙, 프록시 또는 대상의 연결 상태 순입니다. 이렇게 확인하면 “규칙이 사용되지 않는 문제”, “규칙 순서 문제”, “정책은 맞지만 연결에 실패하는 문제”를 구분할 수 있어 같은 FINAL을 반복해서 수정하지 않아도 됩니다.