MITM certificates and HTTPS rewriting
For iPhone / iPad. Ordinary proxy access does not require MITM.
Install and trust
- Open Settings → MITM → MITM Certificates and inspect This Device.
- If no certificate exists, choose Generate Certificate. To share an existing account certificate with another device, use the account-certificate controls instead.
- Choose Install Trust Profile and complete profile installation in iOS Settings.
- Under General → About → Certificate Trust Settings, enable full trust for that root certificate.
- Return to the app, enable MITM as prompted, and check the intended hosts and rules.
Replacing the local certificate requires installing and trusting the new one; an old installed profile will not trust it. Regenerating certificates is not a general fix for connection failures.
Installing the profile and trusting its root are separate steps. See Apple's certificate-trust instructions.
Enable and verify rules
Review imported hosts and scripts. Remote MITM rule sets start disabled. Enable only the required sets and keep host scope narrow. HTTPS module rewriting also needs the master switch, a trusted certificate and active module content.
Connect, reopen the service and inspect request details or MITM diagnostics. An imported rule alone does not prove interception.
| Symptom | Check |
|---|---|
| No match | Host scope and master/set/module switches |
| Certificate error | Installation, full trust and certificate pinning |
| A feature breaks | Disable the relevant set or module and compare |
Pinned applications may reject interception. Do not disable global certificate verification; exclude unsuitable hosts and retain their original TLS connection.
To stop, disable MITM or the relevant set and recreate connections. Remove the profile in system settings if no longer needed. Never share its private key.
Never decrypt a particular domain
For certificate pinning or a service incompatible with rewriting, open Settings → MITM → Never Decrypt, enter the exact hostname, then choose Never Decrypt This Domain. Request details and the MITM Inspector offer the same action.
The exclusion applies to that exact domain on this device, across all TLS ports. Add subdomains separately. Module and subscription updates cannot override it. Reconnect after changing it; existing connections keep their previous behavior. Use Allow MITM for This Domain in the list to restore interception.
Excluded domains retain their original TLS connection. HTTPS rewrites, scripts and HTTP-based routing stop applying, while ordinary routing and plain HTTP rules remain unchanged. Current versions also skip domains with no applicable HTTPS rules automatically. A connection that is not decrypted is not necessarily a certificate failure; inspect its reason first.
Three exclusion scopes
| Setting | Effect on HTTPS decryption |
|---|---|
| A loaded module's hostname exclusion | A match excludes the host from decryption by all modules; native MITM rule sets may still handle it |
| A native MITM rule set's hostname exclusion | Removes only that set; other applicable sets can still participate |
| Device-local Never Decrypt | Prevents all modules and sets from decrypting that exact domain and survives subscription updates |
Use Never Decrypt when the entire device should leave a domain encrypted. An exclusion in one module or native set is not equivalent. Cross-module HTTPS exclusion does not disable plain HTTP rules; plain HTTP still follows each module's own matching and exclusion conditions.
Open Activity → MITM to inspect the domain's decision and matching sources. Compare changes with new connections; exclusion problems do not require repeatedly generating certificates. Module updates may change hosts, so repeat the module verification steps afterwards.
For centralized rule-set updates, see External Resources.