HomeLabFix

Tailscale / Troubleshooting

Tailscale Connection Stuck on DERP Relay

The connection works, but DERP persists during poor performance. Compare both peers and network observations before requesting a scoped network-owner investigation.

DERP can add latency and constrain throughput, but the observed path does not prove the only bottleneck. Start with the affected peer pair, then compare their network reports.[3]

Applicability

Products
Tailscale
Scope
For a reachable peer/application with a real latency or throughput complaint and repeated DERP observations during that problem. Excludes connection failure, direct paths, Peer Relay, unreachable subnet targets and a first negotiation response alone. Use the documented CLI on supported peers; unavailable evidence is a handoff, not permission to guess.[1]
Last verified

Symptoms

  • The application responds, while the active peer shows a region-bearing DERP relay entry during the slow episode.[2]

Quick diagnosis

Gather the relevant observations before choosing a branch. Unknown evidence is not proof of a failed component.

Read-only

Read the active peer's path

Run on a participating client after traffic to the intended peer. Match direct, relay "region-code" or peer-relay; a generic relay description is insufficient.[1]

tailscale status
Safe / low risk

Observe path negotiation

Replace <peer> with the intended peer's Tailscale name or address. This sends connectivity probes; the first DERP response can later become direct. Do not assign a fixed timeout or packet count to persistent DERP.[2]

tailscale ping <peer>
Safe / low risk

Collect both peers' network observations

Run where the CLI is available on each peer during the issue. Record UDP, MappingVariesByDestIP, PortMapping and DERP latency/region context. Keep complete outputs private; the site does not need them.[4][3]

tailscale netcheck

Interactive troubleshooter

Your answers stay in this browser tab. The tool does not connect to your systems or send diagnostic results.

Guided check / step 1

Safe diagnostic guidance

Does the intended peer/application connection work?

This diagnosis starts with working access, not a total failure.[1]

Read the complete diagnostic tree without using the controls
  1. Does the intended peer/application connection work?

    This diagnosis starts with working access, not a total failure.[1]

    • Yes, the application is reachable → What path does the active peer actually show?
    • No, or access is not established → This is not a DERP-performance diagnosis
  2. What path does the active peer actually show?

    Read current output for that peer: direct, relay "region-code" / DERP, or peer-relay.[1]

    • Direct → The observed path is direct
    • Peer Relay → Peer Relay is a separate path
    • DERP relay with a region code → Does DERP persist during the actual performance problem?
    • Unknown or generic relay wording only → Establish the missing evidence first
  3. Does DERP persist during the actual performance problem?

    Repeat observations during the symptom, without an invented timer.[2]

    • Yes, DERP keeps appearing while performance is poor → Have you compared both peers and their netcheck reports?
    • It starts on DERP, then becomes direct → Initial DERP is not persistent DERP
    • No poor performance or insufficient observations → Establish the missing evidence first
  4. Have you compared both peers and their netcheck reports?

    Use the quick checks on both sides; retain unknowns if a report is unavailable.[3]

    • Yes, both sides have observations → Does either peer report UDP false?
    • No, a peer or report is unavailable → Establish the missing evidence first
    • Network changes are not permitted → Keep working access and escalate safely
  5. Does either peer report UDP false?

    Identify the reporting side; UDP true alone is not a direct-path guarantee.[4]

    • Yes, at least one peer reports UDP false → Ask the reporting side's network owner to investigate
    • No, both report UDP true → Does either peer report MappingVariesByDestIP true?
    • UDP results are inconclusive → Keep working access and escalate safely
  6. Does either peer report MappingVariesByDestIP true?

    Compare this with both reports, including PortMapping availability.[4]

    • Yes, destination-dependent mapping is observed → A hard-NAT hypothesis needs owner confirmation
    • No, or the combined evidence remains inconclusive → Keep working access and escalate safely
  7. This is not a DERP-performance diagnosis

    Resolve the actual connectivity failure first. No working application path has been established.[1]

  8. The observed path is direct

    Leave this DERP-only workflow and investigate the remaining performance problem separately.[1]

  9. Peer Relay is a separate path

    Use the Peer Relay source in Next actions; do not diagnose it as DERP.[6]

  10. Initial DERP is not persistent DERP

    The observed transition is not evidence of a connection staying on DERP.[2]

  11. Establish the missing evidence first

    Collect only the missing access, path, performance or peer observation. Do not classify unavailable evidence as a network defect.[3]

  12. Ask the reporting side's network owner to investigate

    Outbound UDP was not established by that report. It does not identify an exact firewall rule. Supply both peers' evidence; recheck path and performance after a separately authorized remedy.[4][5]

  13. A hard-NAT hypothesis needs owner confirmation

    This does not establish CGNAT or a specific router configuration. Include PortMapping context, obtain a scoped investigation and compare results after any authorized change.[4]

  14. Keep working access and escalate safely

    No justified universal fix follows. Preserve observations for both network owners; a separate Peer Relay assessment is optional, not a deployment instruction.[5][6]

