Diagnose
When the agent can’t bring a tunnel up, devgate diagnose walks the path it takes, as
ngrok diagnose does, and says which step fails:
$ devgate diagnose devgate diagnose · agent 0.22.0
✓ config file ~/.devgate/devgate.yml is valid, 2 endpoint(s)
✓ API DNS dashboard.devgate.online → 162.211.231.174 (9ms)
✓ tunnel server DNS devgate.online → 162.211.231.174 (8ms)
✓ API TLS dashboard.devgate.online:443, TLS 1.3, certificate valid until 3 Dec 2026 (88ms)
✓ authtoken valid, the account of ada (ada@example.com)
✗ tunnel server can't connect to devgate.online:22: i/o timeout — outgoing connections to this port may be blocked
! web inspector 127.0.0.1:4040 is in use (another devgate?) — the inspector takes the next free port, up to 4049
1 check failed. What it checks
| Check | What a failure means |
|---|---|
| config file | The config file doesn’t parse, or an endpoint in it is invalid. No file at all is fine for devgate http. |
| API DNS, tunnel server DNS | The names don’t resolve: your DNS, a VPN or the network is in the way. |
| API TLS | The TLS handshake with the dashboard fails — often a proxy or antivirus that intercepts TLS. |
| authtoken | None is configured, or the API rejects it. Copy a fresh one from the dashboard and run devgate config add-authtoken. |
| tunnel server | The agent can’t reach the tunnel server’s SSH port, or something there answers that isn’t SSH: outgoing port 22 is blocked, or a proxy sits in the way. |
| web inspector | A warning, not a failure: 127.0.0.1:4040 is taken, and the inspector uses the next free port. |
It exits 1 when a check fails, so a script or a CI step can tell. --config <path> checks another
config file; DEVGATE_API and DEVGATE_SSH_HOST are honoured as in every run.
Questions people actually ask
Run devgate diagnose. It checks every step a tunnel takes — the config file, DNS for the API and the tunnel server, TLS to the API, your authtoken, the tunnel server’s SSH port — and says which one fails. A blocked outgoing port 22 or a proxy that intercepts TLS are the usual causes on office and hotel networks.
Yes: it exits 1 when a check fails and 0 when they all pass. A busy 127.0.0.1:4040 is only a warning — the inspector takes the next free port.