앱 화면에서 서버와 연결을 관리하는 데 익숙해졌다면, 다음 단계는 구성 파일의 각 섹션이 어떤 역할을 하는지 이해하는 것입니다. Shadowrocket의 .conf는 규칙, DNS, URL Rewrite, MITM 같은 설정을 텍스트로 관리하는 파일입니다. 이 글에서는 사용자가 이미 보유한 구성과 서버 정보를 바탕으로 예제를 읽고 수정하는 방법을 살펴봅니다. 예시 도메인과 주소는 문법 설명용이므로 실제 서비스 주소나 완성된 구성으로 사용하지 마세요.
규칙은 위에서 아래로 확인하고, 넓은 범위의 규칙과 FINAL의 위치를 특히 주의해야 합니다. 원격 RULE-SET은 가져오는 주소와 결과 정책을 함께 확인하고, URL Rewrite와 MITM은 적용 대상 호스트를 좁혀 테스트하세요. HTTPS 내용을 확인하려면 인증서 설치와 신뢰 설정이 필요할 수 있으며, 인증서와 스크립트는 출처와 권한을 점검한 뒤 사용해야 합니다.
.conf의 섹션과 수정 전 준비
구성 파일은 대괄호로 표시한 섹션과 그 아래에 적는 항목으로 이루어집니다. 예를 들어 [Rule]에는 트래픽 분기 규칙을, [URL Rewrite]에는 URL 변경 규칙을, [MITM]에는 HTTPS 캡처 대상 호스트를 작성합니다. 섹션 이름은 기능을 구분하는 표지이지, 그 자체로 설정을 활성화하는 스위치는 아닙니다. 같은 파일 안에서도 각 섹션의 문법은 서로 다르므로 규칙 줄을 MITM 섹션에 넣는 식으로 섞지 마세요.
수정 전에는 현재 사용 중인 파일을 복제하거나 원본 내용을 안전하게 보관하세요. 원격에서 내려받은 구성이라면 제공자가 관리하는 항목을 직접 바꾸기 전에 갱신 시 변경 내용이 유지되는지 확인해야 합니다. 파일을 편집한 뒤에는 저장 여부뿐 아니라 Config에서 실제로 그 구성을 선택했는지, Home의 Global Routing이 Config인지도 확인하세요. 다른 라우팅 방식을 선택했다면 규칙 수정 결과가 예상대로 드러나지 않을 수 있습니다.
규칙 섹션
- 섹션
[Rule]- 항목 예
DOMAIN-SUFFIX,example.com,PROXY- 검토점
- 규칙 순서와 마지막
FINAL
구체적인 대상 규칙을 포괄 규칙보다 먼저 배치하세요.
HTTPS 캡처 섹션
- 섹션
[MITM]- 항목 예
hostname = api.example.com- 전제
- 인증서 설치와 신뢰 설정
캡처가 필요한 호스트만 제한적으로 등록하세요.
규칙 우선순위와 원격 RULE-SET
[Rule]의 규칙은 일반적으로 작성 순서대로 평가됩니다. 특정 도메인 규칙보다 먼저 넓은 범위의 규칙이 일치하면 아래쪽의 더 세밀한 항목은 선택되지 않을 수 있습니다. FINAL은 앞선 규칙에 일치하지 않은 연결을 처리하는 마지막 규칙으로 두는 것이 일반적입니다. 실제 결과는 현재 구성의 정책 이름과 Global Routing 선택 상태에도 영향을 받으므로, 한 줄만 떼어 보고 전체 동작을 단정하지 마세요.
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
RULE-SET,https://rules.example.net/list.txt,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY위 예시는 문법과 배치 순서를 설명하기 위한 조각입니다. 앞의 DOMAIN은 로그인 호스트만 직접 연결하도록 지정하고, 다음 DOMAIN-SUFFIX는 해당 도메인과 하위 도메인에 적용됩니다. 원격 RULE-SET은 주소에서 규칙 목록을 가져와 지정한 정책으로 처리하는 방식입니다. 이 예시의 정책이 사용자의 구성에 정의되어 있는지, 목록이 실제로 접근 가능하며 올바른 규칙 형식인지 확인해야 합니다. 주소가 유효해 보여도 업데이트 실패나 목록 내용 오류가 있으면 기대한 분기가 이뤄지지 않을 수 있습니다.
| 유형 | 적용 범위 | 점검할 내용 |
|---|---|---|
DOMAIN | 지정한 호스트명 | 전체 호스트명이 정확한지 확인합니다. |
DOMAIN-SUFFIX | 도메인과 하위 도메인 | 범위가 넓어 다른 하위 호스트까지 포함하는지 확인합니다. |
RULE-SET | 원격 또는 구성에 지정된 규칙 목록 | 목록 주소, 갱신 결과, 정책 이름을 확인합니다. |
FINAL | 앞선 규칙에 일치하지 않은 연결 | 규칙 섹션의 끝에 있는지와 의도한 기본 정책인지 확인합니다. |
문제가 생기면 여러 규칙을 한꺼번에 고치지 말고, 대상 호스트 하나를 정해 적용 결과를 확인하세요. Data 화면의 연결 기록이나 요청 기록에서 대상과 선택된 정책을 볼 수 있다면, 기록된 시각과 테스트 URL을 함께 대조합니다. 구독 주소, 토큰, 서버 인증 정보가 보이는 화면을 공유할 때는 해당 값을 가리세요.
URL Rewrite: 대상과 동작을 좁혀 테스트
[URL Rewrite]는 URL에 패턴을 적용해 다른 URL로 바꾸거나 응답 동작을 지정하는 항목을 둘 수 있습니다. 아래는 한 호스트의 특정 경로를 다른 경로로 바꾸는 형식 예시입니다. 정규식 특수문자와 슬래시를 포함한 실제 표현은 구성에 맞게 검증해야 하며, 기존 규칙과 겹치면 예상하지 않은 URL에도 적용될 수 있습니다.
[URL Rewrite]
^https?://example\.com/old https://example.com/new 302302는 예시에서 사용하는 임시 리다이렉트 상태 코드입니다. 이 줄은 모든 사이트의 이동을 바꾸는 일반 설정이 아닙니다. 규칙을 적용하기 전에는 정규식이 의도한 호스트와 경로만 일치하는지 확인하고, 테스트 때는 기존 브라우저 탭을 재사용하지 말고 새 탭에서 요청을 시작하세요. 브라우저 캐시, 웹사이트 자체 리다이렉트, 앱 내부 요청이 결과를 다르게 보이게 할 수 있습니다.
- 호스트 범위: 테스트 대상의 호스트명이 패턴과 정확히 일치하는지 살펴보세요.
- 경로 범위: 슬래시, 점, 물음표처럼 정규식에서 의미가 있는 문자를 확인하세요.
- 결과 확인: 요청 기록에서 원래 URL과 처리 결과를 비교하고, 문제가 생기면 방금 추가한 줄만 비활성화해 재시험하세요.
MITM과 인증서 신뢰 설정
HTTPS 트래픽은 기본적으로 암호화됩니다. 패킷 캡처에서 연결 대상, 포트, 전송량 같은 정보가 보이더라도 HTTPS 본문을 읽을 수 있다는 뜻은 아닙니다. Shadowrocket의 MITM 기능은 사용자가 지정한 호스트에 대해 HTTPS 연결을 중간에서 처리해 내용을 확인할 수 있도록 하며, 기기에서 관련 인증서를 신뢰하도록 설정해야 합니다. 금융, 의료, 계정 인증 등 민감한 통신을 임의로 캡처하지 말고 본인이 관리하거나 캡처 권한을 받은 대상에만 적용하세요.
-
원본 구성 보관
Config에서 현재 활성 구성의 사본을 보관하고 테스트 대상 호스트를 한 개만 정합니다. 서비스의 구성이 원격 관리되는 경우 제공된 안내를 먼저 확인하세요.
-
호스트 제한
[MITM]의hostname에 확인이 필요한 호스트만 넣습니다.example.com은 설명용 예시이며, 와일드카드 범위를 넓히기 전에 실제로 필요한 하위 도메인을 확인하세요. -
인증서 생성
Shadowrocket의
Settings → MitM에서 인증서 생성 또는 설치 안내를 확인하고 화면의 단계에 따릅니다. 인증서 파일과 설치 안내는 본인이 신뢰하는 앱 및 구성에서만 사용하세요. -
시스템에서 신뢰
iOS의
Settings → General → About → Certificate Trust Settings에서 해당 루트 인증서의 완전 신뢰 설정을 확인합니다. 기기와 시스템 버전에 따라 표시되는 항목이 다를 수 있으므로 실제 화면 안내를 따르세요. -
요청과 복원
Shadowrocket 연결을 켜고 새 요청을 만들어 기록을 확인합니다. 테스트가 끝나면 불필요한 MITM 호스트를 제거하고, 사용하지 않는 인증서의 신뢰도 해제하거나 프로파일을 정리하세요.
인증서를 설치했다고 모든 HTTPS 연결이 자동으로 복호화되는 것은 아닙니다. MITM 대상 호스트, 현재 선택한 구성, 연결 경로, 앱이나 웹사이트의 인증서 검증 동작이 함께 영향을 줍니다. 연결이 실패하면 먼저 테스트 대상이 hostname에 포함되는지, 인증서가 신뢰 상태인지 확인하세요. 연결이 정상으로 돌아오지 않는다면 MITM 설정을 원래대로 되돌려 비교합니다.
로그·패킷 캡처로 검증하고 스크립트 점검하기
설정이 작동하는지 확인할 때는 예상만으로 판단하지 말고, 변경 전후의 요청 기록을 비교하세요. Data에서 확인 가능한 요청 또는 로그 화면을 열어 테스트 시각, 호스트명, 연결 결과와 선택된 규칙을 기록합니다. 메뉴의 표시 방식은 앱 버전에 따라 다를 수 있습니다. 패킷 캡처는 연결이 어떤 주소와 포트로 오가는지 파악하는 데 유용하지만, TLS 암호화가 유지되는 상태에서는 애플리케이션 본문이 읽히지 않을 수 있습니다. HTTPS 본문 확인에는 앞 절의 MITM 조건이 별도로 필요합니다.
테스트 전: 호스트 / 네트워크 / Global Routing / 선택한 구성
테스트 요청: 새 연결에서 정해 둔 URL 한 번 열기
확인 결과: 요청 시각 / 적용 규칙 / 연결 상태 / 표시된 오류
비교 방법: 설정 한 항목만 변경한 뒤 같은 조건으로 재요청구성에 스크립트 항목이 있다면 스크립트의 출처, 실행 목적, 대상 URL 패턴, 요청·응답 중 접근하는 데이터, 외부로 전송하는 정보가 있는지 검토하세요. 스크립트가 사용하는 문법과 옵션은 해당 구성의 설명을 기준으로 확인하고, 출처를 확인할 수 없는 코드를 복사해 실행하지 마세요. 특히 인증 헤더, 쿠키, 계정 식별 정보가 포함된 요청을 변경하거나 외부로 보내는 스크립트는 사용하지 않는 것이 안전합니다. 예시 형식을 그대로 실제 구성에 붙여 넣는 대신, 현재 파일의 문법과 Shadowrocket 화면에서 유효성을 확인하세요.
규칙을 추가했는데 결과가 그대로예요
Config에서 수정한 파일이 활성 상태인지, Home의 Global Routing이 Config인지 확인하세요. 그다음 요청 기록에서 더 앞선 규칙이 먼저 일치했는지 살펴보세요.
패킷 캡처에 HTTPS 내용이 안 보여요
일반 패킷 캡처만으로 TLS 본문이 보이지 않는 것은 정상입니다. 권한이 있는 테스트 호스트만 MITM에 추가하고 인증서 신뢰 설정과 새 연결 여부를 점검하세요.
설정 후 사이트 연결이 실패해요
방금 변경한 URL Rewrite 또는 MITM 호스트를 잠시 되돌려 같은 URL을 다시 테스트하세요. 한 번에 한 항목만 복원하면 원인이 규칙, 인증서, 대상 사이트 중 어디에 가까운지 좁힐 수 있습니다.
안전한 구성 관리의 기준은 작은 변경, 확인 가능한 결과, 빠른 복원입니다. 규칙은 구체적인 항목부터 검토하고, 원격 목록은 갱신 결과와 정책 이름을 함께 확인하세요. HTTPS 캡처는 필요한 호스트에만 한정하며, 테스트가 끝나면 불필요한 인증서 신뢰와 설정을 정리합니다.