Shadowrocket 설정 파일 .conf 읽는 법: [General], [Rule], [Host], [URL Rewrite] 항목별 설명

이 글 미리보기

이미 연결 설정이 있고 규칙 기반 분기를 점검하거나 .conf 파일을 관리하려는 사용자를 위한 안내입니다. 먼저 Home의 연결 항목과 Config의 설정 파일을 구분한 다음 General, Rule, Host, URL Rewrite를 차례로 확인합니다. 각 설정이 어느 항목에 속하는지, 예상대로 적용되지 않는 이유와 기존 설정을 유지하면서 하나씩 검증하는 방법을 알아봅니다.

1. 먼저 .conf 파일, 연결 항목, 현재 실행 상태 구분하기

Shadowrocket의 .conf 파일은 동작 설정을 구성하는 파일이며 연결 계정과는 다릅니다. Home의 연결 항목에는 서버 주소, 포트, 인증 정보 등이 저장되고, Config 파일에는 DNS, 규칙, 로컬 매핑, 요청 재작성 등의 설정이 들어갑니다. Rule 한 줄만으로 사용할 수 있는 연결 서비스가 생기는 것은 아닙니다.

확인에 앞서 현재 사용 중인 파일과 Home → Global Routing에서 선택한 항목을 살펴보세요. Config를 선택한 상태에서 이 글의 Rule 분기 설정을 점검할 수 있습니다. Proxy와 Direct는 전역 처리 방식이 서로 다르므로, 어느 쪽에서 나온 결과만으로 특정 분기 규칙이 올바르다고 판단할 수 없습니다. Scene은 상황별 선택에 사용됩니다. 문제를 진단할 때는 해당 Scene의 설정도 확인하고, 별도의 고정 규칙 파일로 간주하지 마세요.

항목 4개

이 글에서 확인할 항목: General, Rule, Host, URL Rewrite

메뉴 3곳

Home에서는 연결, Config에서는 파일, Settings에서는 기능 설정 확인

한 번에 하나씩 변경

한 번에 설정 하나만 바꾸고 동일한 요청으로 다시 테스트

대괄호로 항목을 선언하며, 다음 항목 이름이 나올 때까지 뒤따르는 행은 해당 항목에 속합니다. General에는 키-값 형식이 흔히 쓰이고 Rule은 일반적으로 쉼표로 필드를 구분합니다. 두 형식을 서로 바꾸지 마세요. 다음 절차는 수동으로 문제를 확인하는 순서이며, 모든 네트워크 요청이 네 항목의 작성 순서대로 엄격히 처리된다는 뜻은 아닙니다.

원본 파일 백업 활성 설정 확인 설정 하나만 변경 테스트 요청 새로 실행 매칭 결과 확인

2. General: DNS를 먼저 확인한 다음 다른 전역 동작 점검

[General]의 키 이름이 전역 옵션의 의미를 결정합니다. 등호 오른쪽 값만 확인해서는 안 됩니다. 도메인이 열리지 않는다면 먼저 dns-server를 찾아 도메인 해석 실패와 해석 성공 후 연결 실패를 구분하세요. 전자는 DNS 해석 경로를 확인해야 합니다. 후자는 라우팅, 대상 포트 또는 기존 연결 항목의 인증 설정과 관련이 있을 수 있습니다.

[General]
dns-server = system

여기서 system은 시스템이 제공하는 DNS 설정을 사용한다는 뜻입니다. system이라는 서버 주소를 가리키는 것도, 요청이 반드시 직접 연결된다는 뜻도 아닙니다. 실제 해석 결과는 현재 네트워크, 캐시 및 다른 DNS 관련 옵션의 영향을 받을 수 있습니다. 원본 파일에 다른 DNS 설정이 있다면 맥락을 유지해서 확인하고, 이 한 줄만으로 전체 해석 과정을 판단하지 마세요.

