Networking & firewall

Your IP address#

Every VPS comes with a public IPv4 address that stays with the server for its lifetime. You use that address to reach the box over SSH, and you point any DNS records you own at it so visitors and clients find their way to your services.

The address is shown on the server's page in your VPS dashboard, so you never have to log in to find it. When you are already on the server, the quickest way to read it back is from the shell. Run ip addr to list the network interfaces and the addresses bound to them, or ask an outside service with curl ifconfig.me, which echoes back the public IP it sees you connecting from. The second one is handy when the server sits behind any kind of translation and you want the address the rest of the internet uses.

If you have not connected yet, the SSH steps and your login details are covered in connecting to your VPS.

Pointing a domain at your server#

To serve a website or app from a name rather than a raw IP, add a record at your domain registrar or DNS host that points to your server's public address. For the root of a domain, create an A record whose value is the IPv4 address from the section above. For a subdomain such as app.example.com, create an A record on the app name with the same value.

DNS changes are not instant. A new record usually resolves within a few minutes, but it can take longer to reach everyone depending on the TTL you set. You can check what a name currently resolves to from your own machine with dig or nslookup:

dig +short app.example.com

Firewall and open ports#

Which ports accept connections is decided from inside the server, so you manage it with the firewall that ships with your distribution. On Debian and Ubuntu that is ufw, a friendly front end for the underlying rules. A service is only reachable from the outside if something is listening on its port and the firewall allows traffic through.

A typical starting point is to allow SSH and HTTP, turn the firewall on, and then read back the active rules to confirm what you opened:

ufw allow 22/tcp
ufw allow 80/tcp
ufw enable
ufw status

From there you open whatever your services need. A web server with HTTPS wants port 443/tcp, a game or custom service wants its own port, and you can scope a rule to a single source address when only one machine should reach it, for example ufw allow from 203.0.113.10 to any port 5432 for a database you only connect to from your office.

Checking what is reachable#

When a service will not connect, the question is usually whether it is listening at all and whether the firewall is in the way. To see what your server has open locally, list the listening sockets with ss:

ss -tlnp

That shows every TCP port the server is listening on and the process behind each one. If your service is missing from that list, the problem is the service itself rather than the firewall. If it is present but still unreachable from outside, check that ufw status allows the port, then confirm from another machine that the address resolves and responds.