IPv4 vs IPv6 for VPS — I Saved $108/Year Running IPv6-Only Backends

Here is a number that should make you stop and think: a single IPv4 address trades for $30-50 on the secondary market in 2026. A /24 block — 256 addresses — costs $7,500 to $12,000. Meanwhile, a perfectly functional VPS costs $4-6 per month. The address on the mailbox is worth more than six months of rent for the apartment. That absurd economics shapes everything about how VPS providers price their plans, how many IPs you can get, and whether IPv6-only hosting has finally become viable for real workloads.

I run nine VPS instances across four providers for various projects. Three of those instances are IPv6-only backend servers — database replicas, a CI/CD runner, and a monitoring aggregator. They save me $3/month each on IPv4 address fees, totaling $108/year. That is not life-changing money. But it does pay for an entire additional VPS, and the architecture is actually cleaner because those backend services were never meant to be publicly reachable anyway. Removing the IPv4 address did not just save money — it eliminated an unnecessary attack surface.

This page is about making the right decision for your specific situation. Public website? You need dual-stack. Backend services? IPv6-only might save you real money. Gaming server? IPv4 is still mandatory. The answer depends on who needs to reach your server and what they are running.

Quick Answer

Dual-stack (IPv4 + IPv6) for anything public-facing. An IPv6-only server loses 35-40% of potential visitors. For internal services where you control both endpoints, IPv6-only saves $2-5/month per address and reduces attack surface. The Cloudflare proxy trick gives IPv6-only servers full IPv4 reachability for free. Most providers include one free IPv4 and free IPv6 with every VPS. Extra IPv4 addresses cost $1.19–$5/month because every IPv4 address is a scarce commodity. Vultr and Hetzner have the best IPv6 support.

The Economics of IP Address Scarcity

IPv4 uses 32-bit addresses. That gives us 4.3 billion total for the entire planet. In 1981 when the protocol was designed, that seemed absurdly generous. In 2026, with 15+ billion internet-connected devices, every single one has been allocated. All five Regional Internet Registries have exhausted their free pools. The only way to acquire IPv4 addresses now is to buy them from organizations that have them, on a secondary market that looks more like a commodity exchange than a tech transaction.

This is not an abstract infrastructure problem. It shows up directly on your VPS bill:

  • IPv4 addresses are a real cost to providers. When Vultr or DigitalOcean provisions your VPS with a public IPv4 address, they are lending you an asset worth $30-50 on the open market. At a $5/month plan, the IP address's market value exceeds 6 months of hosting revenue. Providers amortize this cost across their customer base, but the pressure is real and growing.
  • Additional IPv4 addresses cost $1.19-5/month. Need multiple IPs for different SSL sites, email reputation isolation, or separate service endpoints? Each extra IPv4 adds to your bill. Hetzner charges the least at $1.19/month. DigitalOcean charges the most at $5/month. That spread directly reflects each provider's existing IPv4 inventory.
  • IPv6-only plans exist and are cheaper. Providers like BuyVM and CloudCone offer VPS without an IPv4 address at a $1-3/month discount. The savings are small per server but compound with multiple instances.

IPv6, by contrast, uses 128-bit addresses. That provides 340 undecillion addresses — a number so incomprehensibly large that if you assigned a billion addresses per second, it would take 10 billion years to use them all. A single /48 block (what BuyVM gives individual VPS customers) contains 1.2 trillion addresses. Providers hand these out like water because there will never be a shortage. The bizarre result: the modern, technically superior protocol is free, while the obsolete 45-year-old protocol costs money. Legacy infrastructure is the definition of expensive technical debt.

IPv6 Adoption in 2026 — The Real Numbers

We have been hearing "this is the year of IPv6" for two decades. The boring reality: adoption has been gradual, real, and is now at a tipping point. Global IPv6 traffic hit approximately 45% in 2026, up from 35% in 2023 and 25% in 2020. But the averages hide dramatic variation across network types:

Network Type IPv6 Adoption Notable Details
Mobile networks70–85%T-Mobile, Verizon, AT&T route mobile traffic primarily over IPv6
US residential ISPs40–60%Comcast, AT&T Fiber, Spectrum support dual-stack. Smaller ISPs lag.
European ISPs35–55%Germany leads at 60%+. UK and France around 30%.
Enterprise networks20–30%Slowest to transition. Legacy equipment, security concerns.
Cloud providers95%+All major VPS providers support IPv6 (except Hostinger).
IoT devices80%+Most modern IoT platforms are IPv6-native.

