Connection diagnostics

Diagnose a localhost tunnel that is ready but cannot connect

Separate local-service, authentication, relay, DNS and public-endpoint failures with Proxlane doctor, profile status, and a redacted support bundle.

Written and reviewed by: ProxlaneOperated by CloudruUpdated: 2026-10-03

First check

Local service

Main command

proxlane doctor

Support

Redacted diagnostic bundle

Before you start

Record the target and error

Note the protocol, local host and port, profile name if used, and error code. Keep credentials and private request bodies out of copied reports.

Review setup and authentication

Step by step

01
Check the local service first
Start the app and use its actual listening port. For HTTP, open http://127.0.0.1:3000 on the same computer. A public tunnel can be created while that local app is stopped.
```
proxlane doctor http 3000
```
02
Check authentication and relay access
Run the general doctor and inspect its result per stage. If authentication needs renewal, run proxlane login. Do not repeatedly change the local port when the failure is at authentication or relay access.
```
proxlane doctor
proxlane version
```
03
Inspect the background profile
For a named profile such as web, check runtime, local diagnosis, and recent logs. Foreground tunnels do not appear as background profiles.
```
proxlane service status --profile web
proxlane service doctor --profile web
proxlane service logs -n 40
```
04
Test the public address and collect evidence
Open the exact public HTTP URL from another network, or use the right TCP/UDP application and public port. If the issue remains, generate a support bundle and review it before contacting Support.
```
proxlane support bundle --profile web
```

Understand connection refused

A local connection refused usually means no process is listening at the selected host and port. A Docker container, WSL instance, or another LAN machine may require a different reachable target. Confirm the address from the environment running the CLI, then specify that host explicitly.

proxlane doctor tcp 192.168.1.20:25565
proxlane tcp --host 192.168.1.20 25565

Separate HTTP status and routing failures

A 404 may mean the application path or method is wrong. A 401 may be endpoint authentication. A blocked safety log can identify an IP, country, or abuse policy denial. Inspect the matching request and local application logs instead of assuming every non-200 response means the tunnel failed. For custom domains, check both Dashboard ownership verification and current DNS routing.

proxlane doctor domain app.example.com

Do not treat UDP as a TCP health check

A TCP check can connect to a listening target. UDP is connectionless: startup confirms the target address is ready for packets, not that the application responds. Test with the intended UDP client, verify its public port, and confirm the plan includes UDP. Minecraft Java uses TCP 25565; Bedrock uses UDP 19132.

Troubleshooting

Plan or quota denies publication

Check active tunnel count, transfer quota, and whether UDP or reservations require an upgrade. Stopping an old profile may release an active-tunnel slot; it does not reset monthly transfer.

Fixed hostname or port is rejected

Reserve it with the same account in Dashboard → Endpoints. For custom domains, finish ownership and routing verification before restarting.

Only another machine's app fails

127.0.0.1 refers to the machine running the agent. Use an address that the agent can reach and check the target machine's firewall and listening interface.

Frequently asked questions

Does ready mean the application is healthy?

It means the tunnel reached a runtime state. Review the local check and test the public endpoint separately to confirm the application responds as expected.

Is every value in a support bundle safe to publish?

Built-in token and protection-secret values are redacted, but diagnostic context can still identify local services. Review the bundle and share only what Support needs.

Proxlane