SSH Works on Wi-Fi but Not 5G? Fix IPv6-Only Carrier Issues

If SSH works on Wi-Fi but not 5G, try the server’s hostname instead of its saved IPv4 address. An IPv6-only carrier may need DNS64/NAT64 to reach an IPv4 server. Also check cellular permissions, private addresses, and IP allowlists: this symptom alone does not prove a NAT64 problem.

Why does SSH work on Wi-Fi but not mobile data?

Switching networks changes the route to your server, the DNS resolver, and potentially the source address its firewall sees. Start with a fresh connection, rather than judging an old session that froze during the switch.

In TermAI, turn Wi-Fi fully off, confirm mobile internet works, and check that the phone permits TermAI to use cellular data. Retry the same server, username, port, and key. Record the exact error.

Error timing is a clue, not a diagnosis. A timeout does not prove packets reached the server, and an immediate failure does not prove IPv6-only service. If only mobile data fails, a firewall allowing your home public IP is another possibility. Follow SSH IP allowlists from a phone for that branch.

How do NAT64 and DNS64 affect SSH on 5G?

An IPv6-only access network can still reach IPv4 servers through translation:

Phone asks for the server's hostname
  -> DNS64 supplies a synthesized IPv6 address
  -> phone connects through the carrier's NAT64 gateway
  -> gateway reaches the IPv4 SSH server

DNS64 can synthesize an AAAA answer from an A record when there is no usable AAAA answer under its synthesis rules. NAT64 translates the traffic. The server does not need native IPv6 for this route. DNS64 specification, NAT64 deployment guidance.

A numeric IPv4 destination gives DNS64 no hostname lookup to work with. However, “IPv4 literals never work on IPv6-only networks” is false. The device or app may provide another translation path. Apple documents IPv4-literal synthesis through supported networking APIs; 464XLAT provides IPv4 service across an IPv6 network for IPv4-only applications. Behavior depends on the device, app, and network. Apple’s IPv6 guidance, 464XLAT specification.

That is why using a hostname is a useful first test, but not a guarantee. Neither an iPhone nor an Android label tells you precisely which path this connection uses.

How do I fix a saved SSH connection in TermAI?

For a public IPv4 server, use this controlled comparison:

1. Keep the working saved connection and create a second entry in TermAI.
2. Set its destination to a DNS hostname you control that resolves to the same server. Keep the username, SSH port, and authentication unchanged.
3. If you have no hostname, create an A record with your DNS provider pointing to the server’s public IPv4 address. Do not invent an AAAA record.
4. With Wi-Fi off, open a new connection using the hostname.
5. If it succeeds, reconnect once more and test the SFTP connection to that same host before relying on it for an incident.

Changing from an IP address to a name can trigger a new host-key trust prompt. Compare the fingerprint through your provider console or another trusted record before accepting it. A new name is not evidence of a new server identity.

If your setup uses a bastion, check its destination too: a working hostname for the final server cannot repair an unreachable first hop. Inspect jump-host configuration in the client that owns it; do not assume every desktop OpenSSH option is available in a mobile app.

How can I check whether my carrier uses DNS64?

The most relevant test is the fresh hostname-versus-address attempt in TermAI on cellular. For deeper inspection, use a local diagnostic environment on that connection with DNS tools available:

dig AAAA ipv4only.arpa
dig A ssh.example.com
dig AAAA ssh.example.com

Replace ssh.example.com with your real hostname. An AAAA response for ipv4only.arpa indicates DNS64 synthesis on the queried resolver path. It does not prove that the translated SSH connection succeeds. An empty answer does not rule out other translation mechanisms. The domain is for DNS discovery, not a server to ping or SSH into. RFC 7050.

Do not run these in a remote TermAI shell and call the result a carrier test. That queries from the server’s network. A tethered laptop is a useful comparison, but hotspot addressing and DNS can differ from the phone app’s path. Also, dig may not use the same scoped resolver behavior as an app.

On a laptop with OpenSSH, compare address families:

ssh -vvv -4 [email protected]
ssh -vvv -6 [email protected]

Use your real account and add -p with your configured port if needed. OpenSSH documents -4, -6, and verbose logging in its client manual. These are diagnostic commands for that local client, not TermAI settings. Forcing IPv4 is a test, not a universal fix for IPv6-only access.

Why does SSH still fail when I use a hostname?

Check two DNS traps before changing SSH authentication.

A custom resolver may bypass DNS64. If you enabled private DNS, encrypted DNS, a filtering profile, or a VPN, compare against automatic network DNS where your policy permits. Restore the original setting afterward. This matters when the connection depends on DNS64; it does not mean every custom resolver breaks every mobile network.

Do not blindly replace it with a public DNS64 resolver. Google’s service requires access to a NAT64 gateway using its expected prefix; it cannot create that gateway for you. Do not manually prepend 64:ff9b:: to your server address either: the network may use another prefix. Google Public DNS64 requirements, Apple’s synthesis warning.

