VPS Networking Fundamentals: IPs, DNS, Ports, and Troubleshooting

Understanding how your VPS connects to the internet is foundational to everything else you do with it. Every time a user visits your website, sends an email through your server, or you SSH in to run a command, networking makes it happen. Yet networking is often treated as a black box — something that either works or doesn't, with no middle ground of understanding.

This guide covers the networking fundamentals every VPS administrator needs: how IP addresses work, how DNS translates domain names to server addresses, what ports are and how to control them, and how to troubleshoot the most common networking problems. By the end, you'll understand the full path a request takes from a user's browser to your VPS and back, and you'll know how to fix it when that path breaks.

MassiveGRID Ubuntu VPS includes: Ubuntu 24.04 LTS pre-installed · Proxmox HA cluster with automatic failover · Ceph 3x replicated NVMe storage · Independent CPU/RAM/storage scaling · 12 Tbps DDoS protection · 4 global datacenter locations · 100% uptime SLA · 24/7 human support rated 9.5/10

Deploy a self-managed VPS — from $1.99/mo
Need dedicated resources? — from $19.80/mo
Want fully managed hosting? — we handle everything

Your VPS on the Internet

When you deploy a MassiveGRID Cloud VPS, you receive a public IPv4 address from one of 4 datacenter locations: New York, London, Frankfurt, or Singapore. This public IP is your server's unique address on the internet — every packet destined for your server is routed to this address by the global network of routers that form the internet's backbone.

Here's what happens when someone visits your website:

1. The user types example.com in their browser
2. Their computer queries DNS to translate example.com into your VPS's IP address (e.g., 203.0.113.50)
3. The browser opens a TCP connection to 203.0.113.50 on port 443 (HTTPS)
4. The request travels through multiple routers across the internet to reach MassiveGRID's network
5. MassiveGRID's network routes the packet to your specific VPS
6. Nginx (or your web server) receives the request and sends back the response
7. The response travels the reverse path back to the user's browser

Every troubleshooting task comes down to identifying where in this chain something broke.

IPv4 Addresses: Finding and Understanding Yours

Your VPS has at least one public IPv4 address. On a MassiveGRID VPS, this is a static address — it doesn't change unless you explicitly request a new one. This is different from home internet connections where your ISP may assign a dynamic IP that changes periodically.

Finding Your IP Address

# Method 1: Show all network interfaces and their IPs
ip addr show

# Method 2: Show just the IP addresses
hostname -I

# Method 3: Find your public IP (queries an external service)
curl -s ifconfig.me
# or
curl -s icanhazip.com

# Method 4: Show the default route and interface
ip route show default

The ip addr show output looks like this:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP
    link/ether 52:54:00:ab:cd:ef brd ff:ff:ff:ff:ff:ff
    inet 203.0.113.50/24 brd 203.0.113.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2001:db8::1/64 scope global
       valid_lft forever preferred_lft forever

Key details:

• eth0 — the network interface name (may also be ens3, ens18, or similar)
• inet 203.0.113.50/24 — your IPv4 address and subnet mask
• /24 — means the first 24 bits are the network portion (subnet mask 255.255.255.0)
• inet6 — your IPv6 address (if assigned)
• state UP — the interface is active

Static vs Dynamic IP on a VPS

VPS providers assign static IPs. Your IP address persists as long as you have the VPS. This is essential for hosting because DNS records point to a specific IP — if it changed, your site would go down until DNS propagated to the new address.

The network configuration on Ubuntu 24.04 uses Netplan. You generally don't need to modify it on a VPS (the provider configures it), but you can view it:

