# Mac SSH “No route to host”: check the app, network and port

If SSH fails to reach a device on your Mac's local network, compare the same address and port in Apple Terminal and the failing app. On macOS 15 or later, check that app's Local Network permission. A successful ping alone does not prove that TCP port 22, SSH authentication or an SFTP session will work.

By Nexus Shell · Published September 18, 2026. For Mac users connecting to a NAS, Raspberry Pi, Linux server or homelab. The symptom picker suggests the next check; it does not scan your network, inspect permissions or ask for a host, password or key.

## Start with the exact error

- No route to host: check the route and network access. When only one app fails to reach an on-link device, also check macOS Local Network permission and restart that app after saving work.
- Operation timed out: the connection did not complete in time. Check the address, port, VPN route and filtering. It does not prove the password is wrong.
- Connection refused: the TCP connection was actively rejected. Check whether SSH is listening on the intended port; a rejecting firewall can also produce this result.
- Could not resolve hostname: check the hostname or configured SSH alias first. A hostname and a saved connection label are not necessarily the same thing.
- Permission denied (publickey): an SSH server answered and authentication failed. Check the account and key selection; Local Network permission is not the first explanation for that connection.
- REMOTE HOST IDENTIFICATION HAS CHANGED: stop and verify the server's fingerprint through a trusted channel before changing saved trust. Do not disable host-key verification to suppress the message.

## 1. Compare the same destination in Apple Terminal

Open Terminal on the Mac itself. Use the same server address, SSH port, account and required jump host as your app. These examples use a documentation-only address: replace it with a server you are authorized to access. Do not run them in an already connected remote terminal.

```sh
# Inspect the route to your server without changing it (macOS)
route -n get 192.0.2.10

# Check one TCP port, with a five-second connection timeout (macOS nc)
nc -vz -G 5 192.0.2.10 22

# Try SSH with diagnostic output; this can open a login session
ssh -v -o ConnectTimeout=5 -p 22 -l developer 192.0.2.10
```

The route output identifies the selected interface and gateway; it does not prove delivery. A successful nc result means that one TCP connection completed, not that SSH or your credentials are valid. SSH -v shows how far the attempt reached. If login succeeds, type exit to close that test session. Verify any first-use host fingerprint before accepting it.

For a configured alias, inspect its effective settings locally before comparing it with the app:

```sh
ssh -G your-configured-alias
```

Check hostname, user, port and proxyjump in that output. OpenSSH prints the evaluated configuration and exits; it does not open an SSH session. Your own configuration can include Match exec commands, so use only a configuration you trust. A direct nc probe is not equivalent to a connection through a bastion or proxy.

## 2. If Terminal works but your SSH app does not

First check that both attempts use the same destination, port and network path. If they differ, fix the comparison before diagnosing an app permission. For an on-link LAN target on macOS 15 or later, open System Settings → Privacy & Security → Local Network and review the failing app's access. Allow access only if you intend that app to communicate with local devices, then reconnect.

Apple documents different treatment for command-line tools launched from Terminal and for app-owned processes. A successful Terminal connection therefore does not establish that another app has the required permission. The [Apple Local Network settings guide](https://support.apple.com/guide/mac-help/control-access-to-your-local-network-on-mac-mchla4f49138/mac) shows where to review it; [Technote TN3179](https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy) explains the platform behavior.

If the app was updated while running, save work, end sensitive sessions deliberately, quit the whole app and reopen it. Opening another tab is not the same as restarting the process. Retest the same connection. This is a diagnostic step, not a guarantee that an update caused the failure.

A [September 9 user report](https://projectinsomnia.com/blog/no-route-to-host-but-ping-works/) describes LAN connections recovering after restarting an app updated by Homebrew. That is an independent report, not our reproduction of its macOS internals or proof that every “No route” error has that cause.

## 3. If the app is missing from Local Network settings

Use the current signed app, launch the intended installed copy, and attempt the local connection once. Review any permission prompt and retry after your decision. Apple notes that an app normally appears after attempting local network access; multiple installed versions can complicate the settings display.

For Nexus Shell, update using the official installer or Homebrew and fully quit and reopen the app. Its connection setup includes an in-process local-network access attempt for recognized local target forms. That helps request OS permission; it cannot grant permission, repair a router or override an administrator's policy. If the app remains absent, contact support with the app/macOS versions and the exact error, without credentials.

## 4. If both clients fail, check the network path

Confirm the current address and SSH port from the device or provider console. A NAS web interface working on HTTPS does not imply that its SSH service is enabled. A sleeping host, stale DHCP address, guest Wi-Fi isolation, different VLAN or changed VPN route can prevent access. Check those facts before changing sshd configuration.

Compare hostname versus the confirmed address to narrow a name-resolution problem. Inspect the selected route on the Mac. For a private host reached through a VPN or jump server, follow that service's access instructions. A private-looking address by itself does not prove that the destination is on your local link or that the macOS Local Network setting is the relevant control.

If the port is refused, inspect the SSH service and its listen port through an authorized console. If it times out, inspect the route and relevant firewall rules. Keep an existing administrative session open while investigating. Avoid broad firewall resets, opening SSH to the whole internet or changing unrelated permissions as a first step.

## 5. Once the server answers, handle the next layer

An authentication error is progress through the network layer, but not a successful login. Compare the SSH account, configured key and authentication requirements. A key passphrase unlocks a local key; it is not necessarily the server account's password. Do not send either credential or a private key to a support thread.

If SSH login succeeds but a file upload fails, investigate the SFTP subsystem, target path and file permissions. A GUI client uses the remote account's rights; it does not automatically elevate an SFTP session with sudo. Follow the [remote file editing workflow](https://nexusshell.app/en/guides/edit-remote-file-macos-sftp/) for permission and conflict checks.

If a forwarded database port is listening but the service still fails, use the [SSH tunnel address and verification guide](https://nexusshell.app/en/tools/ssh-tunnel-command-builder/). Local listening, destination reachability and database authentication are separate checks.

## Keep the working connection in Nexus Shell

After confirming the host, port and account, save that connection in Nexus Shell and verify its host fingerprint. Open a terminal and confirm you reached the intended server before starting file or Docker work. The app keeps those tasks in one native Mac workspace; changing clients does not bypass network or server policy.

Nexus Shell requires Apple Silicon and macOS 14.2+. Personal, non-commercial SSH use has a free tier. SFTP, Docker management and monitoring are Pro features; commercial use requires Pro. See [current pricing and trial terms](https://nexusshell.app/en/#pricing). The Local Network permission steps above apply to macOS 15 or later, not every supported macOS version.

## What to include when asking for help

Record the macOS and app versions, the exact error, whether the target is on the same LAN or reached through a VPN/bastion, and whether Apple Terminal succeeds with matching settings. Include whether the app was updated while open. Redact hostnames, IP addresses, usernames and local paths before sharing logs, and never include passwords or private keys.

This guide was checked against Apple documentation, OpenSSH documentation and Nexus Shell connection-setup code on September 18, 2026. It is not a claim of a fresh end-to-end test on your Mac, NAS or router. The [OpenSSH client manual](https://man.openbsd.org/ssh.1) documents the diagnostic flags used here. Consult man nc and man route on your Mac for its installed command versions.