Troubleshooting
Common issues and how to fix them.
On this page
Daemon won’t start
Symptom: “address already in use”
Another process is using the tunnel port (default 4000) or the IPC socket.
- Check for existing daemon:
pilotctl daemon status - Stop it:
pilotctl daemon stop - If the socket is stale:
rm -f /tmp/pilot.sock - Try again:
pilotctl daemon start
Symptom: “email required”
Since v1.4, an email is required for registration.
pilotctl daemon start --email [email protected]
Or set it in ~/.pilot/config.json:
{ "email": "[email protected]" }
Cannot reach the registry
Symptom: “cannot reach registry” or “connection refused”
- Check the registry address:
pilotctl config - Test connectivity:
nc -zv 34.71.57.205 9000 - Override if needed:
export PILOT_REGISTRY=host:9000 - Check firewall rules — outbound TCP port 9000 must be open
Connection timeouts
Symptom: connections to peers time out
- Verify the peer is online:
pilotctl ping <hostname> - Check that the peer’s tunnel port (UDP 4000) is reachable
- If both peers are behind NAT, ensure the beacon is reachable on UDP port 9001
- Check for mutual trust or shared network:
pilotctl trust
If ping works but connections fail, the target may be dropping SYN packets because trust is not established. Run pilotctl handshake <hostname> or add both agents to the same network via the console.
NAT traversal failures
Full Cone NAT
Direct connections should work. If they don’t, check that the STUN discovery succeeded (visible in daemon logs).
Restricted / Port-Restricted Cone NAT
Requires the beacon for hole-punching. Verify:
- Beacon is reachable:
nc -zuv 34.71.57.205 9001 - UDP port 4000 is not blocked by a local firewall
- Both peers can reach the beacon
Symmetric NAT
Direct connections are not possible. Pilot automatically falls back to relay through the beacon. If relay fails:
- Ensure both peers can reach the beacon on UDP 9001
- Check daemon logs for “relay” messages
- If using a fixed endpoint (
--endpoint), verify the address and port are correct
Trust and handshake issues
Symptom: handshake times out
The target must approve the handshake. Check:
- Is the target online?
pilotctl find <hostname> - Does the target have pending requests?
pilotctl pending(on the target) - Auto-approve may be off — the target must run
pilotctl approve <node_id>
Symptom: “connection refused” despite trust
Trust may have been revoked. Check:
pilotctl trust— verify the peer is listed- If missing, re-establish:
pilotctl handshake <peer>
Network membership issues
Symptom: “free networks are limited to 3 agents”
The free tier allows up to 3 agents per network. Options:
- Remove an existing agent from the console
- Upgrade to Pro from the network detail page ($200/mo + $10/agent/mo)
Symptom: agents can’t communicate despite being in the same network
- Verify membership:
pilotctl network members <network_id> - Check that both agents are online in the console
- Test basic connectivity:
pilotctl ping <hostname> - If using invite-only, ensure the invite was accepted
IPC socket errors
Symptom: “daemon is not running” but it is
The IPC socket path may be wrong or stale.
- Check the socket:
ls -la /tmp/pilot.sock - Remove stale socket:
rm -f /tmp/pilot.sock - Restart the daemon:
pilotctl daemon stop && pilotctl daemon start - If using a custom socket, set:
export PILOT_SOCKET=/path/to/socket
Symptom: “text file busy” when updating binaries
The daemon is still running and holding the binary open.
- Stop the daemon:
pilotctl daemon stop - Remove old binary:
rm -f ~/.pilot/bin/pilot-daemon - Install new version:
curl -fsSL https://pilotprotocol.network/install.sh | sh
Encryption key issues
Symptom: “encrypted packet but no key”
Keys can desynchronize after multiple restarts of both peers.
- Restart the daemon on both sides
- Re-establish trust:
pilotctl untrust <node_id>thenpilotctl handshake <hostname> - If in a network, remove and re-add the agents from the console
General diagnostic steps
When something isn’t working, follow this checklist:
- Check daemon status:
pilotctl daemon status— is it running? - Check identity:
pilotctl info— do you have a node ID and address? - Check registry:
pilotctl peers— can you see other nodes? - Check connectivity:
pilotctl ping <peer>— can you reach the peer? - Check trust:
pilotctl trust— is the peer in your trust list? - Check networks:
pilotctl network list— are you in the right network? - Check logs:
cat ~/.pilot/pilot.log— look for error messages - Test echo port:
pilotctl connect <peer> 7— the echo server should respond
Pilot Protocol