A real but broken AAAA record can direct you to broken IPv6. Check whether it points to an assigned, routed server address with SSH permitted. Normal DNS64 behavior does not rescue a destination merely because its published IPv6 service is unreachable. Repair the IPv6 path or correct the erroneous record. DNS64 processing rules.

Keep dual-stack access when you need both families: a server reachable only over IPv6 can have the reverse problem, working on cellular but failing on IPv4-only Wi-Fi.

Can TermAI connect to my home server over 5G?

A destination such as 192.168.1.50 is a private LAN address. Giving it a public hostname does not create a route from the carrier to your house. This requires private-network access, not a different DNS spelling.

TermAI includes Tailscale on iOS and Android, so you can use its built-in connection to your tailnet for SSH and SFTP:

1. While access still works, enroll the server in your tailnet and confirm it is online.
2. Connect TermAI’s built-in Tailscale integration to the appropriate tailnet.
3. Use the server’s tailnet destination in the SSH connection, with its normal account and key.
4. Ensure tailnet policy and the server’s firewall allow that SSH destination and port.
5. Turn Wi-Fi off and test a fresh SSH login and SFTP connection.

Tailscale supports IPv4 and IPv6 underlay connectivity, including relay connections between devices with different available families. That provides an alternative to depending on the public server’s DNS64 route, though it still requires working network access and policy. Tailscale IPv6 support.

Ordinary SSH over Tailscale and the separately enabled Tailscale SSH feature are different. This workflow can use the server’s existing OpenSSH authentication; built-in tailnet access does not imply that you must enable Tailscale’s SSH server. Tailscale SSH documentation.

An overlay address is reachable through the overlay, not simply because it appears in a saved host. Test the private path before removing public access, and keep a recovery route.

What should I check on the SSH server?

Use a working Wi-Fi session or your provider console. On a Linux server, these read-only checks inspect addresses, listeners, and effective SSH configuration:

ip -6 addr show scope global
sudo ss -lntp
sudo sshd -T

Check the intended SSH port in ss output. In the SSH configuration, inspect addressfamily and listenaddress; sshd -T needs connection parameters to evaluate relevant Match conditions fully. The OpenSSH server configuration manual explains these controls.

If adding native IPv6, verify address assignment, routing, the SSH listener, and both host and cloud firewalls before publishing an AAAA record. IPv4 rules do not automatically authorize IPv6 sources in AWS security groups. Allow only the intended sources. AWS security-group rules.

For a NAT64 connection, the IPv4 server sees the translator’s IPv4 source rather than your home address. Do not widen SSH access to an entire carrier as a shortcut; use an approved private route or controlled egress. NAT64 deployment guidance.

In TermAI, ask the AI assistant:

Suggest read-only checks for this Linux server’s SSH listener, IPv6 address, and firewall. Explain what each result would establish. Do not suggest changing rules yet.

TermAI suggests commands and waits for your confirmation before execution. Review the target and command before running it. An unreachable SSH session cannot execute its own repair; start from working access. See mobile SSH production safety.

Why does SSH disconnect when I switch to mobile data?

Failure to establish a new connection and losing an established session are different problems. First confirm a fresh cellular login works.

Keepalives can help detect dead connections, but cannot repair an absent route. Mosh is designed for roaming with compatible clients and server support; it still needs initial SSH access and a working UDP path. It does not replace DNS or routing diagnosis. OpenSSH client manual, Mosh project documentation.

For work in TermAI, start a persistent server-side session if tmux is installed:

tmux new-session -A -s incident

After reconnecting, run it again to attach to the same session. tmux preserves the server-side session through a client disconnect; it does not keep the phone’s network alive. tmux manual.

Before your next on-call shift, test both the direct hostname and private route on cellular. TermAI’s free tier includes unlimited SSH/SFTP and five AI requests daily, so routine reconnection and file checks do not depend on the AI allowance. Save the working setup as part of your phone-only incident-response plan.

What else should I know about SSH on IPv6-only carriers?

Does 5G mean my phone has an IPv6-only connection?

No. The 5G indicator does not reveal the IP configuration. Carrier, APN, roaming, device, and VPN settings can affect the available path. Test the connection rather than assuming NAT64 is responsible.

Can an IPv6-only phone SSH into an IPv4-only VPS?

Yes, when a working NAT64 path and compatible name resolution or device translation are available. A hostname with an A record can work through DNS64 without adding IPv6 to the VPS.

Why does the same SSH address work on Android but fail on iPhone?

Device translation, resolver behavior, app networking code, and VPN routing can differ. 464XLAT can support IPv4-only applications, while Apple also documents API-based address synthesis. The operating system name alone does not identify the cause.

Should I disable IPv6 or change my SSH port?

Neither is a general NAT64 fix. Disabling IPv6 can remove the available network path, and changing a port does not repair DNS or routing. Change a port only when you have established a port-specific problem and have recovery access.

Will TermAI’s AI assistant automatically repair my connection?

No. TermAI suggests commands for you to review and confirm. It cannot run diagnostics on an unreachable server through the failed SSH connection; use an existing working session or your provider’s console first.