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

이 글 미리보기

이 글은 이미 이용 중인 서비스와 구독이 있으며 설정 파일을 확인하거나 수정하려는 사용자를 대상으로 합니다. 먼저 Home의 연결 항목과 Config의 규칙 설정을 구분한 뒤 General, Rule, Host, URL Rewrite를 차례로 살펴봅니다. 마지막으로 백업, 한 항목 수정, 활성화, 검증 순서로 진행합니다. 예시 도메인과 주소는 문법 설명용이며 실제 연결 서비스가 아닙니다.

1. .conf의 섹션 구조와 적용 조건

Shadowrocket의 .conf는 섹션별로 구성된 텍스트 설정 파일입니다. 대괄호 안의 이름은 섹션 표시자입니다. 예를 들어 [General]과 같습니다. 표시자부터 다음 섹션 전까지의 내용은 해당 섹션에 속합니다. 섹션마다 문법이 다릅니다. General은 주로 키-값 형식, Rule은 쉼표로 구분된 규칙, Host는 이름과 주소의 매핑, URL Rewrite는 매칭 표현식과 대체 대상 및 동작으로 구성됩니다.

Home에서는 연결 항목과 연결 상태를 선택하고, Config에서는 규칙 설정 파일을 관리하며, Settings에서는 앱 설정을 다룹니다. 서비스 구독을 가져왔다고 해서 .conf가 자동으로 활성화되는 것은 아닙니다. 마찬가지로 .conf를 선택해도 사용할 수 있는 연결 서비스가 자동으로 제공되지는 않습니다. 이 글에서는 설정 파일 구조만 설명하며 서비스 이용 경로는 다루지 않습니다.

4개 섹션

General, Rule, Host, URL Rewrite를 살펴봅니다. 사용 가능한 모든 섹션을 다루는 것은 아닙니다.

4가지 규칙

예시에 DOMAIN-SUFFIX, IP-CIDR, GEOIP, FINAL이 등장합니다.

한 번에 한 항목

매번 한 항목만 수정하고 수정 전 로컬 사본을 보관합니다.

Rule의 라우팅 결과를 확인하려면 먼저 Home에서 Global Routing이 Config로 설정되어 있는지 확인합니다. Proxy와 Direct는 서로 다른 전역 라우팅 모드이므로, 특정 Config 규칙의 매칭 여부를 확인하는 기준으로 사용할 수 없습니다. Scene을 사용하는 경우에는 해당 Scene에서 실제로 선택한 라우팅 설정도 확인해야 합니다. 다음 절차는 점검 순서이며, 네 섹션이 내부적으로 반드시 이 순서대로 실행된다는 뜻은 아닙니다.

파일 백업 선택 항목 확인 라우팅 모드 확인 새 요청 보내기 매칭 기록 확인

2. General: 전역 설정은 트래픽 분기 규칙이 아닙니다

[General]에는 DNS 관련 설정과 같은 전역 매개변수가 들어갑니다. 일반적인 형식은 매개변수명 = 값이며, Rule의 쉼표 구문을 그대로 넣을 수 없습니다. 아래 예시는 시스템 DNS를 사용하는 방식으로 키-값 구조를 설명하기 위한 것이며, 모든 네트워크 환경에 같은 DNS 설정을 권장하는 것은 아닙니다.

[General]
dns-server = system

dns-server는 클라이언트의 DNS 처리에 영향을 주지만, 모든 요청을 특정 아웃바운드로 보낸다는 뜻은 아닙니다. DNS 조회는 “이름에 해당하는 주소가 무엇인가”에 답하고, Rule은 “요청에 어떤 정책을 적용할 것인가”를 결정합니다. 서로 관련은 있지만 같은 설정은 아닙니다. 앱 캐시, 암호화 DNS, 연결에 도메인 정보가 포함되는지 여부도 관찰 결과에 영향을 줍니다. 웹페이지가 열린다는 사실만으로 DNS 설정이 예상대로 적용됐다고 판단할 수는 없습니다.

현재 dns-server의 전체 값을 기록한 뒤 수정합니다. 같은 작업 중에 DNS, 규칙, 연결 항목을 동시에 변경하지 마세요.
키 이름을 복사할 때 영문 철자와 반각 기호를 그대로 유지하고, =를 전각 문자로 바꾸지 마세요.
같은 키는 명확하게 하나만 설정하고, 중복 키의 덮어쓰기 순서에 의존해 설정을 관리하지 마세요.
잘 모르는 매개변수는 우선 그대로 두세요. 다른 설정 파일 형식에서 쓰이는 같은 이름의 매개변수를 그대로 사용할 수 있는 것은 아닙니다.

