A Tailscale connection can use three documented path types: direct, Peer Relay, or DERP relay, according to Tailscale's connection type documentation. That path only connects devices. It does not enable SSH or macOS Screen Sharing.

This week's action: test your remote Mac in this order: device status, macOS service, user permission, access policy, connection path, then restart recovery. If the Mac is your only production environment, keep a separate backup entry point before your next trip.

This guide is for you if you use an iPad or lightweight laptop and can see a remote Mac but cannot open its desktop. It also fits remote developers who need SSH for code, builds, or AI Agent tasks after changing networks. If you are preparing a rented Mac, use the final checklist before importing a production project.

01

The first distinction: Tailscale reachability is not service availability

When the Mac appears in the Tailscale admin view or client, you have confirmed only part of the path. The device has an identity in the tailnet, and the client can report its state. You have not yet confirmed that:

  • The Mac is currently online.
  • macOS is accepting SSH connections.
  • macOS Screen Sharing is enabled.
  • Your macOS user is allowed to log in.
  • Your current Tailscale identity can reach the required service.
  • The address or hostname used by your client points to the intended Mac.

This explains the common hotel failure: you arrive, connect your iPad to Wi-Fi, see the Mac in Tailscale, and still receive a refused connection or a blank desktop. The visible device is not proof that the graphical service is listening.

Tailscale's device connectivity documentation is the right reference for separating device reachability from service troubleshooting. Start there, then move to the Apple settings for the service you actually use.

Do not begin by reinstalling Tailscale. That action changes the client state before you have captured the evidence.

02

A symptom map for the five failure layers

Use the symptom first. Each result points to a different layer.

What you observe Most likely layer Next evidence to collect Do not do yet
The Mac is absent or marked offline Client, host power, sleep, or login state Tailscale device status and host console state Change SSH or Screen Sharing settings
The Mac is visible but SSH is refused macOS Remote Login, user permission, or policy SSH service setting and one minimal login test Blame the relay path
SSH works but the desktop does not open Screen Sharing, graphical session, or desktop permission Screen Sharing setting and allowed-user list Reinstall the Tailscale client
The desktop works but SSH fails Remote Login, shell access, or SSH policy Remote Login setting and target username Expand access to every user
Both services work but the session is slow Direct, Peer Relay, DERP relay, or local network Connection path and a second network comparison Replace the remote desktop software
The Mac disappears after restart Unattended startup, disk unlock, login, or sleep Recovery sequence from a controlled restart Treat Tailscale as the only recovery path

The key decision is simple: a failure before the service test is a network or host-state problem. A failure after the service test is usually a macOS setting, account, or access-control problem.

03

First step: prove the device state

Open the Tailscale client on the device you are carrying. Confirm that your current device is logged in to the expected tailnet. Then inspect the target Mac.

Record these facts:

  1. Is the target listed?
  2. Does its status show online or offline?
  3. Is the reported address the one you are using?
  4. Are you signed in with the expected identity?
  5. Has the device been shared with your account rather than only with another user?

A Tailscale device can be visible to an account without giving that account access to every service on the device. The official device sharing documentation explains the difference between sharing a device and granting unrestricted access across a network.

At this stage, run only a minimum connectivity test. Do not interpret a successful ping-style reachability test as proof that the desktop is available. It proves that the device can be reached at the network layer. The next test must target the actual service.

If the device is offline, stop here and inspect host power, sleep, login, and client startup. Changing access rules cannot revive a Mac that is not connected.

04

Second step: verify the exact macOS service

For a graphical session, verify macOS Screen Sharing on the Mac itself. Apple’s Screen Sharing setup guide covers the setting and the users permitted to connect.

Check:

  • Screen Sharing is enabled.
  • The intended macOS account is in the allowed-user list.
  • The connection method uses the correct Tailscale address or hostname.
  • The account has a usable password.
  • A local policy has not changed after a system update or account change.

For command-line work, verify Remote Login instead. Apple’s Remote Login guide covers the macOS setting and user access. Test with the smallest useful command rather than launching a full development workflow.

A successful SSH login and a failed desktop login mean the Tailscale network path is probably not your first problem. Investigate Screen Sharing permissions, the graphical session, and the desktop client.

A successful desktop login and refused SSH connection point in the opposite direction. Check Remote Login, the username format, and the user allowed for SSH. Do not widen access to all users just to make a travel deadline.

What each test proves