What this means for your VPS: an IPv6-only server can be directly reached by roughly 60-65% of the internet. The remaining 35-40% — mostly corporate networks and legacy ISPs — need IPv4 or a translation mechanism. For a public website, losing 35-40% of potential visitors is obviously not acceptable. For a backend API that only your own servers call, or a CI/CD runner that only pulls from GitHub, IPv6-only saves real money because you control both endpoints.

The trend line matters too. IPv6 adoption grows about 3-5 percentage points per year. By 2028-2029, IPv4-only users will be under 25% of the internet. The window where IPv4 is mandatory for public services is closing, but we are not there yet.

Technical Comparison

Feature IPv4 IPv6
Address Size32-bit (4.3 billion total)128-bit (340 undecillion)
Address Format192.168.1.12001:db8::1
AvailabilityExhausted globallyEffectively infinite
Cost per Extra Address$1.19–$5/moFree (included)
Universal Reachability~100% of internet~60–65%
NAT RequiredCommon (CGNAT at ISPs)No (true end-to-end)
Security (IPsec)Optional extensionBuilt into protocol
Header FormatVariable (20–60 bytes)Fixed (40 bytes, faster processing)
Auto-configurationRequires DHCP serverSLAAC (stateless, automatic)
DNS Record TypeA recordAAAA record
BroadcastYes (broadcast storms possible)No broadcast (multicast only)
FragmentationBy routers and endpointsBy endpoints only (more efficient)

The technical advantages of IPv6 are clear. No NAT means true end-to-end connectivity — every device can be directly addressed without port forwarding hacks. Built-in IPsec means encryption is a protocol feature rather than an afterthought. Fixed headers mean routers process IPv6 packets faster. SLAAC means devices can auto-configure their own addresses without a DHCP server. IPv6 is better in every technical dimension. The only reason IPv4 persists is inertia and the massive installed base that has not upgraded.

Dual-Stack Setup — The Recommended Default

Dual-stack means your VPS has both an IPv4 and an IPv6 address. Everyone can reach you regardless of what decade their ISP's equipment was manufactured in. It is the pragmatic choice for any public-facing server. Most providers assign both addresses automatically when you create a VPS instance. You just need to verify three things are properly configured.

1. Verify Your IP Addresses

# Show all IP addresses
ip addr show

# Show only IPv4
ip -4 addr show

# Show only IPv6
ip -6 addr show

# Test IPv4 connectivity
ping -4 google.com

# Test IPv6 connectivity
ping -6 google.com
# or: ping6 google.com

# Check from outside (what does the world see?)
curl -4 ifconfig.me    # Your public IPv4
curl -6 ifconfig.me    # Your public IPv6

2. Configure DNS Records

# At your DNS provider, add both record types:
yourdomain.com    A      203.0.113.10           # IPv4
yourdomain.com    AAAA   2001:db8:1234::10      # IPv6
www.yourdomain.com A     203.0.113.10           # IPv4 for www
www.yourdomain.com AAAA  2001:db8:1234::10      # IPv6 for www

# Browsers use the "Happy Eyeballs" algorithm:
# They try both IPv4 and IPv6 simultaneously and use whichever responds first.
# This means dual-stack never slows down connections — it can only help.

3. Configure Nginx for Dual-Stack

