Shadowrocket 설정 파일 .conf 구조와 사용법: [General], [Rule], [Host], [URL Rewrite] 한눈에 보기

이 글의 핵심

Shadowrocket에 본인 소유의 연결 서비스를 설정해 두었으며 .conf 파일을 읽거나 수정하려는 사용자를 위한 안내입니다. 먼저 네 가지 설정 섹션의 역할을 파악한 뒤 매개변수, 규칙 순서, 도메인 매핑, 주소 변경을 차례로 확인하고 Config에서 파일을 선택해 결과를 검증합니다. 예시의 example.com과 테스트 주소는 문법 설명용이며 실제 연결 서비스가 아닙니다.

1. .conf 파일, 연결 정보, 라우팅 모드 구분하기

.conf는 텍스트 설정 파일이며, 대괄호 안의 이름은 섹션 제목이지 폴더가 아닙니다. 각 섹션은 제목에서 시작해 다음 섹션 제목 직전까지 이어지며, 빈 줄은 주로 가독성을 위한 것입니다. 규칙을 잘못된 섹션에 입력하면 영어 단어의 철자가 모두 맞더라도 앱이 해당 규칙을 올바르게 처리하지 않을 수 있습니다.

Home에서는 사용자가 보유한 연결 항목을 관리하고, Config에서는 설정 파일을, Settings에서는 앱 설정을 관리합니다. 구독으로 가져온 연결 정보와 현재 선택한 .conf 파일은 같은 것이 아닙니다. 연결 목록을 업데이트해도 설정 파일이 바뀌는 것은 아니며, 설정 파일을 저장해도 Global Routing이 Config로 변경되는 것은 아닙니다.

4개 섹션

General, Rule, Host, URL Rewrite 살펴보기

2곳 확인

Config의 현재 파일과 Home → Global Routing

일치 규칙 1개

Rule은 위에서부터 확인해 처음 일치하는 규칙 적용

Global Routing의 Config는 현재 설정에 따라 라우팅한다는 뜻입니다. Proxy와 Direct는 전체 라우팅 처리 방식을 바꾸고, Scene은 상황별 선택에 사용합니다. 이 글의 Rule 예제를 확인할 때는 먼저 Config를 선택하세요. 라우팅 모드가 달라서 파일이 저장되지 않은 것처럼 보이는 상황을 피할 수 있습니다.

2. [General]: 키-값 문법으로 전역 매개변수 설정

[General]에서는 보통 키 = 값 형식을 사용하며, 쉼표로 구분하는 Rule 문법과 다릅니다. 이 섹션의 매개변수는 DNS 서버 설정처럼 전역 처리 방식을 정합니다. 네트워크 설정 전체를 범용 최적화 목록처럼 그대로 덮어쓰지 마세요. 현재 네트워크 환경, 기존 DNS 설정, 규칙의 DNS 조회 요구 사항에 따라 결과가 달라질 수 있습니다.

[General]
dns-server = system

이 예시는 시스템 DNS를 사용하는 문법만 보여 주며 모든 네트워크에 적합하다는 뜻은 아닙니다. DNS 조회 성공과 연결 성공은 별개의 단계입니다. 대상 주소를 찾은 뒤에도 라우팅 선택, 연결 설정, 애플리케이션 계층 통신이 필요합니다. 웹페이지가 열리지 않을 때 DNS만 바꾸고 이후 단계를 확인하지 않으면 실제 원인을 놓칠 수 있습니다.

General 읽는 법

섹션 제목: [General]
매개변수 키: dns-server
예시 값: system

매개변수의 의미를 먼저 확인한 다음 등호 오른쪽의 값을 수정하세요.

Rule 읽는 법

섹션 제목: [Rule]
일치 조건: DOMAIN,example.com
처리 정책: PROXY

규칙은 유형, 일치 값, 정책 순으로 작성하며 등호는 사용하지 않습니다.

텍스트를 확인할 때는 문장 부호도 살펴보세요. 섹션 제목에는 반각 대괄호, 매개변수에는 반각 등호, 규칙에는 반각 쉼표를 사용합니다. 한국어 쉼표, 전각 공백, 서식 있는 텍스트에서 복사한 따옴표는 눈으로 비슷해 보여도 서로 다른 문자열로 처리될 수 있습니다.

3. [Rule]: 구체적인 조건을 먼저 쓰고 마지막에 FINAL 설정하기

[Rule]은 트래픽에 적용할 정책을 결정합니다. 규칙은 위에서 아래로 확인하며 처음 일치하는 규칙이 적용됩니다. 이후 규칙 중 더 ‘정확한’ 규칙을 계속 찾지 않습니다. 따라서 규칙 순서도 설정의 일부입니다. FINAL을 앞에 두면 뒤에 있는 규칙은 기본 처리 규칙보다 먼저 일치할 기회를 얻지 못합니다.

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

