Networking & firewall

Your IP address#

Every VPS comes with a public IPv4 address that stays with the server for its lifetime, including across an OS reinstall. 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. Servers in the Chicago region also come with a /64 IPv6 block.

The address is shown on the server's page in the VPS Panel, 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:

bash
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:

bash
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.

Note: Add the rule for SSH before you run ufw enable. If you turn the firewall on while port 22 is still blocked, your current session keeps working but the next login is refused, and you can lock yourself out of the server.

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:

bash
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.

Note: Provider-level networking controls are still being expanded. For now, port and firewall rules live inside the server rather than in a dashboard control, so the commands on this page are the way to manage them.