Shadowrocket으로 HTTPS 요청 확인하기

이 글의 핵심

Shadowrocket에서 HTTPS 요청을 확인하려면 MitM 인증서를 만들고 기기에서 신뢰하도록 설정한 다음, 테스트할 호스트를 제한적으로 지정해야 합니다. 이 글에서는 본인이 관리하거나 테스트 권한을 받은 도메인만 사용해 인증서 설치, Config 설정, URL Rewrite 작성, 로그 확인 순으로 실습합니다. 인증서 신뢰가 HTTPS 전체를 자동으로 해독한다는 뜻은 아니며, 개인정보와 서비스 정책을 고려해 테스트 범위를 좁히는 것이 중요합니다.

시작 전: HTTPS 복호화와 URL Rewrite의 차이

HTTPS는 기기와 웹사이트 사이의 통신을 암호화합니다. MitM은 테스트 대상 호스트에 대해 Shadowrocket이 중간에서 TLS 연결을 처리하고, 기기에 신뢰된 인증서를 사용해 요청 내용을 살펴볼 수 있도록 하는 기능입니다. 설정은 인증서 생성, 기기의 신뢰 설정, 대상 호스트 지정이 모두 맞아야 동작합니다. 인증서만 설치하거나 호스트만 적는 것으로는 충분하지 않습니다.

URL Rewrite는 요청 URL의 일부를 다른 주소로 바꾸거나 리디렉션하는 규칙입니다. 예를 들어 테스트 도메인의 오래된 경로를 새 경로로 보내는 식으로 확인할 수 있습니다. HTTPS의 경로까지 규칙이 읽어야 한다면 해당 연결에 대한 MitM이 성립해야 할 수 있습니다. URL Rewrite는 웹페이지 본문이나 앱 화면을 임의로 수정하는 기능과는 다릅니다.

인증서 생성 기기 신뢰 설정 호스트 지정 URL 규칙 적용 로그 검증

실습에는 example.com 같은 문서용 도메인을 사용합니다. 실제 환경에서는 본인이 관리하거나 명시적으로 테스트 허가를 받은 호스트만 지정하세요. 다른 사람의 계정, 결제, 로그인 정보를 가로채거나 검사해서는 안 됩니다. 회사나 학교 기기에서는 관리 정책과 테스트 승인을 먼저 확인하세요.

MitM 인증서 만들기와 신뢰 설정

먼저 Shadowrocket에서 인증서를 준비합니다. 메뉴 이름이나 설치 안내는 앱 버전 및 iOS 화면에 따라 다를 수 있으므로 앱 안의 안내를 기준으로 진행하세요. 보통 Settings의 Certificate 관련 항목에서 인증서를 생성하거나 설치 절차를 시작합니다. 인증서를 설치한 뒤에는 iOS 설정에서 해당 루트 인증서를 완전히 신뢰하도록 별도로 승인해야 HTTPS 연결에 사용할 수 있습니다.

인증서 생성

Shadowrocket을 열고 Settings → Certificate로 이동해 앱에 표시되는 인증서 생성 또는 설치 안내를 따르세요. 생성된 인증서와 개인 키는 테스트용으로 안전하게 보관하고, 공개된 위치나 타인과 공유하는 파일에 넣지 마세요.
프로파일 설치

앱의 설치 안내를 따라 인증서를 기기에 추가하세요. iOS가 프로파일 설치 확인을 표시하면 발급자와 인증서 이름을 확인한 뒤 진행합니다. 설치가 끝나도 아직 신뢰가 완료된 것은 아니므로 다음 단계를 확인하세요.
완전 신뢰 켜기

iOS Settings → General → About → Certificate Trust Settings로 이동해 방금 설치한 인증서의 완전 신뢰 옵션을 확인하고 필요한 경우 활성화하세요. 표시되는 인증서 이름이 Shadowrocket에서 만든 인증서와 일치하는지 확인합니다.
설정 확인

