Shadowrocket의 설정 파일을 직접 읽고 관리하려면 섹션별 역할과 규칙이 평가되는 순서를 함께 이해해야 합니다. 이 글에서는 .conf의 주요 섹션, 로컬 규칙과 원격 RULE-SET을 조합하는 예시, 저장 후 적용 여부를 확인하는 순서를 정리합니다. MITM 인증서와 외부 스크립트를 사용할 때의 보안 경계도 설명하므로, 이미 자신의 구독과 설정을 관리하고 있는 사용자가 변경 전후를 안전하게 비교하는 데 참고할 수 있습니다.
1. .conf 파일은 섹션별로 읽고 수정합니다
.conf는 설정 항목을 섹션으로 나누어 기록하는 텍스트 형식입니다. 같은 줄에 여러 설정을 무작정 이어 쓰는 파일이 아니라, 각 값이 어느 기능에 속하는지 구분하는 구조입니다. 파일을 편집하기 전에는 Config에서 현재 사용 중인 파일을 확인하고 사본을 보관하세요. 원격에서 내려받는 설정을 직접 수정하면 다음 업데이트에서 변경 사항이 사라질 수 있으므로, 수정한 파일이 로컬 파일인지 원격 파일인지 먼저 확인하는 것이 중요합니다.
자주 확인하는 섹션에는 공통 동작을 위한 [General], 서버 정의를 위한 [Proxy], 정책 그룹을 위한 [Proxy Group], 트래픽 분기 규칙을 위한 [Rule]이 있습니다. 그 밖에 호스트 처리와 URL 재작성, 스크립트, MITM 관련 설정이 별도 섹션에 들어갈 수 있습니다. 모든 파일이 같은 섹션을 포함하는 것은 아니며, 사용하지 않는 섹션을 예시를 따라 새로 추가할 필요도 없습니다.
섹션 제목은 대괄호를 포함해 별도 줄에 적고, 그 아래에는 해당 섹션에 속하는 항목을 둡니다. 줄의 앞뒤 공백이나 쉼표, 정책 이름이 틀리면 의도한 결과와 달라질 수 있습니다. 예를 들어 DOMAIN-SUFFIX,example.com,PROXY는 도메인 접미사 조건과 정책을 쉼표로 구분합니다. example.com은 설명용 값이므로 실제 정책에 넣을 때는 자신이 관리하는 규칙과 이미 정의된 정책 이름을 사용해야 합니다.
2. 규칙은 위에서 아래로 확인하고 정책 이름을 연결합니다
[Rule]의 규칙은 일반적으로 위에서 아래로 평가되며, 먼저 조건에 일치한 규칙이 해당 연결의 처리 방식을 결정합니다. 따라서 더 구체적인 예외 규칙을 넓은 범위의 규칙보다 앞에 놓고, 마지막에는 필요한 기본 경로를 정하는 FINAL을 둡니다. FINAL 앞에서 이미 일치한 연결에는 뒤쪽 규칙이 적용되지 않습니다. 파일에 이미 규칙이 있다면 전체를 지우고 아래 예시로 바꾸지 말고, 기존 순서와 정책 참조를 먼저 확인하세요.
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
RULE-SET,https://rules.example.net/sample.list,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY위 코드는 문법의 관계를 보여 주는 예시입니다. 도메인, 원격 규칙셋 주소, 정책 이름은 설명을 위한 값이며 실제 서비스의 규칙이나 연결 정보를 제공하지 않습니다. DOMAIN은 지정한 호스트를 대상으로 하고, DOMAIN-SUFFIX는 해당 접미사와 하위 도메인을 포함할 수 있습니다. 예시에서 첫 줄은 api.example.com을 직접 연결하도록 앞에서 처리하고, 다음 줄은 나머지 example.com 영역에 적용됩니다. 범위가 넓은 규칙을 먼저 두면 이처럼 세부 예외가 도달하지 못할 수 있습니다.
PROXY도 문맥에 따라 실제 프록시 서버 또는 정책 그룹의 이름으로 사용됩니다. 규칙에서 호출하는 정책이 현재 설정에 존재하는지 확인하세요. 다른 이름의 그룹을 정의해 놓고 규칙에는 PROXY라고 쓰면, 이름이 일치한다고 가정할 수 없습니다. GEOIP는 도메인 이름이나 웹페이지 언어가 아니라 연결 대상 IP와 GeoIP 판정에 관계합니다. 규칙 한 줄만 읽지 말고, 해당 조건이 어느 트래픽에 적용되는지와 정책 참조가 유효한지를 함께 살펴보세요.
규칙을 배열하는 기준: 구체적인 조건에서 기본 경로로
앞쪽에 배치
- 특정 호스트에 대한 예외
- 범위가 좁은 DOMAIN 조건
- 먼저 처리해야 하는 사용자 지정 규칙
뒤쪽에 배치
- 넓은 도메인 접미사 규칙
- 필요한 경우 원격 RULE-SET
- 마지막 기본 경로 FINAL
앞에 있는 규칙이 먼저 일치하면 뒤의 규칙은 해당 연결을 다시 선택하지 않습니다.
3. 원격 RULE-SET은 규칙 위치와 출처를 함께 관리합니다
RULE-SET은 원격 규칙 목록을 설정의 라우팅에 연결하는 방식입니다. 규칙 줄에는 규칙셋의 URL과 이를 처리할 정책이 들어갑니다. 원격 목록이 갱신되면 목록 내용도 달라질 수 있으므로, URL이 누구의 것인지, 어떤 규칙을 담는지, 어떤 정책으로 보내는지를 사용자가 확인할 수 있어야 합니다. 규칙셋을 추가한다고 해서 그 안의 각 조건이 현재 설정의 모든 규칙보다 자동으로 우선하는 것은 아닙니다. [Rule]에서 RULE-SET 줄을 어디에 두었는지가 평가 순서에 영향을 줍니다.
분기 예시를 구성할 때는 먼저 로컬 예외와 기본 정책을 정리하고, 원격 규칙셋이 처리할 범위를 확인하세요. 넓은 로컬 규칙이 원격 규칙셋보다 앞에서 일치하면 원격 목록의 일부 규칙은 기대한 대로 평가되지 않을 수 있습니다. 반대로 외부 목록을 앞쪽에 배치하면 그 목록의 조건이 로컬 규칙보다 먼저 처리될 수 있습니다. 목록의 내용과 갱신 주기를 통제할 수 없다면 민감한 접속 정책을 무조건 맡기지 말고, 필요한 규칙만 직접 관리하는 선택도 검토하세요.
| 항목 | 로컬 규칙 | 원격 RULE-SET | 확인할 점 |
|---|---|---|---|
| 규칙 위치 | [Rule] 안에서 직접 순서를 관리합니다. |
RULE-SET 줄의 위치가 전체 평가 흐름에 관여합니다. |
예외와 넓은 조건의 선후 관계를 확인합니다. |
| 내용 변경 | 파일을 직접 수정할 때 바뀝니다. | 원격 목록의 갱신으로 내용이 달라질 수 있습니다. | 출처와 업데이트 이후의 결과를 점검합니다. |
| 정책 참조 | 규칙에 적은 정책 이름을 확인합니다. | RULE-SET 뒤에 지정한 정책 이름을 확인합니다. | 현재 설정에 같은 이름의 정책이 있어야 합니다. |
| 장애 분리 | 규칙 한 줄씩 검토하기 쉽습니다. | 주소 접근, 목록 형식, 목록 내용 모두 영향을 줍니다. | 원격 목록의 변경과 로컬 편집을 구분합니다. |
원격 규칙셋의 주소를 공유하거나 점검할 때는 주소에 비공개 token이 들어 있는지 먼저 확인하세요. 구독 주소와 마찬가지로 접근 권한이 포함된 URL은 공개 게시물이나 화면 캡처에 노출하지 않는 편이 안전합니다. 이 글의 예시 주소는 실제 규칙셋이 아니므로 설정에 복사해도 유효한 목록을 가져오지 않습니다.
4. 편집 후에는 저장, 활성 파일, 실제 요청을 차례로 확인합니다
설정을 수정한 뒤에는 텍스트가 저장됐다는 사실만으로 규칙이 적용됐다고 판단하지 마세요. 파일을 저장했는지, 실제로 그 파일이 Config에서 선택되어 있는지, Home의 Global Routing이 Config인지, 그리고 테스트한 요청이 새 규칙과 일치하는지 순서대로 확인해야 합니다. Proxy나 Direct를 선택한 상태라면 Config 규칙에 따른 결과를 확인하는 시험이 아닐 수 있습니다.
-
사본 보관
Config에서 편집할 파일을 확인하고 원본을 별도로 보관합니다. 원격 출처가 있는 파일인지, 로컬에서 관리하는 사본인지도 기록하세요. 백업을 만든 뒤에만 규칙을 수정합니다.
-
한 곳만 수정
Config에서 해당 파일의 편집 기능을 열고
[Rule]에 필요한 규칙만 추가하거나 순서를 조정합니다. 서버 정보, 원격 구독 주소, 관계없는[General]값을 같은 작업에서 함께 바꾸지 마세요. -
정책 참조 확인
새 규칙의 마지막 필드가 실제 설정에 존재하는 정책 또는 그룹 이름인지 확인합니다. 오탈자, 대소문자 차이, 정의되지 않은 이름이 있으면 규칙의 조건이 맞더라도 예상한 경로를 선택하지 못할 수 있습니다.
-
활성 상태 점검
저장 후 Config 화면에서 수정한 파일이 현재 선택된 설정인지 확인합니다. 이어서 Home → Global Routing에서
Config를 선택합니다. 자동 연결이나 다른 설정 파일로 전환되는 조건을 사용하는 경우에는 실제 적용 중인 상태도 함께 확인하세요. -
같은 요청 테스트
변경 전과 같은 네트워크에서 같은 도메인으로 새 요청을 만들어 결과를 비교합니다. 기존 연결이 유지될 수 있으므로 앱이나 웹페이지를 다시 열어 확인하세요. 한 번에 여러 규칙을 바꾸지 말고, 결과가 달라지면 어떤 한 줄이 영향을 줬는지 기록합니다.
요청이 기대한 정책으로 처리되지 않는다면 규칙이 있는지만 보지 말고, 앞에서 이미 일치하는 규칙이 있는지, Global Routing이 Config인지, 테스트한 파일이 활성 상태인지 확인하세요. 원격 RULE-SET을 사용한다면 주소의 접근 가능 여부와 목록 갱신 결과도 변수입니다. 문제가 생겼을 때에는 원본으로 복원한 뒤 한 가지 변경만 다시 적용하면 원인을 좁히기 쉽습니다.
규칙을 넣었는데 결과가 그대로예요
Config에서 수정한 파일이 선택되어 있는지 확인하고, Home → Global Routing이 Config인지 살펴보세요. 그다음 새 요청으로 테스트하며, 앞쪽의 더 넓은 규칙이 먼저 매칭되는지 확인합니다.
RULE-SET 한 줄만 추가하면 되나요?
원격 주소와 규칙셋의 형식이 유효한지, 규칙 줄의 위치가 의도한 순서인지, 마지막 정책 이름이 현재 설정에 정의되어 있는지 함께 확인해야 합니다.
원격 설정을 편집해도 계속 남나요?
원격 설정은 다음 갱신에서 출처의 내용으로 바뀔 수 있습니다. 먼저 로컬 사본을 보관하고, 직접 관리할 변경은 로컬 파일에 적용하는 방식을 검토하세요.
오류 확인을 위해 전체 파일을 보내도 되나요?
전체 설정에는 서버 주소, 비밀번호, UUID, 구독 token이 포함될 수 있습니다. 공유하기 전에 민감한 값을 제거하고, 필요한 규칙 부분만 최소한으로 제공하세요.
5. MITM 인증서와 외부 스크립트는 필요한 범위만 허용합니다
MITM은 일반적인 도메인 라우팅 규칙과 다른 기능입니다. HTTPS 연결을 검사하는 기능을 사용하려면 인증서를 설치하고 기기에서 신뢰하도록 설정하는 과정이 필요할 수 있습니다. 인증서를 신뢰한다는 것은 해당 인증서로 처리되는 연결을 읽거나 변환할 수 있는 권한을 부여하는 일이므로, 단순히 규칙이 동작하는지 시험하기 위해 무심코 켜지 마세요. 인증서의 출처와 용도를 확인하고, 필요한 호스트만 대상으로 제한하며, 사용을 마친 뒤에는 더 이상 필요하지 않은 신뢰 설정을 검토하세요.
외부 스크립트도 설정 파일의 일부라는 이유만으로 안전하다고 볼 수 없습니다. 스크립트의 제공자, 실행 목적, 갱신 방식, 읽거나 바꿀 수 있는 데이터 범위를 확인하세요. 내용이 바뀔 수 있는 원격 스크립트를 사용할 때는 이전 버전을 보관하고, 업데이트 후 동작이 달라지지 않았는지 재검토하는 절차가 필요합니다. 출처를 확인할 수 없거나 설명과 실제 동작을 검증할 수 없는 스크립트는 가져오지 않는 것이 안전합니다.
보안 원칙: MITM 인증서와 외부 스크립트는 편의를 위한 기본 옵션이 아니라 신뢰 경계를 넓히는 설정입니다. 필요한 기능과 대상 범위를 먼저 정하고, 원본 설정과 변경 기록을 보관한 뒤 최소한의 범위로 적용하세요.
설정 파일에는 서버 인증 정보와 개인화된 원격 주소가 포함될 수 있습니다. Config 전체를 공개하거나 문제 화면을 공유하기 전에 URL의 token, 비밀번호, 사용자 식별자, 사설 호스트 이름을 가리세요. Shadowrocket 앱의 구매와 연결 서비스 구독은 별개이며, 구독 링크는 본인이 이용하는 서비스 제공업체에서 확인해야 합니다. 문법을 익히는 목적이라면 실제 자격 증명을 포함하지 않은 사본에서 규칙 순서와 정책 참조부터 검증하는 편이 안전합니다.