# View network configuration
cat /etc/netplan/*.yaml

# Example output:
network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
      # or static:
      # addresses: [203.0.113.50/24]
      # gateway4: 203.0.113.1
      # nameservers:
      #   addresses: [8.8.8.8, 8.8.4.4]

DNS Fundamentals: How Domains Reach Your VPS

DNS (Domain Name System) translates human-readable domain names into IP addresses. When you point a domain to your VPS, you're creating DNS records that tell the internet "when someone asks for example.com, send them to 203.0.113.50."

DNS Record Types

How DNS Resolution Works

When a user's browser needs to resolve example.com:

1. Browser checks its local cache
2. OS checks its local DNS cache
3. OS queries the configured DNS resolver (e.g., your ISP's DNS or 8.8.8.8)
4. The resolver queries the root nameservers → "Who handles .com?"
5. The resolver queries the .com TLD nameservers → "Who handles example.com?"
6. The resolver queries the authoritative nameserver for example.com → "What's the A record?"
7. The answer (203.0.113.50) flows back through the chain and is cached at each level

This process takes milliseconds and the result is cached according to the TTL (Time To Live) set on the DNS record — typically 300 to 3600 seconds.

Pointing a Domain to Your VPS

Here's the step-by-step process to make your domain resolve to your VPS.

Step 1: Find Your VPS IP Address

curl -s ifconfig.me

Step 2: Configure DNS Records at Your Domain Registrar

Log into your domain registrar (Cloudflare, Namecheap, GoDaddy, etc.) and add these DNS records:

The @ symbol represents the root domain (example.com). The www record handles www.example.com. You can also use a CNAME for www:

Step 3: Configure Nginx to Respond to the Domain

# /etc/nginx/sites-available/example.com
server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/example.com/public;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

# Enable the site
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

For a complete Nginx setup including SSL certificates, follow our LEMP stack guide.

Step 4: Verify DNS Propagation

# Check if DNS is resolving to your IP
dig example.com +short

# Check from a specific DNS server
dig @8.8.8.8 example.com +short

# Detailed DNS query
dig example.com ANY

# Check all record types
dig example.com A
dig example.com AAAA
dig example.com MX
dig example.com TXT
dig example.com NS

DNS propagation can take anywhere from a few minutes to 48 hours, depending on TTL values and caching. In practice, with a low TTL (300 seconds), most resolvers pick up changes within 5-15 minutes.

Ports and Services

A port is a number (1-65535) that identifies a specific service on your server. Your VPS has one IP address, but it can run dozens of services simultaneously because each one listens on a different port.

Common Port Numbers

Checking What's Listening

# Show all listening ports and which process owns them
sudo ss -tlnp

# Example output:
# State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
# LISTEN  0       511     0.0.0.0:80          0.0.0.0:*          users:(("nginx",pid=1234))
# LISTEN  0       511     0.0.0.0:443         0.0.0.0:*          users:(("nginx",pid=1234))
# LISTEN  0       128     0.0.0.0:22          0.0.0.0:*          users:(("sshd",pid=567))
# LISTEN  0       70      127.0.0.1:3306      0.0.0.0:*          users:(("mysqld",pid=890))

Key things to notice:

• 0.0.0.0:80 — listening on all interfaces (accessible from the internet)
• 127.0.0.1:3306 — listening only on localhost (not accessible from the internet, which is correct for MySQL)
• The process name and PID tell you what's using each port

Controlling Ports with UFW

UFW (Uncomplicated Firewall) controls which ports accept incoming connections. If a port isn't allowed through UFW, external connections to it are silently dropped. For advanced configurations, see our UFW firewall guide.

# Check current UFW status
sudo ufw status verbose

# Allow a port
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Allow a port only from a specific IP
sudo ufw allow from 198.51.100.5 to any port 3306

# Deny a port explicitly
sudo ufw deny 8080/tcp

# Delete a rule
sudo ufw delete allow 8080/tcp

# Show numbered rules (useful for deletion)
sudo ufw status numbered

Troubleshooting: "I Can't Connect to My VPS via SSH"

This is the most common networking issue. Work through these steps in order.

Step 1: Verify the IP Address

# Confirm you're using the right IP
# Check your MassiveGRID dashboard for the assigned IP

# Try pinging the server (ICMP may be blocked, so don't panic if this fails)
ping -c 4 203.0.113.50

Step 2: Check if SSH Port is Reachable

# Test if port 22 is open (from your local machine)
nc -zv 203.0.113.50 22
# or
telnet 203.0.113.50 22

# Expected success output:
# Connection to 203.0.113.50 22 port [tcp/ssh] succeeded!

If the port is unreachable:

• UFW might be blocking SSH — if you're locked out, use the VPS provider's console/VNC access to fix UFW rules
• SSH might be listening on a non-standard port — check with the provider's console access
• The server might be powered off or the network interface is down

Step 3: Check SSH Client Configuration

# Try connecting with verbose output to see what's happening
ssh -vvv root@203.0.113.50

# Check if your SSH key is being offered
ssh -vvv root@203.0.113.50 2>&1 | grep "Offering"

# Try with a specific key
ssh -i ~/.ssh/id_ed25519 root@203.0.113.50

# Try with password authentication explicitly
ssh -o PubkeyAuthentication=no root@203.0.113.50

Step 4: Common SSH Errors and Fixes

"Permission denied (publickey)" — Your SSH key isn't accepted. Either the wrong key is being offered, the key isn't in ~/.ssh/authorized_keys on the server, or the file permissions are wrong.

"Connection refused" — SSH isn't running, is on a different port, or UFW is blocking it.

"Connection timed out" — The server is unreachable. Network issue, wrong IP, or server is down.

"Host key verification failed" — The server's host key changed (after a reinstall). Fix by removing the old key:

ssh-keygen -R 203.0.113.50

Troubleshooting: "My Website Isn't Loading"

When your website won't load in a browser, the problem is somewhere in the chain: DNS, network, firewall, web server, or application.

Step 1: Check DNS Resolution

# Does the domain resolve to the correct IP?
dig example.com +short

# If it returns the wrong IP or no IP, the problem is DNS
# If it returns the correct IP, DNS is working — the problem is downstream

Step 2: Check if the Web Server Port is Reachable

# Test from your local machine
curl -v http://203.0.113.50
curl -v https://example.com

# Test with just headers (faster)
curl -I http://example.com

Step 3: Check on the Server Itself

# Is Nginx running?
sudo systemctl status nginx

# Is Nginx listening on port 80/443?
sudo ss -tlnp | grep nginx

# Is UFW allowing HTTP/HTTPS?
sudo ufw status | grep -E "80|443"

# Test Nginx locally (bypasses external networking)
curl -v http://localhost

Step 4: Check Nginx Error Log

# Recent errors
sudo tail -30 /var/log/nginx/error.log

# Common findings:
# "connect() failed" — backend (PHP-FPM) is down
# "permission denied" — file ownership/permissions wrong
# "no such file or directory" — wrong document root path

For comprehensive Nginx troubleshooting, see our server logs troubleshooting guide.

Troubleshooting: "DNS Isn't Working"

DNS problems are tricky because of caching. A record can be "correct" at your registrar but still show the old value to users whose resolvers have cached the previous answer.

Step 1: Check What DNS Currently Returns

# Query multiple DNS servers to see if they agree
dig @8.8.8.8 example.com +short       # Google DNS
dig @1.1.1.1 example.com +short       # Cloudflare DNS
dig @9.9.9.9 example.com +short       # Quad9 DNS

# Check your local resolver
dig example.com +short

# If the results differ, propagation is still in progress

Step 2: Check Authoritative Nameservers

# Find the authoritative nameservers for your domain
dig example.com NS +short

# Query the authoritative nameserver directly (bypasses caching)
dig @ns1.dnsprovider.com example.com +short

# If the authoritative NS returns the correct IP but resolvers don't,
# wait for TTL to expire (or reduce TTL before making changes)

Step 3: Check TTL

# See the TTL of the current record
dig example.com A

# Look for the number in the ANSWER SECTION:
# example.com.     300     IN      A       203.0.113.50
#                  ^^^
#                  TTL in seconds (300 = 5 minutes)

Pro tip: Before making DNS changes, reduce the TTL to 300 seconds (5 minutes) and wait for the old TTL to expire. Then make your changes. This minimizes the window where users see stale DNS data.

Step 4: Flush Local DNS Cache

# Linux
sudo systemd-resolve --flush-caches
# or
sudo resolvectl flush-caches

# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

# Windows
ipconfig /flushdns

Private vs Public Networking

Your VPS has at least one public interface that faces the internet. Some providers also offer private networking — a network interface that can only communicate with other VPS instances in the same datacenter.

Public network — Accessible from the internet. Used for serving websites, SSH access, and any service that external users need to reach. Traffic is metered toward your bandwidth allocation.

Private network — Only accessible between your VPS instances in the same datacenter. Used for database connections between app and database servers, internal API communication, and backup replication. Private network traffic is typically unmetered and faster (lower latency, no internet routing).

# Check if you have a private network interface
ip addr show

# Private IPs are typically in these ranges:
# 10.0.0.0/8
# 172.16.0.0/12
# 192.168.0.0/16

Best practice: If your application server and database are on separate VPS instances in the same datacenter, connect them over the private network. Configure MySQL to listen on the private IP instead of localhost:

# In /etc/mysql/mysql.conf.d/mysqld.cnf
bind-address = 10.0.0.5  # Private IP of the database VPS

# Then configure UFW to allow MySQL only from the app server's private IP
sudo ufw allow from 10.0.0.10 to any port 3306

For more on PostgreSQL networking, see our PostgreSQL installation guide.

Bandwidth and Data Transfer

Bandwidth is the maximum rate of data transfer (measured in Mbps or Gbps). Data transfer is the total amount of data moved (measured in GB or TB per month). Your VPS plan includes a data transfer allocation.

Monitoring Bandwidth Usage

# Install vnstat for traffic monitoring
sudo apt install vnstat -y

# View current month's usage
vnstat

# View daily usage
vnstat -d

# View hourly usage for today
vnstat -h

# View live transfer rates
vnstat -l

Example vnstat output:

Database updated: 2026-02-28 14:00:00

   eth0 since 2026-02-01

          rx:  45.62 GiB      tx:  123.87 GiB      total:  169.49 GiB

   monthly
                     rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
      2026-02         45.62 GiB |  123.87 GiB |  169.49 GiB |   1.20 Mbit/s
     ------------------------+-------------+-------------+---------------

If your application is bandwidth-intensive, dedicated resources include dedicated network bandwidth without contention.

Reducing Bandwidth Usage

• Enable gzip/brotli compression in Nginx for text-based responses
• Set proper cache headers for static files so returning visitors don't re-download them
• Use a CDN for static assets to offload bandwidth from your VPS
• Optimize images before serving them (WebP format, proper sizing)

# Enable gzip in Nginx (/etc/nginx/nginx.conf)
http {
    gzip on;
    gzip_vary on;
    gzip_min_length 256;
    gzip_types
        text/plain
        text/css
        text/javascript
        application/javascript
        application/json
        application/xml
        image/svg+xml;
}

Choosing Your Datacenter Location

Your datacenter location affects latency — the time it takes for a packet to travel between the user and your server. Lower latency means faster page loads and more responsive applications.

MassiveGRID offers 4 datacenter locations:

Choose the location closest to the majority of your users. If your users are globally distributed, choose the location closest to your largest user segment and consider using a CDN for static content.

Test latency to each location from your target audience's region:

# Test latency from your local machine
ping -c 10 nyc-server-ip
ping -c 10 london-server-ip
ping -c 10 frankfurt-server-ip
ping -c 10 singapore-server-ip

Network Diagnostic Tools

Every VPS administrator should know these tools. They're pre-installed on Ubuntu or available via apt.

ping — Test Basic Connectivity

# Is the server reachable?
ping -c 5 203.0.113.50

# Ping a domain (also tests DNS resolution)
ping -c 5 example.com

# Continuous ping (useful for monitoring during changes)
ping 203.0.113.50

Note: Some servers block ICMP (ping) for security. A failed ping doesn't necessarily mean the server is down — try connecting to a known-open port instead.

traceroute — Trace the Network Path

# Install traceroute
sudo apt install traceroute -y

# Trace the path to your server
traceroute 203.0.113.50

# Use TCP instead of UDP (more likely to succeed through firewalls)
sudo traceroute -T 203.0.113.50

# Alternative: mtr (combines ping and traceroute)
sudo apt install mtr -y
mtr 203.0.113.50

Traceroute shows every router (hop) between you and the destination. High latency or packet loss at a specific hop indicates a network problem at that point. If the problem is in the middle of the path (not the first or last hop), it's likely an upstream ISP issue that you can't fix directly.

dig and nslookup — DNS Queries

# Query A records
dig example.com A +short

# Query all record types
dig example.com ANY

# Query a specific DNS server
dig @8.8.8.8 example.com

# Reverse DNS lookup (IP to hostname)
dig -x 203.0.113.50

# nslookup (older, simpler)
nslookup example.com
nslookup example.com 8.8.8.8  # Query specific DNS server

ss — Socket Statistics (Replaces netstat)

# Show all listening TCP ports
sudo ss -tlnp

# Show all established connections
sudo ss -tnp

# Show listening and established UDP sockets
sudo ss -ulnp

# Show connections to a specific port
sudo ss -tnp | grep :443

# Count connections per state
sudo ss -s

# Show connections from a specific IP
sudo ss -tnp | grep 198.51.100.5

curl — Test HTTP Connections

# Test a URL and show headers
curl -I https://example.com

# Test with verbose output (shows TLS handshake, headers, etc.)
curl -v https://example.com

# Test with timing information
curl -w "\nDNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTotal: %{time_total}s\n" -o /dev/null -s https://example.com

# Test from the server itself (bypass DNS/network issues)
curl -v http://localhost
curl -v --resolve example.com:443:127.0.0.1 https://example.com

The timing output from curl -w is incredibly useful for diagnosing slow page loads:

DNS: 0.004s      # Time to resolve the domain
Connect: 0.025s  # Time to establish TCP connection
TLS: 0.089s      # Time to complete TLS handshake
Total: 0.234s    # Total time for the request

If DNS time is high, you have a DNS resolver issue. If connect time is high, there's network latency. If the gap between TLS and total is large, the server is slow to generate the response.

tcpdump — Packet Capture (Advanced)

# Capture packets on port 80 (HTTP)
sudo tcpdump -i eth0 port 80 -nn

# Capture packets from a specific IP
sudo tcpdump -i eth0 src host 198.51.100.5

# Capture and save to file (for analysis in Wireshark)
sudo tcpdump -i eth0 port 443 -w /tmp/capture.pcap -c 1000

# Capture DNS queries
sudo tcpdump -i eth0 port 53 -nn

Use tcpdump when other tools don't give you enough information. It shows the actual packets flowing through your network interface, which can reveal issues like connection resets, malformed packets, or unexpected traffic patterns.

Wrapping Up

Networking is the foundation that everything on your VPS depends on. With the knowledge from this guide, you can confidently point domains to your server, control which services are accessible, and diagnose problems when connections fail. The troubleshooting workflows here — combined with the diagnostic tools — will help you resolve the vast majority of networking issues you'll encounter.

For your next steps, secure your network with our UFW firewall guide, set up a VPN with our WireGuard guide, and monitor your network traffic as part of your server monitoring setup. Each of these builds directly on the networking fundamentals covered here.