Why a remote connection will not establish, and how to tell which layer failed

"It just spins" is the least informative error in remote access, because four completely different failures produce it. They are distinguishable, and the order below narrows it down fast.

First: is the other end actually sharing?

Before touching anything network-shaped, confirm the obvious. The host application must be running on the target computer, and the code you are entering must be the one it is showing right now. Codes are usually per-session — closing and reopening the host gives a new one, and the old one refers to a session that no longer exists.

This is the cause more often than everything below combined, because it produces exactly the same symptom as a genuine network problem. A specific error like "no computer is sharing this code" is telling you the truth: the signalling layer worked fine and there was nothing at the other end.

Second: NAT, and why direct connections often fail

Almost no home computer has a public address. Your router holds one and shares it, rewriting addresses on the way out — that is NAT. It works because every connection is initiated from inside. Nothing on the internet can start a connection to your PC, because from outside your PC does not have an address to start it to.

Remote access tools get around this by having both sides connect outward to a signalling server, then attempting to negotiate a direct path between them — hole punching. It succeeds surprisingly often, and when it fails it fails for reasons you can identify.

• Symmetric NAT. Some routers assign a different outbound port per destination, so the address one side learns is not the address the other side can reach. Hole punching cannot work. Common on corporate gear and some mobile networks.
• Carrier-grade NAT (CGNAT). Your ISP puts thousands of customers behind one public address. Very common on mobile data and increasingly on fixed lines. You are several layers deep and there is nothing to configure at your end.
• Firewalls that block UDP. Direct media paths generally prefer UDP. Networks that permit only TCP on 80 and 443 will not carry it.

This is what a TURN relay is for. When a direct path cannot be negotiated, traffic is relayed through a server instead. It always works, at the cost of extra latency and someone paying for the bandwidth. If a tool connects everywhere but feels slower on one particular network, you are almost certainly being relayed there.

Third: the network you are on

Guest Wi-Fi, hotel networks, university networks and corporate LANs frequently block client-to-client traffic and restrict outbound ports. Two quick tests separate this from everything else:

1. Tether to your phone and try again. If it connects on mobile data and not on the office Wi-Fi, the network is the cause and nothing on either computer needs changing.
2. Try a different pair of endpoints. If a colleague can reach the same host, the host is fine and the problem is on your side.
3. Check whether it is only slow rather than broken. A connection that establishes then drops repeatedly is a different fault from one that never establishes — usually packet loss or an idle timeout on a middlebox, not NAT.

Fourth: the target machine went to sleep

A machine that has suspended is not refusing your connection; it is not there. This is the most common "it worked yesterday" cause, and it looks identical to a network failure from the client side. It is worth ruling out early because the fix is a settings change rather than a debugging session — see preparing a PC to stay reachable.

The order, condensed

More guides