Config에서 현재 사용 중인 파일을 열고 dns-server의 기존 값을 기록한 뒤 복구할 수 있도록 사본을 보관하세요.
같은 테스트 도메인으로 문제를 재현하고, 현재 네트워크가 Wi-Fi인지 셀룰러인지 기록하세요.
DNS 설정 하나만 변경하고 저장하세요. 수정한 파일이 계속 사용 중인지 확인한 다음 요청을 새로 실행합니다.
계속 실패한다면 대상 IP를 받았는지, 예상한 Rule이 매칭됐는지, 대상 연결이 정상적으로 설정됐는지 각각 확인하세요.

3. Rule: 구체적인 조건을 먼저 배치하고 FINAL은 마지막에 유지

[Rule]은 요청을 정책에 매칭합니다. 규칙은 일반적으로 위에서 아래로 확인하며, 먼저 매칭된 유효한 규칙이 처리 방식을 결정합니다. 따라서 구체적인 규칙을 포괄적인 규칙보다 위에 배치하세요. 아래는 구문을 읽기 위한 예시입니다. example.com은 예시 도메인이며, PROXY를 사용하려면 사용자가 이미 유효한 연결 설정을 갖고 있어야 합니다. 이 예시만으로 완전한 설정을 구성할 수는 없습니다.

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

도메인 및 네트워크 대역 매칭

DOMAIN-SUFFIX: example.com,PROXY
IP-CIDR: 192.168.0.0/16,DIRECT,no-resolve
no-resolve: 이 IP 규칙을 위해 도메인 해석을 먼저 실행하지 않음

도메인 조건과 IP 조건을 구분한 다음 규칙이 매칭될 수 있는지 확인하세요.

지역 및 최종 대체 규칙 매칭

GEOIP: CN,DIRECT
FINAL: PROXY
Global Routing: 이 글의 규칙을 테스트할 때는 Config 선택

지역 판정은 IP 데이터에 따라 달라지며, FINAL은 앞에서 매칭되지 않은 요청을 처리합니다.

DOMAIN-SUFFIX,example.com,PROXY는 example.com과 www.example.com 같은 하위 도메인에 매칭됩니다. 임의의 문자열에 포함되는지 확인하는 규칙은 아닙니다. 대상 도메인에 특정 정책을 적용하려면 GEOIP 같은 포괄적인 규칙보다 위에 배치해 다른 규칙이 요청을 먼저 처리하지 않도록 하세요.

IP-CIDR은 주소 대역으로 매칭합니다. 예시의 192.168.0.0/16은 해당하는 사설 주소 범위를 뜻합니다. no-resolve의 적용 범위는 이 규칙의 매칭 과정에 한정되며, 앱 전체의 DNS를 끄는 옵션이 아닙니다. GEOIP,CN,DIRECT는 대상 IP의 지역 데이터를 기준으로 판단하며, 모든 중국어 웹사이트를 직접 연결한다는 뜻이 아닙니다.

요약: 규칙이 적용되지 않으면 먼저 FINAL 위치 확인

FINAL을 규칙 맨 아래에 두고 대상 규칙이 그 위에 있는지, Global Routing이 Config로 설정됐는지 확인하세요. 이 세 가지를 점검한 다음 매칭 조건을 수정해야 현재 실행 방식의 문제를 구문 문제로 오인하지 않습니다.

4. Host: 이름 해석을 변경하며 연결 정책을 대신하지 않음

[Host]는 도메인 매핑을 명시적으로 지정합니다. Host는 이 이름이 어떤 주소에 대응하는지 정하고, Rule은 요청에 어떤 정책을 적용할지 정합니다. 두 기능은 서로 대체할 수 없습니다. 매핑을 추가해도 DIRECT 규칙이 자동으로 만들어지지 않으며, 서버 프로그램이나 연결 가능한 경로, 유효한 인증서가 제공되는 것도 아닙니다.

[Host]
demo.example.com = 192.0.2.10

