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

이 글의 핵심 내용

Shadowrocket에서 본인 구독을 사용 중이며 로컬 설정 파일을 점검하려는 사용자에게 적합한 글입니다. 연결 정보와 .conf 파일의 역할을 구분하고, 네 가지 섹션 이름과 규칙 순서, URL Rewrite 형식을 살펴봅니다. 마지막으로 한 번에 한 항목씩 변경해 결과를 확인하는 방법을 소개합니다. 예시는 문법 설명용이며, 현재 환경에 그대로 적용할 수 있는 완성 설정이 아닙니다.

1. .conf 파일의 역할: 설정 파일과 연결 정보 구분하기

Shadowrocket의 .conf는 텍스트 설정 파일입니다. 대괄호 안의 섹션 이름에 따라 뒤에 오는 내용을 읽는 기능이 달라집니다. [General]에는 주로 매개변수 할당, [Rule]에는 순서가 있는 규칙, [Host]에는 로컬 도메인 매핑, [URL Rewrite]에는 URL 일치 및 처리 방식이 들어갑니다. 섹션마다 문법이 다르므로 서로 바꿔 쓸 수 없습니다.

Home에 있는 연결 정보와 Config에서 선택한 설정 파일은 서로 다른 항목입니다. 구독 업데이트는 보통 연결 항목을 동기화하고, 로컬 .conf 편집은 요청 처리 방식을 조정합니다. 구독을 업데이트해도 현재 적용 중인 규칙 파일이 바뀌는 것은 아닙니다. 반대로 .conf를 가져와도 사용할 수 있는 연결 정보가 자동으로 생기지는 않습니다.

4가지 섹션

General, Rule, Host, URL Rewrite 확인

최종 기본 규칙 1개

FINAL은 규칙 끝에서 미일치 요청을 처리합니다

정보 유형 2가지

Home의 연결 항목과 Config의 설정 파일을 각각 확인

편집하기 전에 Config에서 현재 선택된 파일을 확인하고 원본을 별도로 보관하세요. Home으로 돌아가 Global Routing을 확인합니다. [Rule]을 검증할 때는 Config를 사용하세요. Proxy와 Direct는 전체 트래픽 처리 방식을 바꾸고, Scene에는 별도의 장면 설정이 포함됩니다. 이러한 상태를 Config에서 규칙을 하나씩 테스트한 결과와 혼동하지 마세요.

파일을 가져왔는지만 확인하지 말고 Config에서 실제 선택된 파일을 확인하세요.
해당 파일의 편집 화면을 열고 섹션 이름에 반각 대괄호를 사용했는지 확인하세요.
Home에 연결 항목이 있는지 확인한 다음 Global Routing을 Config로 설정하세요.
수정 사항을 저장한 뒤 테스트 연결을 새로 설정하세요. 수정 전부터 유지된 연결을 그대로 사용하지 마세요.

2. [General]: 전역 매개변수를 설정하는 곳이며 트래픽 분기 규칙은 작성하지 않습니다

[General]에서는 키 = 값 형식으로 설정합니다. 매개변수의 적용 범위는 각 키의 정의에 따라 달라지며, 파일 맨 위에 있다는 이유만으로 모든 섹션을 덮어쓰지는 않습니다. 예를 들어 DNS 매개변수는 이름 해석에 영향을 주고, 우회 관련 매개변수는 일부 트래픽이 처리 과정에 들어가는지에 영향을 줍니다. 어느 쪽도 [Rule]의 도메인 규칙을 대신할 수 없습니다.

[General]
dns-server = system
skip-proxy = 127.0.0.1, localhost

여기서 dns-server = system은 시스템 DNS 설정을 사용한다는 뜻이지, 특정 서버를 지정하는 설정이 아닙니다. 127.0.0.1은 로컬 루프백 주소입니다. 이를 skip-proxy에 추가하는 목적은 특정 공개 웹사이트를 DIRECT로 연결하는 것과 다릅니다. 아래 예시는 두 가지 매개변수 작성 형식만 보여 주며, 일반적인 네트워크 최적화 방법은 아닙니다.

