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

1. .conf 파일, 구독, 현재 연결 구분하기

.conf는 텍스트 설정 파일이며, 대괄호 안의 이름은 설정 섹션을 나타냅니다. 섹션마다 문법이 다릅니다. [General]은 주로 키-값 쌍을, [Rule]은 쉼표로 구분한 규칙을 사용합니다. [Host]에는 호스트 이름 매핑을 저장하고, [URL Rewrite]에는 매칭 표현식, 대상 주소, 동작을 지정합니다. 한 섹션의 작성 방식을 다른 섹션에 그대로 복사하면 안 됩니다.

Home에서 구독을 가져오는 것은 사용할 수 있는 연결 항목을 추가하는 작업입니다. Config에서 설정을 선택하는 것은 트래픽을 처리하는 방식을 정하는 작업입니다. 두 작업은 관련이 있지만 서로 같지는 않습니다. 이용 중인 서비스 제공업체와 구독이 있다면 해당 업체에서 구독 링크를 받아, 링크에 연결 정보가 있는지 전체 설정이 포함되어 있는지 확인하세요. 링크의 확장자만 보고 내용을 판단하지 마세요.

[Rule]의 트래픽 분기 동작을 확인하려면 Home → Global Routing에서 Config를 선택해야 합니다. Proxy와 Direct는 해당 섹션의 규칙을 검증하는 데 같은 환경이 아닙니다. Scene을 사용하는 경우에는 현재 Scene에 적용된 설정도 확인하세요. 파일을 저장하기만 하고 현재 모드를 확인하지 않으면 ‘규칙을 바꿨는데 아무것도 달라지지 않는다’고 오해하기 쉽습니다.

2. General: 전역 매개변수와 DNS 확인

[General]은 DNS 등의 설정을 포함해 전역 동작을 관리합니다. 이 섹션을 볼 때는 먼저 등호 왼쪽의 키를 확인하고, 오른쪽의 값을 살펴보세요. 필드 이름, 영문 구두점, 불리언 값은 원래 형태를 유지해야 합니다. 값에 한국어 설명을 넣거나 반각 쉼표를 전각 쉼표로 바꾸지 마세요.

[General]
dns-server = system

여기서 dns-server = system은 시스템 DNS를 사용한다는 뜻입니다. 모든 연결이 직접 나가거나 모든 요청에 프록시가 지정된다는 의미는 아닙니다. DNS는 ‘이름을 어떻게 해석할지’를, Rule은 ‘연결에 어떤 정책을 적용할지’를 다룹니다. 실제 이름 해석 위치는 규칙 옵션, 프록시 프로토콜, 그 밖의 DNS 설정에 따라서도 달라질 수 있습니다.

연결 항목은 사용할 수 있는데 도메인에 접속할 수 없다면, 먼저 로그에서 DNS 조회에 실패했는지, IP를 받은 뒤 연결에 실패했는지 확인하세요. 전자의 경우 DNS를 우선 점검하고, 후자라면 적용된 정책과 대상 포트, 서버 상태도 확인해야 합니다. HTTPS의 기본 포트는 443이지만 서비스 제공업체의 연결 포트도 반드시 443인 것은 아니므로 혼동하지 마세요.

3. Rule: 위에서부터 매칭하고 FINAL은 마지막에 배치

[Rule]의 규칙은 위에서 아래 순서로 매칭됩니다. 규칙에 일치하면 지정된 정책을 적용하며, ‘더 구체적인’ 조건을 찾기 위해 다음 규칙을 계속 비교하지 않습니다. 따라서 예외 규칙은 범위가 넓은 규칙보다 앞에 둬야 합니다. 나머지 트래픽을 처리하는 FINAL은 마지막에 배치하세요.

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

여기 나온 도메인과 192.0.2.0/24는 설명을 위한 예시이며, 실제 연결 경로를 뜻하지 않습니다. 첫 번째 규칙은 지정된 호스트를 거부합니다. 두 번째 규칙은 example.com과 그 하위 도메인에 직접 연결합니다. 정확한 거부 규칙이 앞에 있으므로 blocked.example.com은 뒤에 있는 도메인 접미사 규칙으로 허용되지 않습니다.

4. Host: 이름 해석을 바꾸고 URL은 유지

[Host]는 로컬 이름 매핑에 사용됩니다. 아래 예시는 lab.example.com을 문서용 주소인 192.0.2.10에 매핑합니다. 이 주소는 접속 가능한 테스트 서버가 아닙니다. 실제로 사용할 때는 관리 권한이 있고 접근 가능한 대상 주소로 바꾸세요.

[Host]
lab.example.com = 192.0.2.10

• 프로토콜과 경로는 입력하지 않습니다: 왼쪽에는 호스트 이름을 입력하며 https://lab.example.com/path처럼 입력하지 않습니다.
• 포트를 IP 주소처럼 취급하지 않습니다: 오른쪽의 IP 매핑은 대상 포트를 다른 포트로 바꾸지 않습니다.
• Rule을 대체하지 않습니다: 매핑된 연결에도 현재 라우팅과 정책이 적용됩니다.
• 인증서 검사를 생략하지 않습니다: HTTPS에 연결할 때는 요청에 사용한 원래 호스트 이름에 해당하는 인증서를 계속 확인합니다.