키워드	이 예시에서 일치하는 대상	결과 및 주의사항
`DOMAIN`	`api.example.com` 정확히 일치하는 도메인	먼저 DIRECT가 적용되며 다음 PROXY 규칙은 적용되지 않습니다.
`DOMAIN-SUFFIX`	`example.com` 및 하위 도메인	그 밖에 일치하는 도메인에는 PROXY를 사용합니다.
`IP-CIDR`	`192.0.2.0/24` 주소 대역	DIRECT를 사용합니다. 이 주소 대역은 문서 예시 전용입니다.
`GEOIP`	주소 데이터베이스에서 CN으로 분류되는 대상 IP	웹페이지 언어나 도메인 접미사가 아니라 IP 분류를 기준으로 합니다.
`FINAL`	앞선 규칙에 일치하지 않은 트래픽	이 예시에서는 기본 처리로 DIRECT를 선택합니다.

no-resolve는 이 IP 규칙과 일치시키기 위해 도메인 조회를 별도로 수행하지 않는다는 뜻이지, 앱 전체의 DNS를 끈다는 뜻은 아닙니다. 요청에 대상 IP가 이미 있다면 주소 대역을 기준으로 판단할 수 있습니다. 예시의 GEOIP에는 이 옵션이 없으므로, 한 규칙의 옵션을 Rule 섹션 전체의 설정으로 확대해 해석하지 마세요.

PROXY는 정책일 뿐 서버 정보를 자동으로 만들지 않습니다. 사용자가 이미 보유한 사용 가능한 연결 항목이 있어야 합니다. DIRECT는 직접 연결을 뜻하지만 현재 네트워크에서 대상에 접속할 수 있다는 보장은 없습니다. 검증할 때는 일치한 정책과 실제 연결 결과를 함께 확인하세요.

4. [Host]: 주소를 지정하며 프록시 정책은 지정하지 않음

[Host]는 로컬 도메인 매핑에 사용합니다. ‘이 이름은 어떤 주소를 가리키는가’를 정하는 섹션이지, ‘이 요청을 어떤 경로로 보낼 것인가’를 정하는 섹션이 아닙니다. 아래에서는 예시 도메인을 문서 테스트 주소에 매핑합니다. 이 주소는 웹 서비스를 제공하는 공개 서버가 아니므로 접속이 실패하더라도 문법이 잘못됐다고 판단할 수 없습니다.

[Host]
lab.example.com = 192.0.2.10

도메인을 주소에 매핑하는 것이므로 등호 왼쪽에 URL 전체를 입력하지 마세요. https://나 경로를 포함한 형식으로 작성하면 안 됩니다.
Host는 포트를 변환하지 않습니다. https://lab.example.com/에 접속할 때 일반 HTTPS의 기본 포트는 443이며, 일반 HTTP의 기본 포트는 80입니다.
HTTPS 인증서는 별도로 확인해야 합니다. 도메인이 다른 서버를 가리키도록 바꿔도 해당 서버의 인증서가 원래 도메인과 자동으로 일치하지는 않습니다.
매핑 후에도 Rule에 따라 라우팅을 확인해야 합니다. 해당 도메인에 DIRECT를 적용하려면 Rule에 DOMAIN,lab.example.com,DIRECT를 명시하고, 해당 규칙보다 먼저 일치할 수 있는 포괄적인 규칙 앞에 배치하세요.

앱 자체의 DNS 캐시, 재사용 중인 연결, 앱이 자체 암호화 DNS를 사용하는 경우 등은 테스트 결과에 예상한 변경 사항이 나타나지 않는 원인이 될 수 있습니다. 수정 후에는 기존 페이지를 닫고 요청을 다시 시작하세요. 필요한 경우 Shadowrocket 연결도 다시 설정하세요. 캐시 문제를 확인하기 전에 Host 항목을 계속 추가하지 마세요.

5. [URL Rewrite]: 요청 주소를 변경하며 Rule을 대체하지 않음

[URL Rewrite]는 정규식으로 URL을 일치시킨 뒤 지정된 작업을 수행합니다. 아래 예시는 예시 도메인의 HTTP 요청을 HTTPS로 리디렉션합니다. 끝에 있는 302는 리디렉션 상태 코드이며 포트 번호나 프록시 정책 이름이 아닙니다.

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

^는 URL의 시작 부분부터 일치하도록 제한합니다. \.는 도메인에 있는 실제 마침표를 나타내며, 임의의 문자가 마침표로 처리되는 것을 방지합니다.
(.*)는 슬래시 뒤의 내용을 캡처하고, 대상 주소의 $1은 첫 번째 캡처 결과를 참조합니다.
이 표현식에서는 http://example.com/docs가 https://example.com/docs로 리디렉션됩니다.
리디렉션으로 생성된 새 요청도 라우팅 설정에 따라 처리해야 합니다. 주소를 HTTPS로 바꾼다고 정책이 PROXY로 바뀌는 것은 아닙니다.

HSTS가 적용되었거나 리디렉션이 캐시된 경우 브라우저는 바로 HTTPS를 사용해 예시의 HTTP 규칙이 적용될 기회를 주지 않을 수 있습니다. 테스트할 때는 ‘클라이언트가 HTTP 요청을 보내지 않은 경우’와 ‘변경 표현식이 잘못된 경우’를 구분하세요. 주소창에 최종적으로 HTTPS가 표시된다는 이유만으로 규칙이 실행됐다고 판단하지 마세요.

