Inspect traffic
Failed requests and tunnels
Understand failed requests and encrypted tunnels in Cloak Proxy. What each error message means, what the app receives, and how to decrypt a tunnel.
Not every row in the traffic list is a finished request and response. Some requests fail before a response arrives: the host doesn’t exist, the server doesn’t answer, or a rule stops them. Others are tunnels: HTTPS connections Cloak Proxy passed through without decrypting, so it only knows where they went. This page shows how to recognize both and what to do about them.
Recognize a failed request
Section titled “Recognize a failed request”A failed request is marked in four places:
| Where | What you see |
|---|---|
| Status icon column | An orange triangle. Hover it to read the error. |
| Code column | ERR in red |
| Inspector header | Failed in red, and the error on an orange line underneath |
| Response pane | No response and the error |
A request to a host that doesn't exist.
- The error, in full. It's selectable.
- Failed instead of a status code
- No response, with the same error
The request side still works: you can read its headers, body and Summary, copy it as code, and repeat it once the problem is fixed.
Error messages
Section titled “Error messages”| Message | What happened | What to try |
|---|---|---|
DNS lookup for host failed: … |
The host name doesn’t resolve. Cloak Proxy checks names before connecting, so this fails at once rather than after a timeout. | Check the spelling, your VPN and network. If you meant to redirect the host, check your DNS Spoofing rules. |
Timed out connecting to host |
The server didn’t accept the connection | Check that the server is up and reachable, and your external proxy settings if you use one. |
Timed out waiting for a response from host |
Connected, but no response came back in time | The server is slow or stuck. Check Network Conditions isn’t adding delay. |
The request to host took longer than 5 minutes |
The response didn’t finish within Cloak Proxy’s 5-minute limit | Long downloads and streams can hit this. |
Could not reach host: … |
Another error talking to the server, such as a TLS certificate the server presented that isn’t trusted | For a test server with a self-signed certificate, add its host to the insecureUpstreamHosts setting with update_settings (see Control API). |
Could not connect to host:port: … |
A tunnel or WebSocket couldn’t open a connection to the server | As above: check the host, port and network. |
Couldn't load the client certificate … |
A client certificate for mutual TLS couldn’t be read | Check the .p12 file and its password under Client certificates (mutual TLS) in Settings › Certificate. |
Blocked by “rule” |
A Block List rule set to drop the connection matched | Turn off or change the rule. |
Dropped by Network Conditions (profile) |
Network Conditions simulated packet loss | Expected while the profile has packet loss. Lower the profile’s packet loss or turn the rule off. |
Aborted at the request breakpoint / Aborted at the response breakpoint |
You chose to abort a request paused at a breakpoint | Expected. |
TLS handshake with the client failed. The client probably doesn't trust the Cloak Proxy CA, or it pins certificates. |
The app refused Cloak Proxy’s certificate. It appears on a CONNECT row. |
See When an app won’t accept decryption. |
Script errors from Scripting rules also fail the request, with the script’s error as the message.
What the app receives
Section titled “What the app receives”What your app sees depends on why the request failed:
- The server couldn’t be reached (DNS, timeouts, connection and TLS errors): Cloak Proxy answers the app with
502 Bad Gateway. The body is the error message as plain text, and the response has the headerX-Cloak-Proxy-Error: 1, so you can tell it apart from a real 502 from your server. - A rule dropped it (Block List set to drop, Network Conditions packet loss, an aborted breakpoint): Cloak Proxy closes the connection without a response, the way a network failure looks to the app.
A Block List rule set to answer with 403 Forbidden isn’t a failure: the request completes with that response and the Block List badge.
Recognize a tunnel
Section titled “Recognize a tunnel”When an app opens an HTTPS connection and SSL Proxying isn’t on for that host or app, Cloak Proxy relays the encrypted bytes without reading them. The traffic list shows one row for the whole connection:
| Column | Shows |
|---|---|
| Status icon | A gray lock |
| Method | CONNECT, in gray |
| Code | Empty |
| Host | The host the app connected to |
| Path | Encrypted tunnel, or Connecting… while the connection opens |
| Duration, Size | Empty |
One tunnel can carry many requests, and Cloak Proxy can’t see how many. In the sidebar, the tunnel counts as one request for its app and domain.
Decrypt a tunnel
Section titled “Decrypt a tunnel”Select the tunnel and the inspector explains what happened and offers to decrypt it.
An encrypted tunnel, with one click to decrypt the host or the whole app.
- A CONNECT tunnel
- Decrypt this host only
- Decrypt everything this app sends
-
Make sure the Cloak Proxy certificate is trusted. Until it is, the buttons are unavailable and the inspector says Trust the Cloak Proxy certificate first (banner above). See Certificate.
-
Select the tunnel in the traffic list.
-
Click Enable only host to decrypt this host, or Enable all domains from app to decrypt everything the app sends.
Cloak Proxy closes the app’s open tunnels to that host (or from that app) so it reconnects. The inspector shows SSL Proxying is on. New requests will be decrypted.
-
Use the app again. New requests appear as separate, readable rows with a green open lock.
You can also turn on SSL Proxying from the right-click menu in the traffic list or the sidebar, or in Settings › SSL Proxying. Wildcards and the full rules are in SSL Proxying.
The old tunnel row stays in the list. Tunnels have no request to work with, so Repeat, Edit and Repeat…, Save to API Client, Tools and Copy as code don’t apply to them.
When a tunnel fails
Section titled “When a tunnel fails”If Cloak Proxy can’t open the connection to the server, the tunnel row fails like a request: an orange triangle, ERR, and in the inspector Couldn’t open a connection to host with the error, for example Could not connect to host:443: ….
When an app won’t accept decryption
Section titled “When an app won’t accept decryption”Some apps refuse Cloak Proxy’s certificate, either because the certificate isn’t trusted where the app runs (a phone, a simulator, a Java or Node runtime with its own certificate store) or because the app pins the certificate it expects. The handshake fails and Cloak Proxy records a failed CONNECT row that starts with TLS handshake with the client failed.
- The certificate isn’t trusted where the app runs. Install and trust it on that device or runtime. See Devices and Terminal and runtimes.
- The app pins its certificate. It won’t accept any certificate but its own, so it can’t be decrypted. Turn off SSL Proxying for that host or app so it works normally again.
For apps captured through DNS (see Apps that ignore the proxy), Cloak Proxy handles pinning for you: after a failed handshake it passes that host through without decrypting it from then on, and the message ends with Cloak Proxy now passes host through without decrypting it, so the app keeps working.
More fixes are in Troubleshooting.