Shadowrocket으로 돌아와 인증서 상태가 설치 및 사용 가능한 상태인지 확인하세요. 메뉴에 설치 상태가 표시되지 않거나 인증서가 목록에 없다면, 반복해서 새 인증서를 만들기보다 설치 화면과 iOS 신뢰 설정을 먼저 다시 확인하세요.

3단계

인증서 생성, 기기 설치, 완전 신뢰 설정

1개 호스트부터

테스트 범위를 필요한 도메인으로 제한

2곳 확인

Shadowrocket 인증서 상태와 iOS 신뢰 설정

인증서의 완전 신뢰를 켜면 해당 인증서로 서명된 연결을 기기가 신뢰할 수 있게 됩니다. 따라서 테스트가 끝났거나 인증서가 더 이상 필요하지 않다면 신뢰를 해제하고, 사용하지 않는 인증서 프로파일도 정리하세요. 개인 키가 외부에 노출되었다고 의심되면 해당 인증서를 계속 사용하지 말고 폐기 절차를 확인한 뒤 새 테스트 환경을 준비해야 합니다.

Config에서 MitM 대상 호스트 지정하기

인증서를 신뢰하도록 설정했다면 현재 적용할 Config를 확인하고 MitM 대상 호스트를 최소 범위로 지정합니다. Config의 [MITM] 섹션에는 URL 전체가 아니라 호스트 이름을 넣습니다. 예를 들어 https://api.example.com/v1/items를 테스트한다면 호스트는 api.example.com입니다. 경로, 쿼리 문자열, https:// 접두사는 호스트 항목에 포함하지 않습니다.

[MITM]
hostname = api.example.com

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

위 코드는 문법을 설명하기 위한 예시입니다. 기존 Config에 [MITM] 또는 [URL Rewrite] 섹션이 이미 있다면 같은 이름의 섹션을 무작정 중복해서 추가하지 말고, 현재 파일의 해당 섹션에 필요한 행을 반영하세요. 호스트 패턴의 지원 형식은 앱의 Config 안내를 확인하고, 처음에는 와일드카드보다 테스트 대상 호스트 하나를 명시하는 편이 결과를 판단하기 쉽습니다.

호스트 범위: 실제 요청의 호스트와 설정한 값이 맞는지 확인하세요. 하위 도메인까지 자동으로 포함된다고 가정하지 말고 필요한 호스트를 각각 점검합니다.
라우팅: Home → Global Routing에서 Config를 선택하고, 방금 편집한 Config가 실제로 선택되어 있는지 확인하세요.
기존 설정: 수정 전에 Config를 보관하고, 테스트가 끝나면 추가한 호스트와 규칙을 제거하거나 원래 상태로 되돌리세요.

MitM이 활성화되어도 모든 앱의 HTTPS가 복호화되는 것은 아닙니다. 앱이 인증서 고정(certificate pinning)을 사용하거나 별도의 보안 검증을 수행하면 연결이 실패하거나 내용을 확인할 수 없을 수 있습니다. 이런 제한을 우회하려고 범위를 넓히지 말고, 권한을 받은 테스트용 웹사이트나 개발 환경에서만 재현하세요.

URL Rewrite 규칙 작성과 동작 확인

URL Rewrite 예시는 요청 URL이 정확히 https://api.example.com/old일 때 새 경로로 리디렉션하도록 구성했습니다. 정규식의 점은 \.로 이스케이프해 임의의 문자와 혼동하지 않도록 했고, 끝의 $는 예시 경로 뒤에 다른 문자가 더 붙지 않는 경우를 표현합니다. 규칙 문법과 상태 코드 지원 여부는 Shadowrocket의 현재 Config 안내에 맞춰 확인하세요.

수정 후에는 저장한 Config가 적용 중인지 확인하고, 기존 페이지를 새로고침하는 대신 테스트 URL을 새 요청으로 엽니다. 로그에서 요청 호스트와 원래 경로를 찾고, URL Rewrite 규칙이 매칭되었는지 살펴보세요. 리디렉션이 발생했다면 새 주소로 요청이 이어지는지도 확인합니다. 이미 열려 있던 연결이나 앱 캐시가 결과를 가릴 수 있으므로 필요하면 테스트 페이지를 닫고 새로 요청하세요.