도메인을 서버에 매핑한 뒤 인증서 오류가 발생한다면 IP에 연결할 수 있다는 이유만으로 Host 설정이 올바르다고 판단하면 안 됩니다. 해당 서버가 원래 호스트 이름과 TLS 연결을 올바르게 처리해야 합니다. 앱이 자체적으로 이름을 해석하거나 특정 연결 방식을 사용하는 경우에는 모든 요청에 로컬 매핑이 똑같이 적용된다고 단정할 수 없습니다. 실제 연결 로그를 기준으로 확인하세요.

5. URL Rewrite: 요청 주소를 매칭하고 지정된 동작 실행

[URL Rewrite]는 URL 매칭과 재작성을 처리하며, ‘어떤 연결로 도메인을 보낼지’를 정하는 트래픽 분기표가 아닙니다. 아래 예시는 HTTP를 HTTPS로 리디렉션하는 규칙으로, 정규식, 대상 주소, 동작 코드의 세 부분으로 구성됩니다.

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

^와 $는 각각 매칭 시작과 끝을 제한합니다. \.은 문자 그대로의 마침표를 나타내고, (.*)는 뒤에 오는 내용을 캡처합니다. 대상 주소의 $1은 첫 번째 캡처 그룹을 참조합니다. 302는 리디렉션 동작을 뜻합니다. 이 동작 코드를 Rule의 PROXY와 혼동하지 마세요.

문제를 확인할 때는 먼저 원래 요청이 HTTP인지 확인하고, 오래된 리디렉션 캐시가 남아 있는지 살펴보세요. 브라우저가 HSTS 때문에 바로 HTTPS를 사용한다면 HTTP 규칙이 매칭될 기회가 없을 수 있습니다. 두 섹션은 처리 대상이 다르므로 Rule 순서를 바꿔도 해결되지 않습니다. 동작을 확신할 수 없는 재작성 규칙은 먼저 비활성화하고 원래 접속 경로를 복원하세요.

6. 수정 후 적용: 저장, 선택, 연결 재생성

설정 파일이 Config 목록에 있어도 현재 선택된 파일이라는 뜻은 아닙니다. 텍스트를 저장해도 기존의 장시간 연결이 새로 만들어지는 것은 아닙니다. 먼저 현재 작동하는 설정을 복사해 로컬 백업을 만든 다음, 아래 순서대로 한 번에 한 가지 변수만 검증하세요. 플랫폼에 따라 메뉴 표시 방식이 다를 수 있으므로, 여기서는 Home, Config, Settings의 화면별 역할에 따라 설명합니다.

1. 대상 확인: Config에서 현재 선택된 파일을 찾아 이름을 기록한 뒤 편집 화면을 여세요. 아직 선택되지 않은 다른 파일을 잘못 수정하지 않도록 주의하세요.
2. 한 번에 한 곳만 수정: 규칙 하나 또는 키-값 하나만 변경하고, 원래 섹션 이름과 영문 구두점은 유지하세요. FINAL이 중복되었거나 규칙이 잘못된 섹션에 들어가지 않았는지도 확인합니다.
3. 저장하고 선택: 수정 내용을 저장하고 Config로 돌아와 해당 파일이 현재 설정으로 선택되어 있는지 확인하세요. 문법 오류가 표시되면 먼저 수정해야 합니다. 유효한 설정으로 확인되지 않은 상태에서 테스트를 진행하지 마세요.
4. 모드 확인: Home → Global Routing으로 돌아가 Config를 선택하고, 현재 연결 항목이 작동하는지 확인하세요.
5. 새 연결 만들기: 잠시 연결이 끊겨도 괜찮은지 확인한 뒤 다시 연결하고 테스트 앱에서 요청을 새로 보내세요. 필요하면 이전 페이지를 닫거나 테스트 앱을 재시작해 기존 연결이 재사용되지 않도록 합니다.
6. 결과 확인: 같은 대상에 요청을 반복하고 매칭된 규칙, 정책, 오류 유형을 확인하세요. ‘웹페이지가 빨라진 것 같다’는 느낌만으로 설정이 적용되었다고 판단하면 안 됩니다.

원격 설정과 로컬 편집은 따로 관리해야 합니다. 원격 파일을 다시 다운로드하면 로컬 변경 사항이 덮어써질 수 있고, Home의 연결 구독을 업데이트해도 Config의 규칙이 업데이트되는 것은 아닙니다. 사용자 지정 규칙을 장기간 관리하려면 별도 사본을 저장하고, 수정한 필드와 예상 결과를 기록하세요. 구독을 업데이트한 뒤에는 설정에서 참조하는 정책 이름이 여전히 존재하는지도 확인해야 합니다.

7. 자주 묻는 질문: 증상에 따라 설정 섹션 확인

.conf를 관리할 때는 각 섹션의 역할을 구분하는 것이 중요합니다. General은 전역 매개변수, Rule은 정책, Host는 이름 매핑, URL Rewrite는 조건에 맞는 요청 주소를 처리합니다. 한 번에 한 부분만 수정하고 복구 가능한 사본을 보관해야 설정 변경과 연결 결과를 정확히 비교할 수 있습니다.