한 줄에는 매개변수 할당 하나만 작성하세요. DOMAIN-SUFFIX 규칙을 매개변수 값 뒤에 붙이지 마세요.
목록 구분에는 반각 쉼표를 사용하세요. 전각 쉼표를 쓰면 항목 전체가 잘못 읽힐 수 있습니다.
DNS를 변경하기 전에 기존 값을 기록하세요. 새 설정으로 도메인 이름이 해석되지 않으면 기존 값으로 되돌린 뒤 규칙을 점검하세요.
출처와 역할을 확인한 매개변수만 남기고, 효과를 더하려고 같은 키를 여러 번 중복 작성하지 마세요.

Settings → On Demand는 조건에 따라 연결을 설정하거나 끊는 동작을 관리합니다. [General]과 같은 기능으로 들어가는 메뉴가 아닙니다. 설정 문제를 확인할 때 연결이 자동으로 복구된다면 On Demand의 실행 조건도 살펴보세요. 자동 재연결을 .conf 저장 실패로 오해하지 마세요.

3. [Rule]: 위에서 아래로 매칭하고 FINAL로 마지막 요청 처리

[Rule]의 규칙은 순서대로 확인하며, 일반적으로 유형·매칭 값·정책으로 구성됩니다. 매칭을 완료할 수 있는 요청은 먼저 일치한 규칙의 정책을 따릅니다. 도메인이 길수록 자동으로 우선 적용되는 것도 아니고, 마지막 줄이 앞선 규칙을 모두 덮어쓰는 것도 아닙니다. 구체적인 예외 규칙은 포괄적인 규칙보다 위에 배치하세요.

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

위 예시에서 api.example.com은 DOMAIN 규칙에 먼저 일치해 PROXY를 사용합니다. www.example.com은 뒤에 있는 DOMAIN-SUFFIX 규칙에 일치해 DIRECT를 사용할 수 있습니다. 접미 도메인 규칙을 정확한 도메인 규칙보다 위로 옮기면 접미 규칙이 먼저 적용되어 API에 설정한 예외가 작동하지 않습니다.

키워드	매칭 기준	확인할 점
`DOMAIN`	전체 도메인	프로토콜, 포트, 경로는 입력하지 않습니다
`DOMAIN-SUFFIX`	도메인과 하위 도메인	구체적인 예외 규칙을 위에 배치합니다
`IP-CIDR`	IPv4 주소 대역	주소, 마스크, 이름 해석 조건을 확인합니다
`GEOIP`	대상 IP의 지리 정보를 담은 데이터베이스	웹사이트에 표시된 언어를 기준으로 판단하지 않습니다
`FINAL`	앞선 규칙에 일치하지 않은 요청	마지막에 배치하고 도메인은 입력하지 않습니다

no-resolve는 IP 규칙에 추가하는 옵션으로, 해당 IP 규칙을 위해 별도의 도메인 이름 해석을 요청하지 않는다는 뜻입니다. 앱 전체의 DNS를 끄거나, 도메인 요청이 반드시 해당 IP 대역에 일치한다는 뜻은 아닙니다. 판단할 때는 요청에 대상 IP 정보가 이미 있는지 함께 확인해야 합니다.

결론: 규칙이 적용되지 않으면 먼저 모드와 앞서 일치한 규칙을 확인하세요

먼저 Home → Global Routing을 Config로 설정한 다음 대상 규칙보다 앞에 더 포괄적인 규칙이 있는지 살펴보세요. 요청이 어떤 규칙에 일치했는지 확인한 뒤 정책을 변경할지 판단하세요. 연결 프로토콜이나 DNS부터 바꾸지 마세요.

PROXY와 DIRECT는 정책을 나타내며 프로토콜 이름이 아닙니다. PROXY 정책을 사용하려면 현재 환경에서 실제 연결을 사용할 수 있어야 합니다. FINAL을 PROXY로 바꿔도 연결 항목이 자동으로 만들어지지 않습니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard 등의 연결 유형과 DOMAIN-SUFFIX, IP-CIDR 등의 매칭 유형은 서로 다른 계층에 속합니다.

4. [Host]: 주소를 고정 매핑하며 아웃바운드 정책을 직접 선택하지 않습니다

[Host]는 로컬 도메인 매핑에 사용됩니다. 아래 예시에서는 테스트 도메인을 문서용 주소로 지정합니다. 왼쪽에는 도메인, 오른쪽에는 IP 주소를 씁니다. 192.0.2.10은 문서 예시용으로 예약된 주소 범위이며, 접속 가능한 실제 서비스 서버 주소가 아닙니다.

[Host]
demo.example.test = 192.0.2.10