Test result What it confirms What remains unproven
Target Mac appears online The client reports the device as present SSH, Screen Sharing, user access, and policy
Minimal network test succeeds The carrying device can reach the target at a network layer That a service is listening
SSH login succeeds Remote Login and the tested account work The graphical session and Screen Sharing
Screen Sharing login succeeds The graphical service and account work SSH and unattended restart recovery
Both services succeed The two intended entry points work now Recovery after sleep, restart, or disk unlock
Device sharing succeeds The account can see or access the shared device as configured Access to every service or user on that Mac

This separation prevents the most common false conclusion: “Tailscale is broken because the desktop does not open.” Tailscale may be working exactly as configured while macOS Screen Sharing remains disabled.

05

Third step: inspect access policy before changing it

If the device is online and the macOS service is enabled, inspect the access layer.

Confirm that both ends use the expected Tailscale identity. Then check whether the device is shared with the correct person or account. Finally, inspect the rule that permits the target service. Tailscale's grants documentation explains how access rules define who can reach which resources.

Keep the scope narrow:

  • Permit only the users who need access.
  • Permit only the required Mac and service.
  • Avoid opening every service to every tailnet member.
  • Keep one recovery administrator.
  • Remove old travel devices after the trip.
  • Document the identity used by your iPad or lightweight laptop.

A policy change should have a clear before-and-after test. If you cannot state which user, device, and service the rule affects, do not deploy it during an outage.

Travel warning: A shared Mac is not automatically a fully open Mac. Device visibility, service availability, and policy permission are separate checks. Record all three before you import sensitive work.

06

Fourth step: separate direct access from relay access

A connection can succeed and still feel poor. Before replacing your remote desktop client, inspect the connection path. Tailscale documents direct connections, Peer Relay, and DERP relay paths in its connection types reference.

The practical interpretation is:

  • Direct: the devices establish a direct path when network conditions allow it.
  • Peer Relay: another approved device helps carry the connection.
  • DERP relay: Tailscale’s relay path is used when a direct path is unavailable.

Do not invent a universal latency threshold for screen sharing. Responsiveness depends on the work: terminal commands tolerate more delay than visual design, scrolling, or interactive debugging. Use the same action sequence on two networks instead.

The hotel Wi-Fi comparison

Run the following comparison:

  1. Connect through the hotel or café Wi-Fi.
  2. Confirm the Tailscale path.
  3. Open SSH and perform a small command.
  4. Open Screen Sharing and perform the same short desktop task.
  5. Record whether the failure is connection refusal, timeout, login rejection, or sluggish input.
  6. Switch to a personal hotspot.
  7. Repeat the same tests without changing the Mac or access policy.

Interpret the result:

  • If both SSH and the desktop fail on hotel Wi-Fi but work on the hotspot, inspect the local network path and relay behavior.
  • If SSH works on both networks but the desktop is slow only on hotel Wi-Fi, the service is available and the path is the likely bottleneck.
  • If both networks fail, investigate the Mac, service, identity, or policy.
  • If the path is relayed on both networks, changing the remote desktop client may not address the root cause.

Tailscale's poor-performance troubleshooting guide provides the official checks for slow connections. Use its evidence rather than guessing from how the session feels.

07

Why restart recovery deserves its own test

A Mac that works while someone is logged in is not necessarily ready for unattended travel. A restart can expose at least three different states:

  1. Tailscale itself has not connected.
  2. The Mac is waiting for disk unlock or user login.
  3. The Mac is online but has entered sleep.

These states require different recovery actions. Do not describe them all as “Tailscale went offline.”

Tailscale has an official unattended operation guide, but you must verify its current macOS limitations instead of copying unattended settings from another operating system. The important question is not whether a client can run unattended in general. It is whether your exact Mac returns to a usable network and service state without local input.

Run a controlled test before leaving:

  • Save a recovery note outside the Mac.
  • Confirm another device can reach the Mac.
  • Start a planned restart.
  • Check whether the Mac reappears in Tailscale.
  • Test SSH.
  • Test Screen Sharing.
  • Record whether disk unlock or login input is required.
  • Confirm the backup console or second entry point.
  • Stop using the setup as a single-entry system if recovery depends on someone being physically present.

A remote Mac that needs a local unlock after every restart may still be useful. It is not a reliable sole workstation for a multi-country trip.

08

The acceptance checklist before production work