수정 후 여러 도메인에서 DNS 조회가 실패하면 방금 변경한 General 매개변수를 먼저 원래대로 되돌린 다음, 같은 네트워크와 같은 연결 항목으로 다시 테스트합니다. 이때 Rule의 매칭 범위를 넓혀도 DNS 문제 자체는 해결되지 않을 수 있으며, 오히려 점검 변수가 늘어납니다.

3. Rule: 첫 매칭 규칙이 정책을 결정하며 FINAL은 마지막에 둡니다

[Rule]의 규칙은 위에서 아래 순서로 확인합니다. 일반적인 형식은 유형,매칭 조건,정책입니다. FINAL에는 매칭 조건이 필요하지 않으며, 앞선 규칙에 매칭되지 않은 요청을 처리합니다. 구체적인 규칙을 포괄적인 규칙보다 앞에 두고, 마지막에 기본 처리 규칙을 배치합니다.

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

이 예시의 example.com과 192.0.2.0/24는 문서용 예시 값입니다. 첫 번째 줄은 해당 도메인과 하위 도메인에 PROXY를 적용합니다. 두 번째 줄은 예시 주소 범위에 해당하는 요청에 DIRECT를 적용합니다. no-resolve는 이 IP 규칙을 위해 도메인 조회를 별도로 시작하지 않는다는 뜻이지, 클라이언트 전체의 DNS를 끈다는 뜻은 아닙니다.

도메인 및 주소 조건

DOMAIN-SUFFIX: example.com,PROXY; example.com 및 하위 도메인에 매칭
IP-CIDR: 192.0.2.0/24,DIRECT,no-resolve; 대상 IPv4 주소 범위를 기준으로 판단
GEOIP: CN,DIRECT; 대상 IP를 지리 데이터베이스 분류에 따라 판단

도메인의 소유 관계, 대상 IP 분류, 실제 아웃바운드 위치는 서로 다른 개념입니다.

정책 및 기본 처리

DIRECT: 선택한 프록시를 거치지 않고 대상에 직접 연결
PROXY: 현재 선택된 프록시를 통해 아웃바운드 연결. 유효한 연결 설정이 필요합니다.
FINAL: FINAL,PROXY; 앞에서 매칭되지 않은 요청을 처리

규칙은 정책을 선택할 뿐, 사용할 수 없는 서비스나 잘못된 인증 정보를 해결하지 않습니다.

DOMAIN-SUFFIX,example.com,PROXY는 notexample.com에 매칭되지 않으며, 문자열 일부가 포함되기만 해도 매칭되는 것은 아닙니다. GEOIP,CN,DIRECT는 대상 IP와 데이터베이스 분류를 기준으로 하며, 웹페이지 언어, 도메인 접미사, 서비스 제공업체의 등록 지역을 기준으로 하지 않습니다. 요청이 위쪽의 도메인 규칙에 먼저 매칭되면 아래쪽 GEOIP 규칙은 해당 요청의 정책을 바꾸지 않습니다.

정리: 먼저 첫 매칭 규칙을 찾고 대상 규칙을 수정합니다

새 규칙이 적용되지 않는다면 위쪽의 더 포괄적인 규칙이 요청을 먼저 처리했는지 확인합니다. 규칙을 더 구체적으로 바꾸더라도 이미 매칭된 앞선 규칙을 건너뛸 수는 없습니다. 연결을 반복해서 끊었다 연결하기보다 매칭 조건이나 순서를 조정해야 합니다.

4. Host: 이름 매핑은 프록시나 리디렉션이 아닙니다

[Host]는 로컬 이름 매핑에 사용됩니다. 아래 예시는 문서용 예약 주소에 도메인을 연결해 문법만 보여줍니다. 이 주소는 실제 서비스에 접속하기 위한 것이 아니며, 네트워크 연결 테스트 대상으로 사용할 수 없습니다.

[Host]
lab.example.com = 192.0.2.10

Host는 이름에 대응하는 주소를 바꾸지만, 페이지 주소창의 URL을 변경하지 않으며 요청을 자동으로 DIRECT로 전환하지도 않습니다. 요청에 적용할 정책은 현재 라우팅 모드, Rule, 사용할 수 있는 도메인 또는 주소 정보를 함께 고려해야 합니다. 도메인 규칙과 주소 규칙이 함께 있는 경우 매핑 후에는 반드시 새 요청 기록으로 결과를 확인하세요. IP 기준으로만 라우팅된다고 단정해서는 안 됩니다.

