Twingate reports metadata back from Connectors to provide helpful information into the Connector’s status and the current machine it’s running on. Additionally, this information may help troubleshoot any potential issues.
Uptime & Downtime
Uptime and downtime track how long a Connector has been online or offline respectively. Uptime and downtime reflect the state of the Connector as seen by the Controller, and do not necessarily reflect whether the host machine running the Connector is up. If your Connector has downtime but its machine is running, review our best practices to ensure things are running smoothly.
The time offset represents the time difference between the Connector and the Controller. Negative values means the Connector is in “the past” relative to the Controller and positive values mean the Connector is in “the future”. The Controller tolerates a maximum time offset of +/- 5 seconds.
Connectors with a time difference near these limits may experience intermittent connection issues. For more help troubleshooting any issues arising from time synchronization issues, see this Twingate Knowledge Base article.
If STUN discovery is unavailable, a Connector will be unable to establish a peer-to-peer connection with a Client.
Connectors need to be able to complete STUN discovery in order for peer-to-peer connection to be successful. Twingate uses STUN discovery to determine the public IP address and port of the Connector when it is behind one or more layers of NAT. Twingate Clients can then attempt to use this address to establish a peer-to-peer connection with the Connector.
We report the hostname for the machine running a Connector. This hostname reflects the machine running the Connector and, as an example, may reflect a Docker container’s hostname rather than a physical machine’s.
We report the most recent public IP address that the Controller sees the Connector on. This IP address may change, particularly in setups where a single machine may be routed through different IP addresses.
We report all of the private IP addresses we can see on the machine running the Connector. Keep in mind, this address reflects whatever the machine running the Connector can see and may not reflect all addresses on the machine. For example, Docker containers may report addresses in the
188.8.131.52/16 subnet used for container networking. This does not include the physical machine’s IP address or addresses, which are not visible from the container.
Last updated 18 hours ago