Shadowrocket MitM Setup: HTTPS Decryption and URL Rewrite Guide

Shadowrocket’s MitM feature can decrypt HTTPS traffic for selected hostnames when the device trusts Shadowrocket’s local certificate authority and the traffic passes through the app. This makes it possible to inspect requests during authorized testing and apply URL Rewrite rules to specific URLs. It does not decrypt every connection automatically: certificate trust, hostname scope, routing, and the destination app’s TLS behavior all matter. The steps below use reserved example domains and assume you are testing a site, device, or app that you own or are explicitly authorized to assess.

1. What MitM can—and cannot—do

HTTPS normally encrypts traffic between an app and a website. With MitM enabled for a hostname, Shadowrocket can act as an inspection point: it establishes a connection to the destination, presents a certificate signed by its local CA to the device, and makes request details available for inspection when the device accepts that certificate. This is a deliberate change to the device’s trust boundary, not simply a way to view ordinary traffic logs.

Three conditions must line up. First, Shadowrocket’s CA certificate must be installed and explicitly trusted by the operating system. Second, the destination hostname must be included in the MitM scope. Third, the request must be routed through Shadowrocket in a way that allows it to handle the connection. A connected VPN indicator alone does not prove that HTTPS decryption is working.

MitM cannot make every application inspectable. An app may use certificate pinning, a custom trust store, or other TLS checks that reject the locally issued certificate even when the device trusts it. Some traffic may also use a different hostname than the one you expected. Treat a failed interception as a signal to check scope and app behavior—not as a reason to weaken security checks or expand the hostname list indiscriminately.

• Use a controlled target: Test with a hostname and app that you own or have permission to inspect. The examples below use www.example.test, a reserved example hostname, and are not real connection details.
• Limit the scope: Add only the exact hostnames needed for the test. Avoid broad wildcard entries unless you understand every subdomain they cover.
• Plan cleanup: When testing ends, disable MitM, remove its hostname entries, and remove or stop trusting the local CA certificate if it is no longer needed.

2. Prepare and trust the local CA certificate

Start with a note of your current configuration and routing mode so you can restore them after testing. In Shadowrocket, open Settings → MitM and look for the certificate-generation or certificate-management control. The wording can differ across app and system releases, so use the control shown in your installed version rather than relying on an old screenshot. Generate the local CA certificate if one is not already available, then follow Shadowrocket’s prompt to install the profile.

Installing a certificate profile and trusting it for TLS are separate steps. After installation, open the device’s system settings and find Certificate Trust Settings, commonly under Settings → General → About. Enable full trust for the Shadowrocket certificate and confirm the system prompt. If that trust switch is absent, check whether the profile was installed successfully and whether your device’s operating-system version presents the trust control elsewhere.

1. Record your setup

   In Home, note the active configuration and Global Routing choice. Keep a copy of any configuration you plan to edit, and record the MitM state before changing it.

2. Generate the CA

   Open Settings → MitM and use the certificate-generation option shown there. If a certificate already exists, check its status before generating another one.

3. Install the profile

   Follow Shadowrocket’s on-screen instructions to install the certificate profile in system settings. Return to the app only after the system confirms installation.

4. Enable full trust

   Open the system’s Certificate Trust Settings, locate the Shadowrocket CA, enable trust, and approve the confirmation prompt. Do not enable trust for an unrelated certificate.

5. Restrict hostnames

   Return to Settings → MitM. Enable MitM and enter only the hostname or hostnames required for your authorized test, such as www.example.test.

Keep the CA private. A trusted certificate authority can affect how the device evaluates certificates, so do not export it for other people, install it on devices outside the test, or leave it trusted without a continuing need. If a managed device hides certificate controls or prevents profile changes, follow the organization’s policy and ask its administrator instead of trying to bypass the restriction.

3. Add a narrowly scoped URL Rewrite rule