이 줄에서는 포트를 지정하지 않습니다: https://lab.example.com/에 접속하면 기본 포트 443을 사용하고, http://lab.example.com/에 접속하면 기본 포트 80을 사용합니다. Host 매핑으로 443이 다른 포트로 바뀌지는 않습니다.
인증서는 도메인 이름이 일치해야 합니다: HTTPS 연결은 여전히 인증서에 포함된 도메인 이름을 검증합니다. 이름을 다른 서버로 연결해도 일치하지 않는 인증서가 유효해지는 것은 아닙니다.
캐시가 검증을 방해할 수 있습니다: 기존 연결이나 앱 내부 캐시가 이전 결과를 계속 사용할 수 있습니다. 저장한 뒤에는 기존 페이지 연결을 닫고 새 요청을 보내세요.
모든 조회가 이 매핑을 거치는 것은 아닙니다: 앱이 자체적으로 주소를 조회하거나 IP를 직접 사용하면 예상한 Host 효과가 나타나지 않을 수 있습니다.

따라서 먼저 직접 관리하는 테스트 도메인에서 Host를 확인한 뒤 유지 여부를 결정하는 것이 좋습니다. 아웃바운드 정책만 조정하려면 Rule을 수정하고, 웹 주소를 다른 주소로 바꾸려면 Host 항목을 계속 추가하는 대신 URL Rewrite를 확인하세요.

5. URL Rewrite: URL을 매칭한 뒤 지정된 동작을 실행합니다

[URL Rewrite]는 조건에 맞는 URL을 처리합니다. 아래는 HTTP를 HTTPS로 리디렉션하는 302 예시입니다. 첫 번째 부분은 정규 표현식, 두 번째 부분은 대체 주소, 마지막의 302는 동작입니다. URL 매칭과 HTTPS 암호화 콘텐츠의 범위를 구분할 수 있도록 입력 주소에는 일반 HTTP를 사용했습니다.

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

^는 URL 시작 위치부터 매칭하도록 제한해, 같은 문자열이 중간에 있을 때만 동작하는 일을 방지합니다.
example\.com에서 백슬래시는 마침표를 문자 그대로의 점으로 처리하게 합니다. 이스케이프하지 않은 .는 정규 표현식에서 더 넓은 의미를 가집니다.
(.*)는 도메인 뒤 슬래시 다음의 내용을 캡처하고, $1은 대체 대상에서 첫 번째 캡처 결과를 참조합니다.
302는 리디렉션 응답을 뜻합니다. 앱이 리디렉션을 따라가는지는 앱 자체의 HTTP 동작에도 달려 있습니다.

예를 들어 http://example.com/docs?a=1을 입력하면 이 규칙은 https://example.com/docs?a=1을 대상으로 구성합니다. 대상 사이트에 해당 페이지가 있다는 뜻은 아니며, 리디렉션 이후 HTTPS 연결이 성공한다고 보장하지도 않습니다. 이 규칙은 요청 처리 방식만 바꾸며 서버 인증서, 경로, 접근 권한은 별도로 충족되어야 합니다.

URL Rewrite는 도메인 기준 라우팅을 대신하는 방법도 아닙니다. 도메인 전체에 특정 정책을 적용하려면 Rule을 우선 사용하세요. 특정 요청을 차단해야 한다면 도메인 수준 차단인지 URL 수준 처리인지 먼저 구분하고, 서로 다른 수준의 문법을 같은 섹션에 섞지 마세요.

6. 수정 사항 적용: 저장, 선택, 새 연결로 확인

“파일 저장 성공”과 “현재 해당 파일을 사용 중”은 서로 다른 상태입니다. 특히 Config에 로컬 파일이나 원격 설정이 여러 개 있으면 사본을 편집한 뒤에도 이전 설정이 계속 사용될 수 있습니다. 원격 설정을 나중에 업데이트하면 로컬 수정 사항이 덮어써질 수도 있으므로, 먼저 알아보기 쉬운 로컬 백업을 만든 다음 테스트하세요.

