Shadowrocket .conf 설정 파일 구조와 사용법: General, Rule, Host, URL Rewrite

1. .conf 파일 구조: 섹션 이름에 따라 각 줄의 해석이 달라집니다

Shadowrocket의 .conf는 텍스트 형식의 설정 파일입니다. 대괄호 안의 이름은 [General]과 같은 섹션 제목입니다. 제목 다음 내용은 다음 섹션 제목이 나올 때까지 해당 섹션에 속합니다. 같은 문장이라도 어느 섹션에 있느냐에 따라 의미가 달라질 수 있으므로 편집 전에 위치를 확인하세요.

[General]에는 주로 전역 설정이, [Rule]에는 트래픽 매칭과 정책이, [Host]에는 로컬 도메인 매핑이, [URL Rewrite]에는 URL 재작성 규칙이 들어갑니다. 네 섹션이 순서대로 실행되는 네 개의 라우팅 규칙은 아닙니다. 특히 파일에 배치된 순서를 네트워크 요청이 실제로 거치는 처리 순서로 해석해서는 안 됩니다.

아래는 파일 구조를 살펴보기 위한 예시입니다. example.com은 예시 도메인이고, 192.0.2.10은 문서용 예시 주소이지 실제 서비스 주소가 아닙니다. 이 내용을 현재 사용 중인 설정에 그대로 덮어쓰지 마세요. #으로 시작하는 단독 주석 줄은 설명용이며 규칙 매칭에 사용되지 않습니다.

[General]
dns-server = system

