An IPv6-only VPS is cheap to run and increasingly common on budget hosts that have exhausted their IPv4 allocation or charge $2 to $4 per month for a dedicated IPv4 address. It is also the single fastest way to discover which of your dependencies still assume a 32-bit address space.
The failure mode is dull rather than dramatic: installs hang for 90 seconds, API calls time out, package mirrors fail over and then back. All of these trace to a host with no working IPv6 default route, or a resolver that returns AAAA records it cannot actually reach. Because the errors are intermittent and slow, they are frequently misdiagnosed as network congestion or a flaky provider.
Before you buy, decide what the instance has to reach. A single container behind a proxy has a short dependency list and will be fine. A general-purpose web server with CMS plugins, cron jobs, a mail relay and a monitoring agent has a long one, and each dependency is a place where a missing IPv4 path turns into an outage.
Verify the route before you verify the software
On a fresh instance, check three things in order: that you have a globally routable address (not just fe80:: link-local), that a default route exists, and that traffic actually leaves. ip -6 addr show scope global, ip -6 route show default, and a ping to a known anycast target will settle it in under a minute.
ip -6 addr show scope global
ip -6 route show default
ping6 -c4 2001:4860:4860::8888
curl -6 -sS -m 10 https://ifconfig.coThen check whether the provider gives you a /64 or a /128. A /128 is fine for a single server but blocks containers or a second service on its own address. A /64 is the minimum for anything that might grow, and a host that will not delegate one on a $5 plan is telling you about its network design.
The resolver is where most setups break
A resolver reachable only over IPv4 is the most common trap. If /etc/resolv.conf points at 8.8.8.8 and the host has no IPv4 at all, every lookup fails and almost every package operation fails with it. Use 2001:4860:4860::8888 and 2606:4700:4700::1111, and confirm with dig AAAA example.com @2606:4700:4700::1111.
Then confirm the reverse: your service can reach IPv4-only destinations through NAT64 if the provider offers it. Without NAT64 or a proxy, an IPv6-only box cannot talk to hosts that publish only A records, and a surprising number of small-scale hosting deployments still depend on payment, email and monitoring endpoints that do exactly that.
Blocklist and reputation checks differ
IPv6 reputation coverage is thinner than IPv4. Some DNSBLs do not publish AAAA zones at all, which means an abuser list you rely on for filtering may silently return nothing and let mail through. Conversely, some receivers apply stricter policy to IPv6 senders because address rotation is trivial across a /64.
For inbound filtering, test your DNSBL queries with explicit AAAA lookups against zen.spamhaus.org and bl.spamcop.net and confirm responses arrive. If they do not, add a DNS-based allowlist or a scoring rule, because a filter that returns NXDOMAIN on every IPv6 query is a filter that is off.
What to confirm with the provider in writing
| Check | Acceptable | Walk away |
|---|---|---|
| Prefix size | /64 or larger | /128 only, no option |
| IPv4 address | Optional add-on ≤ $3/mo | None at any price |
| NAT64 / 464XLAT | Documented and enabled | “Should work” |
| rDNS on IPv6 | Self-service in panel | Ticket-only, no SLA |
| Firewall | ip6tables or nftables exposed | IPv6 bypasses the IPv4 firewall |
The firewall row deserves emphasis. On some budget platforms the panel’s firewall rules apply only to IPv4, so a service that is locked down on 22 over IPv4 is wide open on 22 over IPv6. Verify by attempting an SSH connection from an external IPv6 host with the rule in place. If it connects, you have found a real security gap, and it is the kind that sits unnoticed for months.
The rDNS row is close behind. Many budget hosts expose IPv6 reverse-DNS only through a support ticket, which makes it worthless the day you need to rotate an address quickly. Confirm in the panel that you can edit the PTR yourself, and check it resolves with dig -x 2001:db8::1 +short within a few minutes of saving.
Application-level checks that catch silent failures
Many applications bind to 0.0.0.0, which on a dual-stack host does not always include IPv6. Bind to :: with IPV6_V6ONLY=0, or list both explicitly. Then test with curl -6, not just curl — a request that succeeds over IPv4 proves nothing about the IPv6 path.
Check the health of your outbound integrations at the same time. Anything with a hardcoded IPv4 address in a config file, an allowlisted IP in a partner’s firewall, or a webhook that validates source addresses will need attention. External monitoring services also need AAAA support, or you will be monitoring a name that never resolves.
Run a traceroute6 to two or three destinations and count the hops. A path that leaves through an unexpected upstream can be 30 ms or more slower than the IPv4 route to the same place, and that difference shows up immediately once you put anything latency-sensitive on the instance. Cheap IPv6 transit is often cheap for a reason.
The decision in practical terms
IPv6-only works well for containers behind a reverse proxy, internal APIs, and anything whose outbound traffic goes through a small number of well-behaved endpoints. It works badly for anything that must accept connections from a broad public audience, because a meaningful share of clients still arrive over IPv4 only. Consumer ISPs, older mobile networks and corporate proxies are the slow movers, and they are exactly the users you cannot afford to lose.
There is a middle path: keep the application on IPv6 internally and put a small dual-stack reverse proxy in front of it, either on the same host or on a $2 instance elsewhere. That gives you cheap address space plus IPv4 reachability, at the cost of one more component to monitor and patch.
If your audience is public, buy the IPv4 add-on — $2 to $3 per month is cheaper than the incidents caused by a quarter of your visitors timing out. Start on dual-stack VPS plans with IPv6 available as an addition, test the six checks above, and migrate the workload to IPv6-only later once the dependency list is empty.