여기서 192.0.2.10은 문서용 예시 주소이며 실제로 사용할 수 있는 테스트 서버가 아닙니다. 직접 관리할 권한이 있거나 주소를 명확히 확인한 대상에만 매핑을 설정하세요. 웹페이지가 열리는 것처럼 보이게 하려고 공용 사이트의 IP를 임의로 고정하지 마세요. 주소 변경이나 분산형 배포로 고정 매핑이 작동하지 않을 수 있습니다.

매핑 범위: 예시에는 demo.example.com만 지정되어 있습니다. 다른 하위 도메인에도 같은 매핑이 적용된다고 가정하지 마세요.
HTTPS 인증서 확인: 접속할 때 사용하는 이름은 원래 도메인입니다. 대상 서버는 해당 도메인에 맞는 인증서를 제공해야 하며, IP 매핑을 해도 인증서 검증 요건은 사라지지 않습니다.
문제 확인 방법: 해당 매핑을 삭제하거나 원래대로 복구한 다음 연결을 새로 설정해 결과를 비교하세요. 기존 연결이 재사용되면 잘못 판단할 수 있습니다.
매칭 관계: 대상 요청에 실제로 적용된 Rule을 확인하세요. 매핑된 IP와 최종 정책을 같은 것으로 간주하면 안 됩니다.

5. URL Rewrite: 매칭 범위를 제한하고 리디렉션 검증

[URL Rewrite]는 패턴으로 요청 URL을 매칭해 지정한 동작을 실행합니다. 도메인에 IP를 할당하는 기능은 아닙니다. 아래는 HTTP 임시 리디렉션 예시로, 매칭 표현식, 대체 대상, 동작의 세 부분을 설명합니다. 구문 확인을 위한 예시이므로 실제 사용 중인 설정에 추가할 필요는 없습니다.

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

표현식 앞의 ^와 끝의 $는 전체 매칭 범위를 제한하고, \.은 도메인의 마침표를 문자 그대로 나타냅니다. 이 예시는 http://example.com/old만 매칭하며 HTTPS, 다른 하위 도메인 또는 쿼리 매개변수가 붙은 주소에는 자동으로 적용되지 않습니다. 끝의 302는 임시 리디렉션을 뜻합니다. 이후 클라이언트가 계속 접속할지는 요청을 보내는 쪽의 처리 방식에 따라 달라집니다.

먼저 매칭되어야 하는 전체 URL을 작성한 다음, 매칭되지 않아야 하는 URL도 작성하세요. 예: http://example.com/older.
규칙의 범위를 특정 도메인과 경로로 제한해 로그인, 결제 또는 API 요청에 지나치게 넓은 표현식이 영향을 주지 않도록 하세요.
대체 대상도 원래 표현식에 다시 매칭되는지 확인하세요. 다시 매칭되면 리디렉션이 반복될 수 있습니다.
검증할 때는 페이지가 최종적으로 표시되는지만 보지 말고 리디렉션 상태와 대상 주소를 확인하세요.

6. 가져오기와 업데이트: 연결 출처와 파일 출처를 구분

연결 구독을 업데이트하는 것과 .conf 파일을 업데이트하는 것은 별개의 작업입니다. 이 글은 사용자가 이미 자신의 서비스 제공업체와 구독을 보유한 상황을 전제로 합니다. 구독은 Home의 연결 항목을 관리하고, 설정 파일은 Config의 규칙과 기타 동작을 관리합니다. 구독 업데이트에 성공해도 새 Rule을 사용하게 됐다는 뜻은 아닙니다. 원격 설정을 업데이트하면 파일에 직접 적용한 로컬 수정 사항이 덮어써질 수도 있습니다.

가져오기 전: Home에서 현재 선택한 항목을 기록하고 Config의 기존 파일을 복사해 보관하세요. Home → Global Routing의 선택 항목도 기록합니다.
내용 확인: 파일 확장자만 보고 판단하지 말고 텍스트에 [General], [Rule] 등의 설정 항목이 실제로 포함되어 있는지 확인하세요.
파일 사용: Config에서 가져온 파일이 선택되어 사용 중인지 확인하세요. 파일만 저장하고 활성 설정을 바꾸지 않았다면 테스트에 이전 규칙이 적용될 수 있습니다.
업데이트 후: 사용자 지정 Rule, Host, URL Rewrite가 유지됐는지 확인한 다음 동일한 대상에 요청을 다시 보내세요.

