이 글은 Home에 연결 정보를 추가하고 Config에서 .conf 파일을 읽거나 수정하려는 사용자를 위한 안내입니다. 먼저 연결 매개변수와 설정 규칙의 차이를 확인한 뒤, DNS, 매칭 순서, 로컬 매핑, 요청 재작성을 차례로 살펴봅니다. 마지막으로 한 번에 한 항목씩 수정하고 요청 기록을 확인해 설정이 적용됐는지 검증합니다. 도메인과 주소 예시는 문법 설명용이며, 그대로 사용할 수 있는 서비스 설정이 아닙니다.
1. .conf 파일과 Home 연결 정보의 차이
Shadowrocket의 .conf 파일은 대괄호로 섹션을 구분하는 텍스트 설정 파일입니다. 각 섹션은 제목에서 시작해 다음 섹션 제목 직전까지 이어집니다. 빈 줄은 내용을 구분할 때 쓰며 섹션 제목을 대신하지 않습니다. 파일 형식은 JSON이 아니므로 각 줄을 큰따옴표로 감싸거나 줄 끝에 쉼표를 붙일 필요가 없습니다.
Home의 서버 주소, 포트, 인증 정보와 프로토콜 옵션은 연결 방식을 결정하고, Config에서 활성화한 설정은 요청 처리 방식을 결정합니다. 규칙 파일만 있고 사용할 수 있는 연결 정보가 없다면 프록시 연결을 만들 수 없습니다. 구독은 사용 중인 서비스 제공업체에서 받습니다. 연결 구독과 원격 .conf 설정은 용도가 다르며, 주소가 https로 시작한다는 이유만으로 어느 쪽인지 판단할 수는 없습니다.
먼저 모든 섹션 제목을 찾은 다음 각 줄이 어떤 문법에 해당하는지 살펴보세요. [General]과 [Host]에는 등호로 구분한 키-값 쌍이 자주 쓰이고, [Rule]에는 영문 쉼표로 구분한 필드가 자주 쓰입니다. [URL Rewrite]에는 정규식, 대상, 동작이 포함됩니다. 서로 다른 섹션의 형식을 섞어 쓰지 마세요.
2. [General]: 전역 설정과 DNS 먼저 확인하기
[General]에는 전역 동작 설정이 들어갑니다. 연결 테스트에는 응답이 있지만 도메인이 열리지 않는다면, 모든 규칙을 바로 바꾸기보다 먼저 이 섹션의 DNS 설정을 확인하세요. 아래는 키-값 문법을 설명하기 위한 설정 항목 하나로, 완전한 설정 파일이 아닙니다.
[General]
dns-server = systemdns-server는 사용할 리졸버를 지정하며, system은 시스템 DNS를 사용한다는 뜻입니다. 모든 DNS 요청이 프록시를 통과한다는 의미는 아니며, 실제 조회 경로는 네트워크 환경과 다른 DNS 옵션에도 영향을 받습니다. 리졸버를 특정 공용 주소로 바꿔도 도메인 조회가 반드시 성공하는 것은 아닙니다.
전역 설정 확인표
- 섹션
- [General]
- 설정 항목
- dns-server
- 예시 값
- system
- 문법
- 키 = 값
먼저 현재 값을 확인하고, 변경 전후의 조회 결과를 기록하세요.
규칙 테스트 전 확인 사항
- 연결 정보
- Home에서 확인
- 설정 파일
- Config에서 활성화 여부 확인
- 라우팅 모드
- Global Routing → Config
- 자동 연결
- Settings → On Demand
On Demand는 연결을 시작할 조건을 관리하며, [Rule]의 매칭 규칙을 대신하지 않습니다.
수정하기 전에 원래 값을 저장하세요. 리졸버를 바꾼 뒤 모든 도메인에서 동시에 조회 오류가 발생하면 해당 항목을 원래대로 되돌린 후 다시 테스트하세요. 아웃바운드 정책, 매핑, 재작성을 한꺼번에 바꾸지 않아야 리졸버에 연결할 수 없는 문제인지, 아니면 조회는 성공했지만 이후 연결 단계에서 실패한 것인지 구분할 수 있습니다.
3. [Rule]: 매칭 순서와 정책 이해하기
[Rule]은 위에서 아래 순서로 규칙을 확인하고, 일치하는 항목의 정책을 적용합니다. 일반적으로 구체적인 도메인 규칙은 범위가 넓은 IP 또는 지리 규칙보다 위에 둡니다. 남은 요청을 처리하는 FINAL은 맨 아래에 둡니다. 아래 예시는 구조를 설명하기 위한 것이며, PROXY를 사용하려면 해당하는 프록시 아웃바운드가 준비되어 있어야 합니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY| 키워드 | 예시 의미 | 확인할 점 |
|---|---|---|
DOMAIN-SUFFIX | example.com과 그 하위 도메인에 매칭됩니다. | 임의 문자열 포함 여부를 찾는 규칙이 아닙니다. |
IP-CIDR | 192.0.2.0/24 주소 대역에 매칭됩니다. | no-resolve는 이 규칙과 매칭하기 위해 도메인을 별도로 조회하지 않는다는 뜻입니다. |
GEOIP | IP 지리 데이터베이스를 기준으로 CN에 매칭됩니다. | 판단 기준은 IP 데이터이며 웹사이트에서 사용하는 언어가 아닙니다. |
FINAL | 앞선 규칙에 매칭되지 않은 요청을 PROXY로 보냅니다. | 도메인 필드가 없으므로 세 필드 형식으로 작성하면 안 됩니다. |
DIRECT는 직접 연결을 뜻하며 네트워크 연결 중단을 의미하지 않습니다. PROXY는 프록시 정책을 사용한다는 뜻일 뿐, 연결 정보를 자동으로 만들어 주지는 않습니다. 원본 파일에서 사용자 지정 정책 이름을 사용한다면 해당 정책이 실제로 정의되어 있는지 확인하세요. 이름만 바꾸고 정책 정의를 빠뜨리지 않도록 주의해야 합니다.
확인: 라우팅 모드를 먼저 확인한 뒤 규칙 순서 조정하기
[Rule]을 검증할 때는 먼저 Global Routing을 Config로 설정한 다음 요청이 어떤 규칙에 매칭됐는지 확인하세요. Proxy나 Direct 모드라면 Config로 전환한 뒤 다시 테스트해야 합니다. 그 결과만으로 규칙 문법이 잘못됐다고 단정할 수는 없습니다. Scene도 고정된 FINAL 규칙과는 다릅니다.
위 예시의 192.0.2.0/24는 문서 설명용 주소 대역으로, 실제 접속 대상이 아닙니다. 도메인 규칙과 IP 규칙은 서로 다른 대상을 기준으로 합니다. 전자는 도메인을, 후자는 주소를 확인합니다. 특히 no-resolve를 사용할 때 도메인 요청이 특정 IP 규칙에 매칭되지 않았다는 이유만으로 DNS 조회 장애라고 판단하지 마세요.
4. [Host]: 로컬 매핑과 트래픽 분기 규칙 구분하기
[Host]는 로컬 이름 매핑을 설정하는 섹션입니다. 아래 예시는 도메인을 문서용 주소에 연결해 형식을 보여줄 뿐입니다. 해당 주소로 실제 서비스에 접속해도 정상적인 서비스 응답을 받을 수 없습니다.
[Host]
demo.example.com = 192.0.2.10이 설정은 도메인이 어떤 주소로 조회되는지를 지정할 뿐, 요청이 어떤 연결을 사용하는지는 지정하지 않습니다. 매핑 후 적용되는 정책은 라우팅 모드와 규칙을 함께 확인해야 합니다. 브라우저 주소 표시줄의 도메인을 바꾸거나 HTTPS 인증서 검증에 사용되는 호스트 이름을 자동으로 변경하지도 않습니다.
- 주소 변경 테스트: 대상 서버가 정상이라는 점을 확인한 뒤, 명시적인 도메인 매핑으로 새 주소를 테스트할 수 있습니다. 테스트가 끝나면 임시 항목을 삭제하세요.
- 인증서 오류가 발생하는 경우: 대상 서버가 원래 도메인에 유효한 인증서를 제공하는지 확인하세요. 임의의 주소로 매핑하는 방법으로 인증서 문제를 해결하려고 하지 마세요.
- 매핑 후에도 프록시를 사용하는 경우:
[Rule]의 도메인 규칙과 최종 정책을 확인하세요. 정책 설정을 대신하기 위해[Host]를 수정해서는 안 됩니다. - 특정 도메인 하나만 문제가 있는 경우: 오래된 매핑이 남아 있는지 먼저 확인한 뒤 공용 DNS를 점검하세요. 로컬에서 덮어쓴 항목을 놓치지 않도록 합니다.
5. [URL Rewrite]: 주소 매핑과 요청 재작성 구분하기
[URL Rewrite]는 처리할 수 있는 요청 URL을 매칭해 재작성합니다. DNS 설정이나 도메인 분기 규칙이 아닙니다. 아래에서는 HTTP 주소를 HTTPS 주소로 보내는 예시를 통해 정규식, 대상, 동작의 작성 형식을 보여줍니다.
[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302^와$는 매칭 범위를 제한해 URL 일부만 매칭되는 것을 방지합니다.example\.com에서 백슬래시는 점을 문자 그대로 해석하도록 합니다. 정규식에서 이스케이프하지 않은 점은 다른 문자와도 매칭될 수 있습니다.(.*)은 슬래시 뒤의 내용을 캡처하며, 대상에 있는$1은 첫 번째 캡처 결과를 참조합니다.302는 임시 리디렉션을 뜻합니다. 재작성된 요청도 도메인을 조회하고 연결을 설정할 수 있어야 합니다.
HSTS 또는 브라우저 자체의 HTTPS 우선 기능으로 요청을 보내기 전에 주소가 HTTPS로 바뀌면, 위 HTTP 규칙에 매칭되는 요청이 없을 수 있습니다. 이때는 주소 표시줄에 처음 입력한 내용만 보고 판단하지 말고 실제로 전송된 URL을 확인하세요.
재작성과 매핑은 각각 따로 검증해야 합니다. [Host]는 이름이 주소로 변환되는 결과에 영향을 주고, [URL Rewrite]는 조건에 맞는 요청 URL에 영향을 줍니다. 두 항목을 동시에 수정하면 점검 범위가 넓어집니다. 특히 리디렉션 후 호스트 이름이 바뀌면 새 호스트 이름의 조회 결과와 정책도 다시 확인해야 합니다.
6. Config에서 수정·활성화·검증하기
파일을 읽었다고 해서 설정이 적용된 것은 아닙니다. Config에서 현재 활성화된 설정을 확인한 뒤 복사본을 편집하세요. 파일 이름만 보고 어떤 파일이 적용 중인지 판단하지 마세요. 원격 설정을 업데이트하면 로컬 수정 내용이 덮어써질 수 있으므로 직접 관리하는 내용과 원격 설정을 구분해야 합니다.
- 원본을 저장하세요. 현재 설정 이름,
dns-server값, Global Routing 모드를 기록하고 수정 전 복사본을 보관하세요. - 테스트 대상을 하나 선택하세요. 직접 접속할 권한이 있고 예상되는 동작을 알고 있는 도메인을 사용하세요. example.com과 문서용 IP는 문법 설명을 위한 예시이며 프록시 사용 가능 여부를 확인하는 대상이 아닙니다.
- 한 곳만 수정하세요. 예를 들어
DOMAIN-SUFFIX규칙 하나의 위치만 조정하고, DNS 변경이나 새 재작성 규칙 추가는 미루세요. - 저장한 뒤 설정이 활성화됐는지 확인하세요. 필요한 경우 연결을 다시 설정하고 새 요청을 보내 기존 연결이나 캐시 결과를 새 규칙의 결과로 오인하지 않도록 하세요.
- 요청 기록을 확인하세요. 실제 도메인, 매칭된 규칙, 아웃바운드 정책, 오류 유형을 대조하세요. DNS 조회 실패, 연결 시간 초과, 인증서 오류는 서로 다른 단계의 문제이므로 각각 따로 처리해야 합니다.
수정 후 문제가 생기면 방금 변경한 항목을 먼저 원래대로 되돌리고 같은 테스트를 반복하세요. 복원에 따라 결과가 일관되게 달라지는 경우에만 문제 범위를 더 좁힐 근거가 생깁니다. 구독 업데이트 성공은 해당 콘텐츠를 가져와 처리했다는 뜻일 뿐, Config의 규칙이 바뀌었다는 의미는 아닙니다. 마찬가지로 원격 설정 업데이트에 성공해도 Home의 연결 인증 정보가 갱신되는 것은 아닙니다.
7. 설정 파일 관련 자주 묻는 질문
[Rule]을 수정했는데 왜 접속 경로가 바뀌지 않나요?
먼저 Config에서 수정한 파일이 현재 활성화된 파일인지 확인하고, Global Routing → Config 설정을 확인하세요. 그런 다음 새 요청을 보내 위쪽의 더 넓은 범위 규칙에 먼저 매칭됐는지 살펴보세요. 그렇다면 구체적인 규칙을 해당 규칙보다 위로 옮긴 뒤 다시 테스트하세요.
PROXY를 설정했는데 왜 연결되지 않나요?
Home으로 돌아가 현재 선택된 연결을 사용할 수 있는지 확인하고, 주소·포트·인증 정보가 서비스 제공업체의 안내와 일치하는지 확인하세요. PROXY는 처리 정책만 지정하며 Shadowsocks, VMess, VLESS, Trojan에 필요한 연결 정보를 채워 주지는 않습니다.
구독을 업데이트하면 직접 작성한 규칙도 함께 업데이트되나요?
먼저 업데이트 대상이 연결 구독인지 원격 설정인지 구분하세요. 연결 구독은 주로 서버 항목을 관리하며 직접 작성한 규칙은 Config에서 확인해야 합니다. 원격 설정은 로컬 복사본을 보관하고, 업데이트 후 사용자 지정 내용이 남아 있는지 항목별로 비교하세요.
.conf 파일 여러 개를 그대로 이어 붙여도 되나요?
그대로 이어 붙이지 마세요. 먼저 섹션별로 내용을 정리하고 이름이 같은 설정, 중복 매핑, 정책 이름, 규칙 순서를 확인한 다음 FINAL을 규칙 맨 아래에 두세요. 병합 후에는 소수의 확인된 요청으로 검증한 뒤 다른 내용을 추가하세요.
계속 점검하려면 문제 해결을 확인하세요. 설정과 키워드의 의미를 확인하려면 기능 및 설정 또는 용어집을 참고하세요. 설정과 테스트 결과는 자신의 설정 및 요청 기록을 기준으로 판단해야 합니다. 예시 파일을 범용 연결 설정으로 사용하지 마세요.