Before editing, confirm that you are working in the configuration selected for use. In Home, set Global Routing → Config if you want traffic to follow that configuration’s rules, then open Config and make a backup. Preserve existing [Rule], [Host], and other settings. Add or edit the relevant section rather than replacing the complete configuration with a short test file.

The example below illustrates a redirect-style rewrite for one exact HTTPS path. The host is reserved for examples; replace it only with a hostname and path that you control or are authorized to test. Keep the rewrite specific while debugging, because a broad regular expression can alter unrelated requests.

[MITM]
hostname = www.example.test

[URL Rewrite]
URL-REWRITE,^https:\/\/www\.example\.test\/old$,https:\/\/www.example.test\/new,302

In this example, the MitM hostname entry scopes certificate handling to www.example.test. The URL Rewrite expression matches the exact old path, and the replacement points to the new path with a 302 redirect. In Shadowrocket’s configuration syntax, the rule fields are comma-separated; escape characters in the regular expression matter. Check the syntax accepted by the configuration you are editing, and do not paste these example values as if they were real service settings.

Save the configuration and verify that the edited file is the one selected for use. If your existing configuration already has a [MITM] or [URL Rewrite] section, add the test entry to that section rather than creating a duplicate. Keep the rewrite disabled or remove it when the test is over; a redirect rule can change what an app receives even if the connection itself is healthy.

4. Verify inspection and rewrite in stages

Test one request at a time. Use a browser or test app that you control, request the exact hostname and path in the example, and then open Shadowrocket’s traffic or request log. Look for the target hostname and the request path. Depending on the app version and request, log labels and available fields may vary; the important distinction is whether you can see the HTTPS request details, not merely that a connection entry appeared.

1. Check routing: Confirm the intended configuration is active and the request is being handled by Shadowrocket. If necessary, temporarily test with a known working connection that you already have, then restore your usual routing mode.
2. Check the certificate stage: With the test request open, confirm that the device accepts the certificate and that the request is not failing with a certificate warning. A hostname visible in a basic connection log does not by itself prove successful decryption.
3. Check the hostname scope: Compare the actual hostname in the request with the entry under Settings → MitM. A page may load assets from additional hostnames; each should be assessed individually and added only if needed and authorized.
4. Check the rewrite: Request the exact old path and inspect whether the client receives or follows the expected redirect to the new path. If decryption works but the URL is unchanged, review the expression, commas, escaping, section placement, and active configuration.
5. Repeat without the rule: Temporarily remove or disable the rewrite and repeat the same request. This separates a rule-matching problem from a TLS or routing problem.

A successful redirect is not the same as a successful application workflow. The app may cache a response, use a second API hostname, reject a changed response, or follow the redirect to a location outside your MitM scope. Clear only the relevant test state when appropriate, repeat the same request, and record which hostname and path were involved. Do not infer that every request from the app is decrypted because one request was visible.

5. Troubleshoot common failures safely

Use the symptom to choose the next check. Avoid adding every hostname, generating repeated certificates, or changing unrelated TLS options before you have a reproducible test. The table separates common causes from useful checks.

Certificate pinning deserves particular care. An app that compares the server certificate or public key with a value embedded in the app may reject Shadowrocket’s locally issued certificate. That is a security control, not necessarily a Shadowrocket configuration mistake. Do not attempt to defeat pinning in an app or service you do not own or have explicit authorization to test. For an app under your control, use a designated test build or an approved debugging approach.

Also consider whether the request is using a hostname you did not list, or whether the device is reaching the destination by a route that does not pass through the expected configuration. Check the actual request and active settings before expanding scope. If the issue only happens on one network, compare the same test on another network you are permitted to use while keeping the hostname and configuration unchanged.

6. FAQ and cleanup

Before finishing, confirm that the test rule is removed or disabled and that your configuration is back to its intended state. Keep only the records needed for your authorized test, and avoid capturing credentials, personal messages, or unrelated traffic. HTTPS inspection can expose sensitive request data, so narrow scope and prompt cleanup are part of using the feature responsibly—not optional extras.