[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.net,PROXY
GEOIP,CN,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

[Host]
lab.example.com = 192.0.2.10

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

설정을 복사할 때는 반각 대괄호, 쉼표, 등호를 사용하세요. 규칙 끝에 한국어 설명을 바로 덧붙이지 마세요. 변경 내역을 확인할 수 있도록 하려면 모든 섹션의 순서를 한꺼번에 바꾸기보다 수정 대상 줄 앞에 별도의 주석을 추가해 목적을 적어 두세요.

2. General: 전역 설정과 DNS

[General] 설정은 주로 키 = 값 형식으로 작성합니다. 예시의 dns-server = system은 시스템에서 제공하는 DNS 서버를 사용한다는 뜻입니다. 이는 라우팅 규칙이 아니며 모든 요청이 DIRECT로 처리된다는 의미도 아닙니다. 도메인에서 주소를 확인하는 과정과 최종 연결 정책을 선택하는 과정은 각각 따로 점검해야 합니다.

DNS 조회에는 일반적으로 53번 포트가 사용되지만, 로그에 표시된 포트 하나만 보고 전체 조회 경로를 판단할 수는 없습니다. 암호화 DNS와 일반 DNS는 전송 방식이 다릅니다. 기존 설정에 명시적인 DNS 설정이 있다면 우선 현재 값을 기록한 다음 필요에 따라 수정하세요. 도메인 하나를 점검하려고 모든 DNS 설정을 한꺼번에 바꾸지는 마세요.

파일의 설정과 Settings의 스위치는 표현 방식이 다릅니다. 예를 들어 Settings → On Demand는 연결이 시작되는 조건을 다루며 특정 도메인을 DIRECT로 바꾸는 기능은 아닙니다. 문제를 확인하는 동안 On Demand의 기존 상태를 기록해 두세요. 수동으로 연결을 끊은 뒤 다시 연결되었을 때 설정 변경 사항이 저장되지 않았다고 오해하지 않도록 주의해야 합니다.

3. Rule: 매칭 대상, 순서, FINAL

[Rule]의 규칙은 순서대로 확인되며, 일치하는 규칙이 있으면 지정된 정책이 적용됩니다. 따라서 구체적인 예외 규칙은 일반적인 조건보다 앞에 두는 것이 좋습니다. 예외 규칙을 FINAL 뒤에 추가해도 앞서 적용된 기본 규칙을 덮어쓰지 못합니다.

DIRECT는 직접 연결, PROXY는 프록시 정책 사용, REJECT는 거부를 뜻합니다. PROXY 자체에는 서버 주소나 인증 정보, 연결 서비스가 포함되어 있지 않습니다. 이 글은 사용자가 직접 보유한 서비스와 구독이 있다고 가정합니다. 예시를 적용하기 전에 Home에 사용할 수 있는 연결 항목이 있는지 확인하세요.

no-resolve는 이 IP 규칙을 매칭하기 위해 별도로 도메인 조회를 수행하지 않도록 합니다. 모든 DNS를 비활성화한다는 뜻도, 도메인에 자동으로 주소를 부여한다는 뜻도 아닙니다. GEOIP는 IP 데이터베이스를 사용하며 웹페이지 언어, 도메인 접미사 또는 사용자의 현재 위치를 기준으로 판단하지 않습니다.

Global Routing의 Proxy, Direct, Config, Scene은 서로 다른 라우팅 모드입니다. Config는 설정 파일의 규칙에 따라 트래픽을 라우팅합니다. Scene을 사용할 때는 해당 Scene의 설정도 확인해야 합니다. 현재 모드를 기록해 두는 것은 규칙 문제를 재현하는 데 필요합니다.

4. Host: 로컬 도메인 매핑과 라우팅 정책은 별개입니다

[Host]에서는 도메인 = IP 주소 형식으로 로컬 매핑을 설정할 수 있습니다. 예를 들어 아래 줄은 lab.example.com을 문서용 예시 주소에 연결합니다. 이 설정은 도메인과 주소의 대응 관계만 지정하며 해당 요청을 DIRECT로 처리할지 PROXY로 처리할지는 정하지 않습니다.

[Host]
lab.example.com = 192.0.2.10

• 왼쪽에는 도메인만 입력하고 https://, 경로, 쿼리 매개변수는 입력하지 마세요.
• 오른쪽 주소는 사용자가 직접 관리하거나 사용 권한을 받은 환경의 주소여야 합니다. 예시 주소로 실제 연결 여부를 확인할 수는 없습니다.
• 이 줄에서는 서버 포트를 지정하지 않습니다. HTTPS는 기본적으로 443번 포트를 사용하며, 다른 포트는 요청 URL 또는 앱의 연결 설정에서 지정해야 합니다.
• HTTPS 접속 시에도 도메인과 인증서가 확인됩니다. IP를 다른 주소로 매핑해도 인증서가 자동으로 일치하지는 않습니다.

Host를 수정한 뒤에도 이전 주소로 연결된다면 기존 웹페이지를 닫고 새 요청을 보내세요. 브라우저 캐시, 앱 캐시, 이미 수립된 연결이 확인 결과에 영향을 줄 수 있습니다. 페이지에 변화가 있는지만 보지 말고 요청 기록에서 대상 도메인과 주소를 확인하세요.

일부 앱은 자체 DNS 조회 방식을 사용하거나 미리 설정된 IP에 직접 연결하므로 이 매핑이 예상대로 적용되지 않을 수 있습니다. 먼저 앱이 실제로 도메인과 IP 중 무엇을 요청하는지 확인하세요. 아직 조회 문제인지 확인되지 않았다면 더 포괄적인 Rule을 계속 추가해 해결하려고 하지 마세요.

5. URL Rewrite: 도메인 라우팅이 아닌 URL 패턴 재작성

[URL Rewrite]와 [Rule]은 필드 구조가 다릅니다. 아래 예시는 매칭 표현식, 대상 URL, 302를 포함합니다. 지정한 이전 주소와 일치하면 클라이언트가 새 주소로 이동하도록 하는 HTTP 리디렉션을 나타냅니다. PROXY 정책이 아니며 서버 연결 설정에도 사용되지 않습니다.

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

1. ^는 문자열의 시작을 지정하여 다른 위치에 비슷한 문자가 포함된 URL까지 함께 매칭되지 않도록 합니다.
2. \.는 도메인에 있는 마침표를 문자 그대로 나타냅니다. 정규식에서 이스케이프하지 않은 마침표는 더 넓은 범위와 일치합니다.
3. /old$는 경로와 문자열의 끝을 지정하므로 쿼리 매개변수가 추가된 URL은 이 정확한 표현식과 일치하지 않습니다.
4. https://example.com/new는 리디렉션 대상입니다. 이후에도 정상적인 DNS 조회와 라우팅, 연결 과정이 필요합니다.
5. 302는 임시 리디렉션을 뜻합니다. 테스트할 때는 주소 표시줄의 최종 주소만 보지 말고 리디렉션 경로를 확인하세요.

이 예시는 일반 HTTP URL을 대상으로 합니다. HTTPS의 경로와 쿼리 매개변수는 암호화된 요청에 포함되므로 이 예시를 임의의 HTTPS 페이지를 재작성할 수 있는 규칙으로 해석해서는 안 됩니다. HTTPS 요청 내용을 읽어야 하는 재작성에는 추가적인 MITM 조건과 신뢰 설정이 필요하며 URL Rewrite 한 줄만 추가해서는 구현할 수 없습니다. 이 글에서는 해당 조건을 설정하는 과정을 입문 단계로 다루지 않습니다.

리디렉션이 반복되지 않도록 대상 URL이 같은 규칙에 다시 매칭되지 않게 해야 합니다. 첫 테스트는 범위가 명확하고 제어 가능한 주소 하나로 진행하세요. 결과를 확인한 뒤에야 매칭 범위를 넓힐지 검토하세요. 모든 도메인을 매칭하는 정규식부터 시작하지 마세요.

6. Config에서 가져오기 및 편집: 한 번에 한 가지 변경만 확인하세요

Home은 연결과 라우팅 모드를 주로 관리하고, Config는 설정 파일을 관리하며, Settings는 앱 설정을 관리합니다. 연결 항목이나 구독이 있다고 해서 특정 .conf 파일이 선택되어 있는 것은 아닙니다. 파일을 가져온 것만으로 현재 설정으로 적용되는 것도 아닙니다. 편집을 마친 뒤 Config로 돌아가 선택된 파일을 확인하세요.

1. 원본을 보관하세요. 편집 전에 현재 사용 가능한 설정 파일을 복사하고 파일 이름, Global Routing 모드, 수정할 줄을 기록하세요.
2. 가져올 파일을 준비하세요. 직접 보유한 .conf 파일이나 신뢰하는 설정 URL을 사용하세요. 원격 텍스트는 DNS, 라우팅, 재작성 동작을 바꿀 수 있으므로 가져오기 전에 내용을 확인하세요.
3. Config를 여세요. 추가 메뉴에서 해당 파일 또는 URL을 가져오는 방법을 선택하세요. 가져온 뒤 파일 이름을 확인하고 예상한 섹션 제목이 포함되어 있는지 살펴보세요.
4. 편집 화면으로 이동하세요. 해당 설정의 작업 메뉴에서 텍스트 편집을 열고 섹션별로 설정 하나 또는 규칙 하나를 수정한 뒤 저장하세요. 편집 메뉴의 구체적인 표시는 현재 화면을 기준으로 확인하세요.
5. 설정을 선택하세요. Config에서 저장한 파일을 선택한 다음 Home → Global Routing에서 Config가 선택되어 있는지 확인하세요. 테스트 전에 필요하면 연결을 다시 설정하세요.
6. 요청을 다시 확인하세요. 같은 대상에 다시 접속해 요청 기록에서 매칭 규칙, 정책, 대상 주소를 확인하세요. 실패하면 방금 수정한 항목을 먼저 원래대로 복원한 뒤 다시 테스트하세요.

원격 설정 업데이트와 연결 항목 구독 업데이트는 서로 다른 작업입니다. 전자는 .conf 내용을 바꿀 수 있고, 후자는 주로 기존 구독의 연결 항목을 업데이트합니다. 원격 업데이트로 덮어써지는 파일에 직접 수정 사항을 저장하면 다음 업데이트 때 변경 내용이 사라질 수 있습니다. 별도 사본을 보관하고 업데이트 전후에 주요 섹션을 비교하세요.

설정이 제대로 적용되었는지 확인하려면 저장된 파일, 현재 선택된 파일, Global Routing 모드, 새로 보낸 요청을 모두 확인해야 합니다. 저장 완료 메시지만으로 요청에 새 규칙이 적용되었다고 판단할 수는 없습니다.

7. 설정 파일 편집 관련 자주 묻는 질문