Host는 적용 가능한 이름 해석 결과에 영향을 주지만, 도메인을 입력한다고 자동으로 직접 연결되는 것은 아닙니다. 최종 요청에 DIRECT와 PROXY 중 어느 쪽이 적용되는지는 Global Routing, 규칙, 실제 아웃바운드 경로를 함께 확인해야 합니다. 도메인 이름 해석이 원격에서 이뤄지는 경우에는 로컬 매핑이 최종 대상 주소를 결정한다고 단정할 수도 없습니다.

Host 매핑 확인

섹션 이름: [Host]
왼쪽: demo.example.test
오른쪽: 192.0.2.10
처리 대상: 도메인과 주소 간 로컬 매핑

도메인 뒤에 경로를 붙이거나 IP 주소에 포트를 덧붙이지 마세요.

Rule 정책 확인

섹션 이름: [Rule]
매칭 유형: DOMAIN
매칭 값: demo.example.test
정책 예시: DIRECT

DIRECT를 선택해도 직접 연결 방식을 지정할 뿐, 대상에 사용할 수 있는 주소가 제공되지는 않습니다.

Host 매핑을 사용해도 HTTPS 인증서는 해당 도메인과 일치해야 합니다. 지정한 IP로 해석되더라도 대상 서버가 해당 도메인에 맞는 인증서를 제공하지 않으면 인증서 오류가 발생할 수 있습니다. 이 경우 규칙 우선순위가 아니라 서버의 도메인 설정을 확인하세요.

5. [URL Rewrite]: 정규식, 대상 URL, 상태 코드를 각각 확인하세요

[URL Rewrite]에서는 보통 매칭 표현식, 대상 URL, 리디렉션 상태 코드 순으로 작성하고 각 항목을 공백으로 구분합니다. 이 기능은 단순히 도메인을 매칭하는 것이 아니라 URL을 처리합니다. 정규식에서 점, 괄호, 경계 기호는 각각 문법적 의미가 있습니다.

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

이 규칙은 http://example.com/으로 시작하는 주소에 일치하며, 캡처한 뒷부분을 대상 주소의 $1에 넣습니다. 예를 들어 입력이 http://example.com/docs?a=1이면 예상 리디렉션 주소는 https://example.com/docs?a=1입니다. 문법을 설명하기 위한 예시이며 외부 테스트 페이지에 접속하라는 뜻은 아닙니다.

^는 문자열의 시작을 지정해 관련 없는 URL에 포함된 일부 문자열을 대상으로 오인하지 않도록 합니다.
\.은 문자 그대로의 점을 매칭합니다. .만 쓰면 임의의 문자 하나와 일치합니다.
(.*)은 캡처 그룹을 만들고, $1은 첫 번째 그룹의 내용을 참조합니다.
302는 임시 리디렉션을 뜻합니다. 테스트할 때 브라우저에 남아 있는 캐시도 확인하세요.

HTTPS URL을 처리할 수 있는지는 암호화된 트래픽을 적법한 권한 범위 안에서 복호화하는지와 관련 설정이 완전한지에 따라 달라집니다. URL Rewrite 규칙만 추가해도 HTTPS 경로나 콘텐츠를 자동으로 읽을 수 있는 것은 아닙니다. 이 글에서는 형식을 보여 주기 위해 HTTP 주소를 사용하며, HTTPS 복호화 설정이나 인증서 신뢰를 추가하라고 안내하지 않습니다.

6. 저장 후 검증 방법: 기능별로 나누어 테스트하기

설정 파일에서 섹션이 배열된 순서가 요청 처리의 전체 실행 순서를 뜻하지는 않습니다. 네 섹션을 위에서 아래로 고정된 처리 단계처럼 읽으면 안 됩니다. 검증할 때는 먼저 선택된 파일과 전역 모드를 확인하고, 이름 해석·규칙 일치·URL 동작을 각각 살펴보세요. 한 번에 한 가지 요소만 변경해야 합니다.

원본 파일 백업선택 항목 확인한 항목 수정연결 다시 설정결과 확인