6. Config에서 저장하고 적용한 뒤 검증하기

파일 수정은 편집기를 닫는 것으로 끝나지 않습니다. 어느 파일을 저장했는지, 현재 어느 파일을 적용 중인지, 연결을 다시 불러왔는지 확인해야 합니다. 아래 절차는 이미 로컬 설정 파일이 있는 경우를 기준으로 합니다. 한 번에 한 섹션만 수정하고 테스트를 통과한 뒤 다음 항목으로 진행하세요.

원본 파일 보관하기

Config로 이동해 수정할 파일을 먼저 내보내거나 복사하세요. 파일명을 기록해 이름이 같은 원격 설정과 로컬 사본을 혼동하지 않도록 합니다.
텍스트 편집하기

Config에서 대상 파일을 탭한 다음 Edit Plain Text를 엽니다. 해당 섹션 제목 아래의 내용을 수정하고 반각 문장 부호를 확인한 뒤 편집 내용을 저장하세요.
설정 파일 적용하기

Config로 돌아가 해당 파일을 탭하고 Use Config를 선택하세요. 편집 화면에 머물러 있는 것에 그치지 말고 수정한 파일이 현재 적용된 파일인지 표시를 확인하세요.
라우팅 모드 확인하기

Home → Global Routing → Config로 이동합니다. Home에서 선택된 연결 항목을 확인하고, 자동 연결이 테스트에 영향을 준다면 Settings → On Demand에서 트리거 설정을 확인하세요.
다시 검증하기

필요하면 연결을 끊었다가 다시 연결한 다음 대상 요청을 새로 보내고 요청 기록을 확인하세요. 원래 정상적으로 접속되던 대상을 비교 기준으로 사용하고, Connectivity Test 한 번의 결과만으로 전체 규칙을 검증하지 마세요.

라우팅 규칙과 콘텐츠 처리를 따로 검증하기

Rule 확인

Global Routing을 Config로 유지합니다.
정확히 일치하는 도메인과 같은 접미사를 사용하는 다른 도메인을 각각 테스트합니다.
요청 기록에서 대상, 일치한 규칙, 정책을 확인합니다.

Host 및 주소 변경 확인

요청이 예상한 DNS 조회 방식을 사용했는지 확인합니다.
대상 주소, 프로토콜, 리디렉션 응답을 확인합니다.
기존 연결, 캐시, HSTS의 영향을 확인합니다.

먼저 파일이 불러와졌는지 확인한 뒤 요청이 해당 처리 과정을 거쳤는지 검증하세요. 한 번에 변수 하나만 조정합니다.

7. 설정 파일 수정 후 자주 묻는 질문

파일을 저장했는데 왜 모든 요청에 같은 정책이 적용되나요?

먼저 Home → Global Routing에서 Config를 선택했는지 확인한 다음 Config에서 현재 파일을 확인하세요. 이어서 Rule 상단에 범위가 지나치게 넓은 규칙이 있는지, FINAL이 앞에 배치되어 있지는 않은지 살펴보세요. 텍스트 저장, 파일 적용, 라우팅 모드 선택은 서로 다른 작업입니다.

Host를 새 주소로 바꿨는데 HTTPS 오류가 발생하는 이유는 무엇인가요?

새 서버가 443 포트에서 요청을 수신하는지, 서버 인증서가 원래 도메인을 포함하는지 확인하세요. Host는 DNS 조회 결과만 바꾸며 URL의 호스트 이름을 바꾸거나 인증서 검증을 우회하지 않습니다. 기존 매핑으로 되돌려 테스트하면 이번 주소 변경이 원인인지 확인할 수 있습니다.

구독을 업데이트하면 Rule도 새 내용으로 자동 변경되나요?

그렇게 단정할 수 없습니다. Home의 연결 구독 업데이트와 Config의 원격 파일 업데이트를 각각 확인해야 합니다. 전자는 주로 연결 항목을 업데이트하고 후자는 설정 텍스트를 변경합니다. 로컬 사본을 사용한다면 현재 선택된 파일이 해당 사본인지도 확인하세요.

몇몇 웹사이트에만 PROXY를 적용하려면 네 섹션을 모두 수정해야 하나요?

보통 Rule에 대상 도메인의 PROXY 규칙을 추가하고 필요에 따라 FINAL,DIRECT를 기본 규칙으로 설정하면 됩니다. 구조를 채우기 위해 General, Host, URL Rewrite를 추가할 필요는 없습니다. 사용 가능한 연결 항목이 이미 있고 Home → Global Routing에서 Config를 선택했다는 전제입니다.

설정 파일은 섹션 제목과 문법을 확인한 뒤 규칙 순서를 살펴보고, 마지막으로 라우팅 모드와 실제 요청을 확인하는 순서로 점검하면 됩니다. 연결 문제를 더 살펴보려면 문제 해결 가이드를, 키워드의 의미가 궁금하다면 용어집을 참고하세요. 이렇게 하면 텍스트 오류, 라우팅 선택, 네트워크 접속 가능성을 나누어 확인할 수 있습니다.