SSL Interception
WePROXA intercepts HTTPS traffic only for rules you explicitly enable. After installing the CA certificate, you can target interception in two ways:
- Host rules — match a hostname such as
api.example.comor a wildcard such as*.example.com - App rules — match the exact client application name shown in the Apps source view
This keeps inspection focused and lets you choose whether to decrypt traffic by destination, by app, or both.
Why Targeted SSL Rules?
Section titled “Why Targeted SSL Rules?”Instead of blindly decrypting all HTTPS traffic, WePROXA lets you choose exactly what to inspect. This gives you:
- Better performance — only decrypt the traffic you care about
- Less noise — your request list stays focused on relevant hosts
- More control — easily toggle interception on/off per host or per app
Add a Host Rule
Section titled “Add a Host Rule”There are two ways to enable SSL interception for a host:
- Click the lock icon (Certificate) in the toolbar
- Type a hostname in the input field (e.g.,
api.example.com) - Press Enter or click the + button
- The host is added and SSL interception is enabled immediately
You can also use wildcard patterns like *.example.com to match all subdomains.
- Find a request in the request list from the host you want to inspect
- Right-click the request to open the context menu
- Click Enable SSL for {host}
- SSL interception is enabled immediately for that host
This is the quickest way to enable SSL for a host you’re already seeing traffic from.
Add an App Rule
Section titled “Add an App Rule”Use an app rule when you want to inspect HTTPS traffic from one specific client app, even if it talks to many different hosts.
- Switch the sidebar to the Source View.
- Expand Apps and find the client application you want to inspect.
- Right-click the app and choose Enable SSL for {app}.
- Traffic from that app is now eligible for HTTPS inspection and also appears under SSL Enabled Apps.
App rules match the exact app name shown in the sidebar. They do not support wildcard patterns.
TLS Passthrough Hosts
Section titled “TLS Passthrough Hosts”Use TLS passthrough when an app-wide SSL rule is useful, but certain domains should stay tunneled instead of decrypted. This is common for certificate-pinned hosts, identity providers, or services where you only need connection visibility.
- Open Settings.
- Go to Proxy Status.
- Add hosts under TLS passthrough hosts, one per line or separated by commas.
- Leave the field or press Cmd/Ctrl + Enter to save.
Bare domains include their subdomains: example.com matches example.com and api.example.com. Wildcards such as *.example.org are also accepted. Passthrough applies to app-wide SSL interception; an explicit host SSL rule still decrypts that host.
SSL Manager Window
Section titled “SSL Manager Window”For longer rule lists, open the standalone SSL Manager window from the certificate menu. The SSL Manager gives you a larger workspace for the same host and app interception rules.
From the SSL Manager you can:
- Add host rules such as
api.example.comor*.example.com. - Add app rules by application name or bundle identifier.
- Search across configured hosts and apps.
- Filter the list to All, Host, or App rules.
- Toggle or remove individual rules.
- Open certificate installation settings from the title bar.
The SSL Manager uses the same saved SSL rules as the toolbar certificate menu, so changes appear immediately across open windows.
Managing SSL Rules
Section titled “Managing SSL Rules”Open the Certificate Menu (lock icon in the toolbar) to see all your configured SSL rules. From here you can:
- Toggle a host or app rule on/off using the checkbox
- Remove a host or app rule by clicking the trash icon
- Add new host rules using the input field
- Open SSL Manager when you want search, filters, or a larger detached window
To disable SSL for a host via the context menu, right-click a request from that host and select Disable SSL for {host}.
To disable an app rule, right-click the app again in the Apps source view and choose Disable SSL for {app}.
The Certificate Menu labels each rule as Host or App, and all SSL rules persist automatically between sessions.
Where SSL Rules Appear in the Sidebar
Section titled “Where SSL Rules Appear in the Sidebar”- SSL — hosts with SSL interception enabled
- SSL Enabled Apps — apps with SSL interception enabled, grouped as app → host → path
- Apps — all detected client applications, whether SSL is enabled or not
Prerequisites
Section titled “Prerequisites”Before SSL interception can work, you must install and trust the WePROXA Root CA certificate. See Certificate Trust for instructions.
Troubleshooting
Section titled “Troubleshooting”HTTPS requests show as CONNECT tunnels
Section titled “HTTPS requests show as CONNECT tunnels”No matching host or app SSL rule is enabled. Add the host, enable SSL for the client app, or both.
Certificate errors after enabling SSL
Section titled “Certificate errors after enabling SSL”Make sure the WePROXA Root CA is installed and trusted in your macOS Keychain. See Certificate Trust.
Wildcard patterns
Section titled “Wildcard patterns”Use *.example.com to match all subdomains (e.g., api.example.com, cdn.example.com). The exact host example.com itself is not matched by a wildcard — add it separately if needed. Wildcards only apply to host rules, not app rules.
App rule does not match anything
Section titled “App rule does not match anything”Some traffic may not expose a stable client name and can appear under Unknown in the Apps source view. In that case, use a host rule instead.