# Nginx dual-stack server block
server {
    listen 80;
    listen [::]:80;              # IPv6 on port 80

    listen 443 ssl http2;
    listen [::]:443 ssl http2;   # IPv6 on port 443

    server_name yourdomain.com www.yourdomain.com;
    root /var/www/yourdomain.com/html;

    # SSL configuration (Certbot will add this)
    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

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

# After editing, test and reload:
sudo nginx -t && sudo systemctl reload nginx

4. Certbot SSL for Both Protocols

# Certbot handles dual-stack automatically — no special flags needed
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

# Let's Encrypt validates via HTTP on whichever protocol it chooses
# As long as both A and AAAA records point to your server, it works

# Verify certificate covers your domain
sudo certbot certificates

IPv6-Only Architecture — When It Makes Sense

This is where the economics get interesting. I run three IPv6-only backend servers as part of my infrastructure. They save me $3/month each — $9/month total, $108/year. Here is exactly what they run and why IPv6-only works for each:

When IPv6-Only Works Well

  • Backend services: My database replica and monitoring aggregator communicate exclusively with my front-end servers, which I control and confirm have IPv6. No public access needed. No IPv4 needed.
  • CI/CD runners: My build server pulls from GitHub (which has full IPv6 support) and pushes to my deployment targets (which I control). IPv4 never enters the picture.
  • Development and staging environments: I access these through WireGuard tunnels that run over IPv6. See our networking guide for WireGuard setup.
  • VPN endpoints: WireGuard and OpenVPN work over IPv6 just fine. Your clients connect by IP address that you configure.
  • Internal microservices: Any service that only talks to your other services. API gateways, message queues, caches, workers.

When IPv6-Only Fails

  • Public websites: 35-40% of visitors cannot reach an IPv6-only server. Fatal for any commercial site.
  • Email servers: Many receiving mail servers only support IPv4 MX lookups. IPv6-only SMTP will have serious deliverability problems.
  • Third-party API calls to IPv4-only services: Some APIs (payment processors, legacy services) only have IPv4 endpoints. Your IPv6-only server cannot reach them without NAT64 or a proxy.
  • Game servers: Most game clients still connect via IPv4 by default. Running a Minecraft server on IPv6-only loses a significant chunk of your player base.
  • External monitoring services: Many uptime monitoring tools only check IPv4 endpoints. Your IPv6-only server appears "down" to them.
# Test if a service you need is reachable via IPv6
curl -6 https://api.github.com       # Works — GitHub has IPv6
curl -6 https://registry.npmjs.org    # Works — npm has IPv6
curl -6 https://pypi.org              # Works — PyPI has IPv6
curl -6 https://api.stripe.com        # Check before depending on it

# If a critical service is IPv4-only and you need it from an IPv6-only VPS,
# you have two options:
# 1. Use NAT64/DNS64 (complex, provider-dependent)
# 2. Route through an IPv4-capable proxy (simpler, more reliable)

The Cloudflare Proxy Trick — IPv4 Reachability for Free

This is the clever workaround that makes IPv6-only viable for some public-facing services: put Cloudflare in front of your IPv6-only VPS as a reverse proxy. Cloudflare accepts connections from IPv4-only visitors and forwards them to your IPv6 origin server. Your server gets universal reachability without needing an IPv4 address.

# Step 1: Point your domain to Cloudflare's nameservers
# (Done in your registrar's dashboard)

# Step 2: In Cloudflare dashboard, add DNS records:
yourdomain.com    AAAA   2001:db8:1234::10   # IPv6 only — no A record needed
www               AAAA   2001:db8:1234::10   # Enable orange cloud (proxy) on both

# Step 3: Ensure Cloudflare's proxy is enabled (orange cloud icon)
# This means:
# - IPv4 visitors → Cloudflare (IPv4) → Your server (IPv6)
# - IPv6 visitors → Cloudflare (IPv6) → Your server (IPv6)
# - Universal reachability, zero IPv4 cost

# Step 4: Configure Nginx to accept Cloudflare's real IP
# /etc/nginx/conf.d/cloudflare-real-ip.conf
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;
# IPv6 ranges
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;
real_ip_header CF-Connecting-IP;

The trade-offs with this approach are worth understanding clearly:

  • Pro: Universal reachability without an IPv4 address. Saves $2-5/month per server.
  • Pro: Cloudflare's free tier includes DDoS protection, CDN caching, and SSL termination.
  • Con: Dependency on Cloudflare. If their free tier changes terms or they have an outage, your IPv4 reachability goes with it.
  • Con: SSH access must be via IPv6 directly or through a WireGuard tunnel. Cloudflare does not proxy SSH.
  • Con: Certbot HTTP validation requires direct connectivity. Use DNS validation instead (certbot --dns-cloudflare).

My recommendation: for personal projects, side projects, and non-revenue-generating sites, the Cloudflare trick is a smart way to save money. For a business generating real revenue, spend the $3/month on an IPv4 address and eliminate the dependency. Saving $36/year is not worth the risk of a Cloudflare outage taking your revenue-generating site offline for IPv4 visitors.

Provider IPv6 Support — The Full Comparison

Provider Free IPv6 IPv6 Allocation IPv6-Only Plans Extra IPv4 Cost Entry Price
VultrYes/64 subnet availableNo$3/mo$5/mo
DigitalOceanYes16 addressesNo$5/mo$6/mo
HetznerYes/64 subnet (18 quintillion)No$1.19/mo$4.59/mo
LinodeYes/128 + SLAAC poolNo$2/mo$5/mo
KamateraYes1 address (more on request)No$4/mo$4/mo
ContaboYes/64 subnet (18 quintillion)No$3.50/mo$5.50/mo
BuyVMYes/48 subnet (1.2 trillion)Yes (cheaper)$3/mo$2/mo
CloudConeYes/64 subnetYes$2/mo$1.99/mo
RackNerdYes1 addressNo$2/mo$1.49/mo
HostingerNo IPv6NoN/A$4.99/mo

The standouts: BuyVM's /48 allocation is outrageously generous — 1.2 trillion addresses per VPS. Hetzner and Contabo hand out /64 subnets (18 quintillion addresses) as standard. Even DigitalOcean's relatively conservative 16 addresses per droplet covers any normal use case. Hetzner also wins on extra IPv4 pricing at $1.19/month — less than a quarter of what DigitalOcean charges for the same thing.

The conspicuous outlier: Hostinger. No IPv6 support at all in 2026. For a provider that performs well in our CPU and disk benchmarks, this is a puzzling gap. If your deployment requires IPv6 — for compliance, future-proofing, or cost optimization — Hostinger is simply not an option. Factor this into your provider decision.

IPv6 Firewall Configuration — The Part Everyone Forgets

This is the most common IPv6 security mistake, and I have seen it on production servers from people who should know better: they carefully configure iptables for IPv4, then leave IPv6 completely open because they "do not use IPv6" or "forgot it was enabled." Every service listening on 0.0.0.0 is also listening on :: unless explicitly bound to an IPv4 address. If your firewall only covers IPv4, your services are exposed on IPv6 with zero protection.

nftables (Recommended — Handles Both Protocols)

# nftables "inet" family applies to BOTH IPv4 and IPv6 simultaneously
# This is the single biggest advantage of nftables over legacy iptables

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        ct state established,related accept
        ct state invalid drop
        iif "lo" accept

        # ICMPv4 — rate limited
        ip protocol icmp icmp type echo-request limit rate 5/second accept

        # ICMPv6 — MUST ALLOW (IPv6 breaks without it)
        # Neighbor discovery, router advertisements, and path MTU all use ICMPv6
        ip6 nexthdr icmpv6 accept

        # SSH, HTTP, HTTPS — applies to both IPv4 and IPv6
        tcp dport { 22, 80, 443 } accept
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Legacy iptables + ip6tables (If You Must)

# IPv6 firewall rules — MUST mirror your IPv4 rules
# The most common mistake is having iptables rules but no ip6tables rules

ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A INPUT -m state --state INVALID -j DROP

# CRITICAL: Allow ICMPv6 — IPv6 BREAKS without it
# Unlike IPv4 where blocking ICMP is sometimes recommended,
# IPv6 uses ICMPv6 for:
#   - Neighbor Discovery (equivalent of ARP)
#   - Router Advertisements
#   - Path MTU Discovery
#   - Duplicate Address Detection
ip6tables -A INPUT -p icmpv6 -j ACCEPT

# Allow SSH, HTTP, HTTPS
ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT
ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT
ip6tables -A INPUT -p tcp --dport 443 -j ACCEPT

# Drop everything else
ip6tables -A INPUT -j DROP

# Save the rules persistently
sudo apt install iptables-persistent -y
sudo netfilter-persistent save

The ICMPv6 rule is critical. I cannot stress this enough. In IPv4, blocking ICMP is sometimes done for "security." In IPv6, blocking ICMPv6 breaks the protocol entirely. Neighbor Discovery — the IPv6 equivalent of ARP — uses ICMPv6. Path MTU Discovery uses ICMPv6. Router advertisements use ICMPv6. Block ICMPv6 and your IPv6 connectivity will fail in ways that are maddeningly difficult to debug. Always allow it. This is covered in detail in our VPS security guide.

DNS for Dual-Stack — Getting It Right

# Verify your DNS records resolve correctly
dig yourdomain.com A        # Should return your IPv4 address
dig yourdomain.com AAAA     # Should return your IPv6 address

# Test that both protocols work end-to-end
curl -4 https://yourdomain.com   # Force IPv4
curl -6 https://yourdomain.com   # Force IPv6

# Check what protocol visitors are actually using
# Add this to your Nginx access log format:
log_format detailed '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

# Then analyze the logs:
# IPv4 addresses look like: 203.0.113.10
# IPv6 addresses look like: 2001:db8::1
# Count them:
grep -c "^[0-9]\{1,3\}\." /var/log/nginx/access.log    # IPv4 hits
grep -c "^[0-9a-f]*:" /var/log/nginx/access.log         # IPv6 hits

Reverse DNS (PTR Records)

If you run a mail server, reverse DNS is mandatory for both IPv4 and IPv6. Most VPS providers let you set PTR records through their dashboard. Without proper reverse DNS on your sending IP, your email goes straight to spam.

# Check reverse DNS for your IPs
dig -x 203.0.113.10             # IPv4 PTR lookup
dig -x 2001:db8:1234::10        # IPv6 PTR lookup

# Both should return your domain name.
# Set PTR records in your VPS provider's dashboard — not your DNS provider.
# The reverse DNS zone is controlled by whoever owns the IP block (your VPS provider).

IPv6 Troubleshooting — The Common Problems

# Problem: IPv6 is enabled but not working
# Step 1: Check if IPv6 is enabled in the kernel
cat /proc/sys/net/ipv6/conf/all/disable_ipv6
# 0 = enabled, 1 = disabled

# If disabled, enable it:
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=0
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=0
echo "net.ipv6.conf.all.disable_ipv6 = 0" | sudo tee -a /etc/sysctl.conf
echo "net.ipv6.conf.default.disable_ipv6 = 0" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

# Step 2: Check if you have an IPv6 address assigned
ip -6 addr show | grep "scope global"
# Should show a global IPv6 address. If empty, check provider dashboard.

# Step 3: Check IPv6 routing
ip -6 route show
# Should have a default route like: default via fe80::1 dev eth0

# Step 4: Test connectivity
ping6 -c 4 google.com
# If this fails but you have an address and route, check your firewall

# Step 5: Check if your application is listening on IPv6
ss -tlnp | grep -E '::.*LISTEN'
# Services should show [::]:80, [::]:443, etc.

# Problem: "Network is unreachable" when pinging IPv6
# Usually means no IPv6 default route. Check with your provider
# that IPv6 is enabled for your VPS instance.

# Problem: IPv6 works locally but not from outside
# Check firewall rules — you may be blocking incoming IPv6 connections
sudo nft list ruleset | grep -i ipv6
# Or: sudo ip6tables -L -n

Frequently Asked Questions

Do I need IPv6 for my VPS?

Enable it if your provider offers it — most do, for free. Dual-stack ensures your server is reachable via both protocols. The only reason to disable IPv6 is a specific security policy, and even then, properly firewalled IPv6 is better than disabling it. Critical: if you firewall IPv4 but leave IPv6 open, you have a security hole. Our security guide covers this.

Is IPv6 faster than IPv4?

In theory, slightly — no NAT overhead, simpler fixed header. In practice, under 1 ms difference on well-connected networks. Some ISPs route IPv6 less optimally because their IPv6 peering is less mature. On premium providers like Vultr and DigitalOcean, performance is virtually identical between protocols.

Can I run a public website on IPv6 only?

You can, but 35-40% of visitors cannot reach you. The workaround: Cloudflare as a reverse proxy accepts IPv4 connections and forwards to your IPv6 origin. Universal reachability, zero IPv4 cost. For internal services where you control both endpoints, IPv6-only is fully viable without any proxy.

Why does an IPv4 address cost money but IPv6 is free?

Pure scarcity. IPv4: 4.3 billion addresses, all allocated. Secondary market price: $30-50 each. Providers charge $1.19-$5/month per extra address. IPv6: 340 undecillion addresses. Effectively infinite. Costs providers nothing to allocate. The legacy protocol is the expensive one.

How many IPv6 addresses can I get with a VPS?

More than you could ever use. BuyVM: /48 (1.2 trillion). Hetzner and Contabo: /64 (18 quintillion). DigitalOcean: 16 addresses. Even the most conservative allocation exceeds any practical need.

Why does Hostinger not support IPv6?

Legacy infrastructure that has not been upgraded. Hostinger is the most notable mainstream VPS provider lacking IPv6 in 2026. If you need IPv6 for compliance, cost optimization, or future-proofing, Hostinger is not an option. Check our networking guide for providers with full IPv6 support.

How do I firewall IPv6 on my VPS?

Use nftables with the inet family, which covers both protocols in a single ruleset. With legacy iptables, create matching ip6tables rules for every iptables rule. Critical: always allow ICMPv6 — IPv6 connectivity breaks without it because Neighbor Discovery and Path MTU both depend on ICMPv6.

What is dual-stack and should I use it?

Dual-stack = your VPS has both IPv4 and IPv6. Clients reach you via either protocol. Yes, use it for anything public-facing. DNS gets both A (IPv4) and AAAA (IPv6) records. Browsers pick the fastest one automatically via Happy Eyeballs. Most providers assign both addresses by default — just verify your firewall and application binding cover both protocols.

The Label on the Mailbox Costs More Than the Apartment

IPv4 scarcity is real and getting worse. Dual-stack your public servers. IPv6-only your backends. Save the $108/year and put it toward a better VPS.

Networking Guide Provider Reviews Price Comparison
AC
Alex Chen — Senior Systems Engineer

Alex manages nine VPS instances across four providers, three of which run IPv6-only to save on address costs. He tracks IPv6 adoption trends and provider allocation policies as part of ongoing VPS benchmarking. Learn more about our testing methodology →