기준 상태 만들기: 정상 작동하는 설정을 보관하고 테스트 도메인, 네트워크 유형, Global Routing 상태를 기록합니다.
문법 확인: 대괄호, 등호, 반각 쉼표, 철자를 확인하고 규칙이 잘못된 섹션에 들어가지 않았는지 살펴봅니다.
규칙 검증: Config 모드에서 대상 요청을 새로 만들고 앱에서 제공하는 연결 기록으로 대상, 정책, 일치 여부를 확인합니다. 기록이 있다면 이를 근거로 판단하고 페이지가 열리는 속도만으로 결론 내리지 마세요.
매핑 검증: 직접 관리하며 서비스 설정이 올바르게 된 도메인을 사용해 실제 대상 주소를 확인합니다. 이 글의 문서용 주소로 연결 가능 여부를 테스트하지 마세요.
Rewrite 검증: 직접 관리하는 HTTP 테스트 주소를 사용해 대상 주소와 리디렉션 횟수를 확인합니다. 이전 캐시 때문에 설정 변경이 가려지지 않도록 주의하세요.
문제 발생 시 되돌리기: 원래 설정으로 복구하고 연결을 다시 설정합니다. 복구 후 정상 작동한다면 방금 수정한 항목만 따로 추가하세요.

원격 설정과 로컬 파일도 별도로 관리해야 합니다. 편집한 파일이 원격 업데이트로 덮어써질 수 있다면 별도 사본을 저장하고 실제 선택 항목이 그 사본인지 확인하세요. 구독 업데이트와 원격 설정 업데이트를 각각 확인해야 합니다. Home의 연결 항목이 바뀌었다는 이유만으로 로컬 규칙까지 교체됐다고 판단하지 마세요.

7. 자주 묻는 질문: 파일은 저장됐는데 결과가 예상과 다른 이유는?

FINAL을 첫 줄에 두면 뒤에 있는 규칙도 적용되나요?

FINAL은 규칙 끝에 배치해야 합니다. 앞선 규칙에 일치하지 않은 요청을 처리하므로 먼저 배치하면 뒤에 있는 규칙이 의도대로 작동하지 않습니다. 구체적인 예외 규칙을 포괄적인 규칙보다 앞에 두고 FINAL은 마지막에 배치한 뒤 다시 테스트하세요.

Host를 수정했는데 웹사이트가 왜 직접 연결되지 않나요?

Host는 아웃바운드 정책을 선택하지 않습니다. 먼저 Home → Global Routing을 확인하고, 이어서 [Rule]에서 해당 도메인에 적용된 정책을 살펴보세요. 이름 해석이 로컬에서 처리되는지도 확인해 원격 해석 결과를 로컬 매핑 실패로 오해하지 않도록 하세요.

구독을 업데이트했는데 Config의 규칙은 왜 바뀌지 않나요?

연결 구독과 설정 파일은 서로 다른 유형의 정보입니다. Config로 돌아가 선택된 파일과 출처를 확인하세요. 원격 설정을 업데이트하려면 해당 파일에서 작업해야 합니다. Home의 연결 구독을 반복해서 업데이트하지 마세요.

저장해도 달라지지 않는데 기존 파일을 삭제해야 하나요?

우선 삭제하지 마세요. 실제 선택된 파일을 수정했는지 확인하고 저장한 다음 연결을 새로 설정해 새 요청으로 테스트하세요. 연결이 자동으로 복구된다면 Settings → On Demand의 조건을 확인하고 전후 테스트 조건을 동일하게 유지하세요.

문제를 재현하고 확인하는 기록에는 선택한 설정 파일, Global Routing 상태, 수정한 섹션 이름과 해당 줄, 테스트 대상, 관찰 결과가 포함되어야 합니다. 기록을 공유하기 전에는 구독 주소, 토큰, 연결 인증 정보를 제거하세요. 일반적으로 관련 규칙과 비식별 처리한 대상 정보만으로도 매칭 방식을 논의할 수 있습니다.

App Store 정식 앱 확인 및 첫 설정

Shadowrocket은 전 플랫폼 클라이언트이며 iPhone과 iPad를 중심으로 제공됩니다. iPhone과 iPad는 App Store에서 한 번 구입합니다. Mac, Windows, Android, Linux 버전은 다운로드 페이지에서 무료입니다. 개발자 Shadow Launch Technology Limited, 공식 아이콘, 앱 ID 932747118을 확인하세요. 시스템 요구 사항과 구매 적용 범위는 App Store 페이지의 표기를 기준으로 합니다. 클라이언트의 일회성 구매는 연결 서비스 이용권과 별개이며, 이 문서의 안내는 본인 구독을 이미 보유한 사용자를 전제로 합니다.

App Store 정식 앱 확인 사용 가이드 보기