관찰 결과	우선 확인할 항목	다음 조치
인증서 경고 표시	인증서 설치 여부와 완전 신뢰 설정	iOS Certificate Trust Settings에서 인증서 이름과 상태 확인
요청은 보이나 내용 확인 불가	MitM 호스트와 실제 요청 호스트	Config의 `[MITM]` 항목을 최소 범위로 대조
요청은 보이나 리디렉션되지 않음	규칙 형식, URL 일치, 적용 중인 Config	테스트 URL을 단순화하고 로그에서 매칭 결과 확인
연결이 실패함	인증서 고정, 네트워크, 앱의 보안 정책	허가된 테스트 웹 환경에서 재현하고 정책 담당자에게 문의

결론: 인증서보다 먼저 테스트 범위를 고정하세요

처음에는 테스트 도메인 한 개와 URL 규칙 한 줄만 적용하세요. 요청 호스트, Config 적용 상태, 인증서 신뢰 여부를 각각 확인하면 인증서 문제와 규칙 불일치를 구분하기 쉽고, 필요 이상의 HTTPS 검사도 줄일 수 있습니다.

정상적으로 리디렉션된 결과가 보이지 않는다고 곧바로 인증서를 다시 만들 필요는 없습니다. 먼저 실제 요청이 HTTPS인지, Config의 호스트가 요청과 일치하는지, URL Rewrite의 정규식이 전체 URL과 맞는지 확인하세요. 또한 규칙이 특정 경로를 대상으로 한다면 슬래시, 대소문자, 쿼리 문자열이 예시와 다른지 로그를 통해 비교합니다.

개인정보 보호와 자주 묻는 질문

MitM 테스트는 요청 URL, 헤더, 경우에 따라 요청 및 응답 내용처럼 민감할 수 있는 정보를 노출할 수 있습니다. 테스트 계정에는 실제 비밀번호나 결제 수단을 사용하지 말고, 수집된 로그를 공개 저장소나 공유 문서에 그대로 붙여 넣지 마세요. 다른 사람의 통신을 동의 없이 가로채거나 회사·학교의 보안 정책을 우회하는 용도로 사용해서는 안 됩니다.

인증서를 신뢰했는데도 HTTPS 내용이 보이지 않나요?

Home → Global Routing에서 Config가 선택되어 있는지, 해당 Config의 [MITM] 호스트가 실제 요청의 호스트와 일치하는지 확인하세요. 앱의 인증서 고정이나 별도 보안 정책 때문에 검사되지 않을 수도 있습니다.

URL Rewrite만 쓰는데 인증서가 꼭 필요한가요?

일반적으로 HTTPS URL의 경로까지 검사하거나 변경하려면 해당 연결을 MitM으로 처리해야 할 수 있습니다. 먼저 테스트 URL과 현재 Config에서 규칙이 매칭되는지 확인하고, 인증서 요구 여부는 Shadowrocket의 해당 기능 안내를 기준으로 판단하세요.

테스트가 끝난 뒤 무엇을 정리해야 하나요?

Config에서 테스트용 [MITM] 호스트와 URL Rewrite 행을 제거하거나 원상 복구하고, 더 이상 사용하지 않을 인증서는 iOS의 프로파일 및 Certificate Trust Settings에서 정리하세요. 보관 중인 개인 키도 안전한 위치에 두세요.

모든 앱의 HTTPS 요청을 확인할 수 있나요?

아니요. 인증서 고정, 앱의 보안 구현, 네트워크 상태, 대상 호스트 설정 등에 따라 확인할 수 없는 요청이 있습니다. 제한을 무력화하려 하지 말고 권한이 있는 테스트 환경과 공개된 개발자 문서 안에서 확인하세요.

실습 목적이 달성되면 테스트 규칙을 그대로 일상 설정에 남겨 두지 마세요. 필요한 연결 정보와 Config는 사용자가 이미 보유한 자료를 기준으로 관리하고, 인증서 신뢰 범위와 로그 보관 기간을 최소화하는 것이 안전합니다.