기준 상태 기록: Home에서 현재 선택한 연결 항목, Global Routing 모드, Config에서 현재 선택한 파일을 기록합니다.
백업 후 한 항목만 수정: Config에서 원본 파일의 사본을 보관하고 한 섹션의 한 항목만 수정합니다. 규칙 줄 앞에 #을 붙여 실험 내용을 주석 처리하고, 섹션 전체를 삭제하지 마세요.
저장 후 활성 항목 확인: Config로 돌아가 수정한 파일이 선택되어 있는지 확인합니다. 편집 화면을 열어본 것만으로는 충분하지 않습니다.
Config로 확인: Home으로 돌아가 Global Routing이 Config인지 확인하고, 선택한 연결 항목을 실제로 사용할 수 있는지도 확인합니다.
새 연결 요청: 기존 페이지나 세션을 닫은 뒤 다시 접속합니다. 필요한 경우 수동으로 연결을 끊었다가 다시 연결해 기존 연결에 의존하지 않고 테스트하세요.
결과를 기록하고 되돌리기: 대상 도메인, 대상 주소, 매칭 규칙, 실제 정책을 확인합니다. 결과가 예상과 다르면 방금 수정한 항목을 원래대로 되돌리고 같은 테스트를 반복합니다.

서로 다른 두 종류의 “업데이트”를 구분해야 합니다. Home의 서비스 구독 업데이트는 주로 연결 항목을 변경하고, Config의 원격 설정 업데이트는 General, Rule 등의 텍스트 내용을 변경할 수 있습니다. 둘 다 “설정 새로고침”으로 뭉뚱그려 같은 효과라고 생각하지 마세요. 업데이트 전에 대상이 무엇인지 확인하고, 업데이트 후에는 실제 내용과 선택 상태를 확인합니다.

Settings → On Demand는 자동 연결 조건을 관리하며 Rule의 매칭 조건을 관리하는 항목이 아닙니다. 수동으로 연결을 끊은 뒤 자동으로 다시 연결된다면 .conf가 저장되지 않았다고 단정하지 말고 On Demand와 시스템 VPN 설정을 먼저 확인하세요. 반대로 자동 연결에 성공해도 새 규칙이 매칭됐다는 뜻은 아닙니다.

7. 자주 묻는 질문: 파일을 가져왔는데 결과가 예상과 다른 이유는 무엇인가요?

Rule을 수정했는데 왜 모든 웹사이트가 계속 직접 연결되나요?

먼저 Home에서 Global Routing이 Direct인지 확인합니다. 설정 규칙을 검증하려면 Config를 사용하세요. 그런 다음 Config로 돌아가 선택된 파일을 확인하고 대상 도메인에 새 요청을 보냅니다. 이미 연결된 세션으로 새 규칙의 적용 여부를 판단하지 마세요.

FINAL은 맨 위에 두나요, 맨 아래에 두나요?

Rule의 맨 아래에 둡니다. FINAL은 앞선 규칙에 매칭되지 않은 요청을 처리합니다. 맨 위에 두면 뒤에 있는 구체적인 규칙이 매칭될 기회를 잃습니다. 먼저 FINAL이 이미 있는지 확인한 뒤 추가 위치를 정하고, 서로 충돌하는 기본 처리 규칙을 여러 개 두지 마세요.

Host를 추가한 뒤 인증서 오류가 발생합니다. IP를 잘못 입력한 건가요?

먼저 매핑 주소가 실제로 예상한 서버의 주소인지 확인한 다음, 해당 서버가 원래 도메인에 유효한 인증서를 제공하는지 확인합니다. Host는 HTTPS가 검증하는 도메인 이름을 바꾸지 않습니다. 매핑을 원래대로 되돌려 다시 테스트하면 오류가 이번 주소 변경 때문에 발생했는지 확인할 수 있습니다.

원격 설정을 업데이트한 뒤 로컬 수정 사항이 사라졌습니다. 왜 그런가요?

별도의 로컬 사본이 아니라 원격 설정 원본을 업데이트했는지 확인합니다. 백업을 복원한 뒤 장기간 유지할 수정은 직접 관리하는 사본에 적용하세요. 다음 업데이트 때는 먼저 변경 사항을 비교하고 필요한 내용을 병합합니다. 검증 중인 파일을 바로 덮어쓰지 마세요.

.conf가 올바른지 판단할 때 파일을 가져올 수 있는지만 확인해서는 안 됩니다. 섹션 이름과 필드는 문법을 읽을 수 있는지 결정하고, 현재 선택한 항목과 라우팅 모드는 설정이 실제 처리에 참여하는지 결정합니다. 동작 검증에는 새 요청의 실제 기록을 사용해야 합니다. 이 순서로 점검하면 “문법 오류”, “활성화되지 않음”, “요청이 조건에 맞지 않음”을 구분하기 쉽습니다.