Detailed diagnosis

Read-only

1. Require sustained DERP evidence

Compare repeated observations during the actual poor-performance episode. A transition to direct is different from staying on DERP; exclude Peer Relay too.[2]

Read-only

2. Compare both peers before blaming one router

Compare each peer's connections with other active peers. An all-relayed side versus a mixed direct/relayed side helps prioritize a network owner, not prove an exact cause.[3]

Read-only

3. Interpret fields together

UDP true means outbound probes reached STUN, not guaranteed peer-to-peer access. UDP false does not identify a firewall rule. MappingVariesByDestIP true supports difficult NAT behavior, not a particular router defect. PortMapping describes available mapping protocols; availability is not a direct-path guarantee.[4]

Read-only

4. Select an authorized investigation

Ask the relevant network owner to assess the observed UDP/NAT conditions against their platform documentation. If the evidence cannot distinguish a side, involve both owners rather than guessing.[5]

Safe / low risk

5. Compare the result after any separate authorized change

HomeLabFix recommends recording both the path and the same application's performance again. An improved path is not proof that every performance limit has disappeared.[3][1]

Supported scenarios

These observations narrow the investigation; they do not establish a unique cause.

UDP reachability needs investigation

An unsuccessful outbound UDP observation makes direct connectivity less likely.[4]

How to check: Compare both reports and identify which peer reported the limitation.[3]

Mapping behavior may impede direct connectivity

Destination-dependent mappings are evidence for a hard-NAT hypothesis, not the exact network configuration.[4]

How to check: Include both peers and port-mapping context in the investigation.[4]

Next actions and procedure boundaries

For an observed Peer Relay path or a separately authorized architecture assessment, use the official Peer Relay documentation. This page does not configure a relay.
Read-only

Request a bounded network-owner assessment

Provide the affected pair, repeated path observations and sanitized network findings. This does not authorize firewall or NAT edits. Router-specific remedies need their own applicability and recovery review.[5]

Read-only

Consider Peer Relay only as a separate architecture review

Where direct access cannot be obtained, an owner may assess dedicated Peer Relay infrastructure. The documented option requires compatible versions, capacity, reachable UDP and policy. This page neither deploys it nor supplies setup commands.[6]

Read-only

Keep the working fallback when a change is not justified

If changes are prohibited or evidence remains inconclusive, preserve access and escalate. HomeLabFix does not prescribe a port-opening experiment to force a result.[5]

Warnings and boundaries

HomeLabFix safety rule: no global firewall disable, blind UPnP enable or universal port-opening fix. Network changes can alter exposure for other devices. Require owner authority, saved configuration, local recovery access and verified vendor-specific rollback before any separate procedure.[5]
DERP output does not establish CGNAT, ISP NAT or a broken firewall. Record carrier NAT only when independently confirmed; otherwise ask the provider or administrator.[1][4]
Peer Relay is not DERP. If that is the observed path, use its separate documentation instead of this diagnosis.[6]

Sources

Links were reviewed on 2026-09-05. Reachability and automated validation do not replace editorial verification of each claim.

  1. Connection types
    Tailscale · Tier A · accessed 2026-09-05
  2. Troubleshoot DERP traffic routing issues
    Tailscale · Tier A · accessed 2026-09-05
  3. Poor performance between tailnet devices
    Tailscale · Tier A · accessed 2026-09-05
  4. Device connectivity
    Tailscale · Tier A · accessed 2026-09-05
  5. Using Tailscale with your firewall
    Tailscale · Tier A · accessed 2026-09-05
  6. Tailscale Peer Relays
    Tailscale · Tier A · accessed 2026-09-05