Aliases let you add an extra address to any of your Resources. Aliases are accessible to anyone with access to the Resource and do not take the place of the original address.

For example, consider a router as a Resource. The Resource’s address is 10.0.0.1 and its alias is router.internal. Users can access the router using either the address, 10.0.0.1, or the alias, router.internal.

Aliases are protocol agnostic, meaning that an alias will work with any protocol. Think of an alias as a pseudo-A record for an address that can only be used via Twingate.

Caveats

HTTPS and aliases

Websites that use HTTPS will cause certificate errors when accessed via an alias. As aliases are protocol agnostic, there’s no built-in support for HTTPS. This may lead to confusion when trying to use an alias with a Resource that uses HTTPS.

In order for HTTPS to work with an alias, you must create and register a TLS certificate for the alias. This can either be done by using a domain you control (e.g. aliasing things to a subdomain of your corporate domain) or by creating and distributing a private certificate for your devices.

Host headers

When connecting to an alias via HTTP, the host header will be set to the alias. For example, when connecting to router.internal, your browser will set Host: router.internal. This may impact some setups, like which virtual host a server might return.