Tailscale Configuration

Chute includes native Tailscale networking. Once configured, you can reference the built-in policy TAILSCALE from rules or policy groups to send traffic over your tailnet — reach other devices in the tailnet, route out through an exit node, or access subnets advertised by peers.

Unlike ordinary proxy protocols, Tailscale is not a per-line policy defined in [Proxy]; it is configured through a single globally unique [Tailscale] section. It registers the node with the control server using an auth key, with no interactive browser login required.

Tailscale Section

A [Tailscale] section defines everything a device needs to join a tailnet:

[Tailscale]
auth-key = tskey-auth-xxxxxxxxxxxx
control-server = https://controlplane.tailscale.com
hostname = my-device
exit-node = 100.101.102.103
accept-routes = true
force-derp = false

Note: only one [Tailscale] section is allowed in the entire configuration file. A duplicate [Tailscale] section is treated as a configuration error. This is because the Tailscale engine is heavyweight and tailnet address ranges are mutually exclusive — only one tailnet can be joined at a time.

Parameters

Boolean values accept the following spellings (case-insensitive): true/false, 1/0, yes/no, on/off.

Note: unknown keys are ignored with a warning (they do not block configuration loading). A misspelled key (e.g. force-derp written as force_derp) will silently disable that option — please verify against the table above.

The TAILSCALE Built-in Policy

Once the [Tailscale] section is configured, the built-in policy identifier TAILSCALE becomes available — it sits alongside DIRECT and REJECT and can be referenced directly in rules and policy groups. When the [Tailscale] section is not configured, or when Tailscale is turned off, rules referencing TAILSCALE fall back to REJECT (fail-closed).

[Proxy Group]
Mesh = select, TAILSCALE, DIRECT

[Rule]
IP-CIDR,100.64.0.0/10,TAILSCALE,no-resolve
FINAL,DIRECT

Automatic Routing

When Tailscale is enabled, Chute automatically injects the following three rules ahead of all your rules, so you usually do not need to hand-write rules for reaching the tailnet:

DOMAIN-SUFFIX,ts.net,TAILSCALE
IP-CIDR,100.64.0.0/10,TAILSCALE,no-resolve
IP-CIDR6,fd7a:115c:a1e0::/48,TAILSCALE,no-resolve

These injected rules are runtime-only and never modify your configuration file. When accept-routes = true is set, the subnets advertised by peers are also auto-injected as corresponding IP-CIDR / IP-CIDR6 rules and updated automatically as peers add or withdraw subnets.

Usage

Reaching devices in the tailnet

Once the [Tailscale] section is configured, reaching other devices in the tailnet needs no extra rules — the injected rules already cover the tailnet ranges and the MagicDNS suffix. You can address peers directly by MagicDNS name or tailnet IP:

[Tailscale]
auth-key = tskey-auth-xxxxxxxxxxxx
hostname = my-iphone

[Rule]
FINAL,DIRECT

Targets such as my-pc.<tailnet>.ts.net or 100.101.102.103 will now go over Tailscale automatically.

Routing out through an exit node

Set TAILSCALE as the FINAL target to send all traffic that doesn't match a more specific rule out through the exit node:

[Tailscale]
auth-key = tskey-auth-xxxxxxxxxxxx
exit-node = 100.101.102.103

[Rule]
FINAL,TAILSCALE

Note: Setting exit-node alone does not route any traffic through it — you must also add a rule that sends traffic to TAILSCALE (for example FINAL,TAILSCALE). Without such a rule the exit node is configured but unused; the app's configuration editor flags this.

Accepting subnet routes

When a device in the tailnet acts as a subnet router and advertises local subnets, enable accept-routes = true to reach those subnets; the corresponding routing rules are injected automatically:

[Tailscale]
auth-key = tskey-auth-xxxxxxxxxxxx
accept-routes = true

Custom Control Server (Headscale)

In addition to the official control plane, Chute also supports self-hosted Headscale / Ionscale control servers. Just fill in the corresponding URL:

[Tailscale]
auth-key = your-headscale-preauth-key
control-server = https://headscale.example.com
hostname = my-device

Third-party control servers do not enforce the tskey- prefix and accept their own auth keys. Using an http:// cleartext address is recommended only on a trusted network (e.g. a locally self-hosted Headscale).

Known Limitations and Best Practices

The Tailscale implementation focuses on the capabilities most commonly used in proxy scenarios; some official-client features are not yet supported. Please note the following behavioral differences:

1. Use force-derp = true only as a troubleshooting option. Chute normally prefers direct UDP connections (disco hole-punching), which usually provide lower latency and better throughput than a DERP relay. If direct connections are consistently unstable or slower than DERP on a particular network, compare both modes and enable force-derp only for that environment.

2. Only auth-key login is supported. SSO / interactive browser login, Tailscale SSH, Taildrop, and Funnel / serve are not supported. Chute also cannot advertise local subnet routes or offer this device as an exit node; it joins only as a consumer.

3. Ordinary DNS remains local when using an exit node. Chute does not send ordinary DNS resolution through the selected exit node. MagicDNS names are resolved locally from the tailnet map. Global resolvers and remote split-DNS resolvers are not supported; use an IP address when a private name can only be resolved on the remote network.

4. MagicDNS supports A / AAAA records only. Global Resolvers, split-DNS routes (entries with dedicated resolvers), and non-address ExtraRecords (TXT / CNAME / SRV) are ignored; a warning is logged when detected.

5. The direct path's inner MTU is fixed at 1280. There is no path MTU discovery; this conservative value avoids black holes on PPPoE / stacked-tunnel links. The DERP relay path is unaffected.

6. Tailnet Lock (network lock) is not supported. In a tailnet that has network lock enabled, this node's key will not be signed, and locked peers will silently drop traffic from this device.

7. Mullvad exit and other source-rewrite scenarios are unavailable. Exit-node features that require rewriting the local source address are not yet implemented.

8. Recovery after a network change depends on a system notification. When switching Wi-Fi / cellular, Chute rebuilds connections promptly; in the rare case the network-change notification is not received, recovery falls back to an approximately 3-minute watchdog reconnect.