Use this as a pass/fail gate. Do not move a production repository or time-sensitive build workflow until every relevant item is complete.

  • [ ] Confirm the iPad or travel laptop uses the intended Tailscale identity.
  • [ ] Confirm the target Mac appears online from the travel device.
  • [ ] Confirm the target address or hostname belongs to the intended Mac.
  • [ ] Test a minimal network connection.
  • [ ] Enable macOS Remote Login if SSH is required.
  • [ ] Add only the intended macOS user to the Remote Login list.
  • [ ] Enable macOS Screen Sharing if graphical access is required.
  • [ ] Add only the intended graphical user.
  • [ ] Test SSH with the exact production username.
  • [ ] Test Screen Sharing with the exact production account.
  • [ ] Confirm the relevant Tailscale access rule allows the intended device and service.
  • [ ] Check whether the path is direct, Peer Relay, or DERP relay.
  • [ ] Repeat the test on hotel or café Wi-Fi.
  • [ ] Repeat the test through a personal hotspot.
  • [ ] Perform a controlled restart.
  • [ ] Check whether disk unlock or local login is required.
  • [ ] Confirm the backup console or second remote entry point.
  • [ ] Remove old travel devices and unnecessary permissions.
  • [ ] Keep a recovery administrator separate from the daily work account.

If any item fails, classify the failure before fixing it. “Remote access works” is too broad to be useful. Record whether network access, SSH, the graphical session, policy, or restart recovery passed.

09

FAQ: the four failure questions that matter

Why can Tailscale see the Mac but still fail to connect?

A visible Mac confirms device registration and reported network state. It does not confirm that SSH or macOS Screen Sharing is enabled, that your user is allowed, or that the access policy permits the service. Test the target service directly after confirming the device. A refused SSH connection and a failed graphical login require different macOS checks.

Can Tailscale open macOS Screen Sharing by itself?

No. Tailscale supplies the network path between approved devices. macOS Screen Sharing remains a separate service that must be enabled and configured in macOS. You also need an allowed user and the correct Tailscale address. The same rule applies to SSH: network reachability does not automatically activate Remote Login.

Why does a remote Mac appear offline in Tailscale after a restart?

The word “offline” can hide different states. The client may not have started, the Mac may be waiting for disk unlock or login, or the host may be asleep. Check the host through a console or backup entry point. If physical input is required before Tailscale returns, the Mac needs assisted recovery rather than a single unattended travel workflow.

Does a Tailscale relay make remote desktop unusable?

Not automatically. A relay can change responsiveness, but the result depends on the path and the task. Identify whether the connection is direct, Peer Relay, or DERP. Then compare hotel Wi-Fi with a hotspot using the same SSH and desktop actions. If both networks fail, the relay is probably not the first issue to fix.

10

Choosing a single entry point or a backup path

Tailscale is valuable when it gives you a consistent private route to a Mac across changing networks. It is not a complete disaster-recovery plan.

A single Tailscale entry point may be acceptable when:

  • The Mac has passed a restart test.
  • SSH and Screen Sharing both work.
  • No local disk unlock is required during normal recovery.
  • You have tested the setup from more than one travel network.
  • You can reach a host console if the client stays offline.

Use two independent paths when:

  • The Mac is your only production environment.
  • A restart may require local input.
  • You run long builds or scheduled agents.
  • You move between countries and networks frequently.
  • Your work cannot wait for someone at the host location.
  • The graphical and SSH paths depend on the same unverified service state.

For a rented environment, compare the Mac rental plans before committing to a long cycle. The important comparison is not only hardware. Check how you regain access when the private network client is offline.

A short real-work trial is more useful than a theoretical configuration review. Connect from the device you will actually carry. Test code maintenance over SSH, open the graphical session, change networks, and perform the controlled restart. If the setup fails, you want to discover that before the airport transfer, not during a delivery deadline.

You can also review the available remote Mac ordering options and select the access method that fits your recovery plan. Keep the decision neutral: self-managed access can be appropriate for stable, long-running work, while a managed console and independent recovery route matter more when you travel without local support.

11

The practical decision for your next trip

Tailscale should remain one layer in your remote Mac workflow, not the entire workflow. Use it for private device connectivity. Configure SSH and macOS Screen Sharing separately. Test policy permissions separately. Check the relay path when performance changes. Treat restart recovery as a formal acceptance test.

Your current setup has three common weaknesses: Tailscale visibility can create false confidence, a hotel network can expose relay or NAT limitations, and a restart can leave the Mac waiting for local input. A single private-network entry point also gives you no independent way back when the client or host state fails.

If you need a remote Mac for a temporary project, a short travel assignment, or a real-world compatibility test, a VpsMesh environment with a web console plus SSH and graphical access can provide a more recoverable workflow than relying on one self-managed entry path. Test it for a complete workday before moving critical work. If you require permanent heavy workloads, physical peripherals, or guaranteed local access, owning a Mac may still be the better choice.