자동 연결 동작은 Settings → On Demand에서 별도로 확인해야 합니다. On Demand는 특정 조건에서 연결을 시작할지 결정하며 Rule의 대상 매칭을 대신하지 않습니다. 수동으로 연결을 끊은 뒤 다시 연결된다면 FINAL을 반복해서 삭제하기보다 먼저 트리거 조건을 확인하세요. 원인을 분리하려면 기존 설정을 기록하고 On Demand를 잠시 비활성화한 상태에서 수동 연결을 테스트한 다음 설정을 복구하면 됩니다.

설정을 공유하기 전에는 Rule뿐 아니라 모든 행을 확인하세요. 구독 주소의 token, 연결 인증 정보, 인증서 개인 키를 공개된 예시에 포함하면 안 됩니다. 이 사이트는 연결 노드나 구독을 제공·판매·추천하지 않습니다. 글에 나오는 도메인, 주소, 규칙은 형식과 문제 해결 방법을 설명하기 위한 예시입니다.

7. 자주 묻는 질문: 증상에 따라 해당 항목 찾기

Rule을 수정했는데 접속 방식이 바뀌지 않는 이유는 무엇인가요?

먼저 Config에서 방금 수정한 파일을 사용 중인지 확인한 다음 Home → Global Routing에서 Config가 선택되어 있는지 확인하세요. 이어서 더 위에 있는 규칙이 먼저 매칭됐는지 살펴보고 기존 연결을 끊은 후 요청을 새로 보내세요. 규칙을 편집해도 이미 설정된 연결이 반드시 새 규칙으로 다시 매칭되는 것은 아닙니다.

Host를 추가했더니 HTTPS 오류가 발생하는 이유는 무엇인가요?

매핑한 IP가 올바른지, 해당 서버가 원래 도메인에 맞는 HTTPS 서비스를 제공하는지 먼저 확인하세요. Host는 이름 매핑만 바꾸며 인증서는 변경하지 않습니다. 원래 매핑을 복구하고 요청을 새로 만들어 결과를 비교하세요. 원인을 찾는 대신 인증서 오류를 무시하지 마세요.

원격 설정 업데이트 후 사용자 지정 규칙이 사라진 이유는 무엇인가요?

업데이트된 파일과 백업을 비교해 로컬 수정 내용이 원격 설정으로 덮어써졌는지 확인하세요. 유지해야 하는 규칙은 별도 사본에 보관하고 순서와 정책을 확인한 뒤 사용하세요. 백업 없이 직접 수정한 원격 파일을 반복해서 업데이트하지 마세요.

네 항목을 복사해 넣기만 하면 연결할 수 있나요?

아니요. 이 글의 예시에는 서버 주소, 계정, 인증 매개변수가 없으며 사용할 수 있는 서비스도 설정되어 있지 않습니다. 사용자가 이미 보유한 유효한 연결 설정을 먼저 사용한 다음 분기 규칙을 테스트하세요. 대상에 연결할 수 없다면 DNS, 연결 항목, 규칙을 각각 확인해야 하며 항목을 더 추가하는 것만으로 해결되지 않습니다.

최종 점검에서는 테스트 대상과 네트워크 조건을 고정하세요. 같은 도메인, 같은 요청 경로, 같은 Wi-Fi 또는 셀룰러 환경을 사용하고 한 번에 하나씩만 변경합니다. 어느 설정 파일을 사용했는지, 어떤 규칙이 매칭됐는지, 어떤 주소로 해석됐는지, 연결이 어느 단계에서 실패했는지 설명할 수 있어야 다음 문제를 찾기 쉽습니다. 파일 전체를 반복해서 가져오는 것으로 점검을 대신하지 마세요.