How to reach a home server from outside your network

The short answer

There are four ways to reach something running at home. They are not equally safe, and which ones are open to you depends on your broadband.

For most home set‑ups the sensible combination is a WireGuard VPN for anything administrative, plus a reverse proxy with HTTPS for the one or two apps other people or devices must reach without a VPN.

1. Check whether your broadband accepts incoming connections

Port forwarding only works if your router has a real public IPv4 address. Many UK full‑fibre “altnets” and almost all 4G/5G home broadband share one address between many customers using carrier‑grade NAT (CGNAT). Behind CGNAT, nothing you set on your own router can make a port reachable from the internet over IPv4.

1. Open your router’s status page and find its WAN, Internet or Broadband IPv4 address.
2. Compare it with the address shown on ip.uk.app. The CGNAT check does the comparison for you.
3. If they match, you have a public address and can carry on. If the router shows something in 100.64.0.0–100.127.255.255, you are behind CGNAT. If it shows 192.168.x.x, 10.x.x.x or 172.16–31.x.x, there is another router in front of yours – that’s a double NAT, which you can fix yourself.

Behind CGNAT your options are: ask the provider for a public IPv4 address (several sell one for a few pounds a month), use IPv6 if they give you that, or use a VPN or tunnel that connects outwards. The CGNAT guide covers each.

2. Decide who needs to connect

Only you and your household, on devices you control? Use a VPN. Your phone connects to home first and then sees everything as if it were on the sofa – the NAS, Home Assistant, the Proxmox console – with nothing else exposed. The Home Assistant and Jellyfin phone apps work fine over a VPN.

Other people, smart TVs, or cloud services? Friends watching your Jellyfin library, a smart TV app that can’t run a VPN, Google or Alexa talking to Home Assistant, a webhook from another service: these need a public HTTPS address. Put a reverse proxy in front and forward only port 443 (and 80 if your certificate method needs it).

3. Decide what you are exposing – and what you never should

Anything reachable from the internet gets probed within minutes of the port opening. That’s normal and not a reason to panic, but it does mean some things should never face the internet directly:

• Admin panels: your router’s web page, Proxmox (port 8006), a NAS admin page, Portainer, database consoles. Use the VPN. See the Proxmox guide.
• DNS on port 53. An open DNS resolver gets abused for attacks on other people. See the Pi‑hole guide for the safe way to use it away from home.
• Remote desktop (RDP 3389, VNC 5900) and file sharing (SMB 445). These are favourite targets.
• SSH on port 22 with passwords. If you must, use keys only – or, better, the VPN.

Apps built to be used from outside – Home Assistant, Jellyfin, Nextcloud, Plex – are fine behind a reverse proxy with HTTPS, as long as you keep them updated and use strong passwords, ideally with two‑factor sign‑in.

4. Give your home a name that follows your IP address

Most UK home broadband addresses are dynamic. They often stay the same for weeks, then change after a hub restart or line fault. Dynamic DNS keeps a name pointing at whatever your current address is.

With a uk.app name the pattern that causes fewest problems is:

1. Register yourname.uk.app and create a DDNS token for it (My names → your name → Dynamic DNS).
2. Run one updater at home that keeps home.yourname.uk.app pointing at your public IP. It can be your router, NAS, Home Assistant or any always‑on Linux box.
3. Point every service name at that one: add ha, jellyfin, cloud as CNAME records to home.yourname.uk.app, or add a single wildcard * CNAME. When your IP changes, one update moves them all.

The update endpoint uses the common dyndns2 protocol:

Server:    ddns.uk.app  (HTTPS, path /nic/update)
Username:  yourname.uk.app
Password:  your DDNS token (not your account password)
Hostname:  home.yourname.uk.app

On any Linux machine, the simplest updater is a cron job. Put the token in a file only root can read:

sudo install -m 600 /dev/null /root/.ukapp-ddns
echo 'user = "yourname.uk.app:YOUR_DDNS_TOKEN"' | sudo tee /root/.ukapp-ddns >/dev/null

# every 5 minutes; answers "good <ip>" when it changed, "nochg <ip>" when it didn't
echo '*/5 * * * * root curl -fsS -K /root/.ukapp-ddns "https://ddns.uk.app/nic/update?hostname=home.yourname.uk.app" >/dev/null' | sudo tee /etc/cron.d/ukapp-ddns

If you leave out myip=, the service records the address your request came from, which is what you want when the updater runs at home. Don’t run it on a machine whose traffic goes out through a commercial VPN, or it will publish the VPN’s address. Router‑specific and app‑specific updaters are covered in each guide, and uk.app’s dynamic DNS page lists the responses.

5. HTTPS is not optional on a .app name

Every .app name is on the browser HSTS preload list. Chrome, Edge, Firefox and Safari will only ever connect to https:// for it, and there is no “proceed anyway” button for a bad certificate. So http://jellyfin.yourname.uk.app:8096 simply won’t open in a browser – you need a valid certificate for each name you use.

The tidy way is one reverse proxy (Caddy, Nginx Proxy Manager or the one built into your NAS) that holds the certificates and forwards each name to the right app inside your network. The HTTPS guide shows both the automatic method and a single wildcard certificate via DNS‑01.

6. Before you open anything

• Update the app and the operating system underneath it, and turn on automatic updates where the app supports them.
• Use a long, unique password for every account that can sign in from outside, and turn on two‑factor authentication where the app offers it (Home Assistant, Nextcloud, Synology and Proxmox all do).
• Turn on login throttling or IP banning if the app has it, and keep an eye on its login log for the first few days.
• Reserve a fixed LAN address for the server in your router’s DHCP settings, so the port forward doesn’t break when the server gets a new address.
• Have a backup you can restore without the server itself.

7. Check it from outside

1. Does the name point home? Look up home.yourname.uk.app with the DNS lookup and compare the A record with the address on ip.uk.app. After a change, the propagation checker shows which resolvers still have the old one.
2. Is the port open from the internet? Run the open port checker against port 443. “Open” means your router forwards it and something answers. “Closed” or “timed out” means the forward, the device’s own firewall or CGNAT is in the way.
3. Is the certificate right? The SSL checker shows whether the certificate covers the exact name, who issued it and when it expires.
4. Test from outside for real. Turn Wi‑Fi off on your phone and open the address over mobile data. Testing from inside your own network can give misleading results.