Disabling IPv6: How to Do It, and Why You Probably Should Not

Disabling IPv6 is a two-line sysctl change, and it is the single most common piece of Linux networking advice that treats a symptom while leaving the cause in place — because the problem is nearly always a broken IPv6 path or a misconfigured DNS answer, not IPv6 itself.

That said, there are legitimate reasons to turn it off, and if you have one you should be able to do it correctly rather than half-way. This post covers the three methods and what each actually does, then the diagnostic path for the symptoms that usually lead people here — because if the real cause is a missing AAAA route, disabling IPv6 hides it until something else surfaces it.

Why people end up disabling it
Method one: sysctl, the reversible one
Method two: kernel parameter, the thorough one
Diagnose before you disable
Where disabling it is the wrong call
How this fits the rest of the stack
FAQ

Why people end up disabling it

The symptoms that lead here are consistent and they share a shape: something is slow or intermittent, and it stops being slow when IPv6 is off.

Slow connections that eventually work. A hostname resolves to both an AAAA and an A record. The client tries IPv6, gets no response, waits for a timeout, then falls back to IPv4. The delay is the timeout.
Some sites unreachable, most fine. A partial IPv6 path — an address assigned but no working route, or a firewall dropping IPv6 without rejecting it.
Software that does not handle it. Older applications binding only to IPv4, or config that assumes an address is four dotted numbers.
A firewall configured only for IPv4. This is the serious one: iptables rules do not apply to IPv6 traffic, which needs ip6tables. A host with a careful IPv4 firewall and no IPv6 rules may be wide open on IPv6 without anyone realising.

The last one is a genuinely good reason to disable IPv6 if you are not going to firewall it — an unfiltered protocol is worse than a disabled one. But the better fix is to firewall it, and modern nftables handles both families in one ruleset, which removes the whole class of mistake.

For the first two, disabling IPv6 makes the symptom vanish while the underlying broken path stays broken. That is fine on one laptop and a poor decision on infrastructure, where the same broken path will resurface somewhere you have less visibility.

Method one: sysctl, the reversible one

This is the method to use. It takes effect immediately, survives reboot when written to a config file, and can be undone without a restart.

# Immediately, for the current boot
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.lo.disable_ipv6=1

# Persistently
echo 'net.ipv6.conf.all.disable_ipv6 = 1' | sudo tee /etc/sysctl.d/99-disable-ipv6.conf
echo 'net.ipv6.conf.default.disable_ipv6 = 1' | sudo tee -a /etc/sysctl.d/99-disable-ipv6.conf
echo 'net.ipv6.conf.lo.disable_ipv6 = 1' | sudo tee -a /etc/sysctl.d/99-disable-ipv6.conf
sudo sysctl --system

# Verify: should return nothing
ip -6 addr show

The three settings do different things and all are needed. all applies to existing interfaces, default to interfaces created afterwards, and lo to the loopback — which matters because some software expects to reach itself over ::1 and behaves oddly when loopback IPv6 is present but the rest is not.

Reverse it by setting the values back to 0, or deleting the file and rebooting. The reversibility is the reason to prefer this method.

One caveat: settings written to /etc/sysctl.d/ are applied late in boot, so there is a window early in startup where IPv6 is active. For most purposes this is irrelevant; if it is not, use the kernel parameter below.

Method two: kernel parameter, the thorough one

Disabling at boot means IPv6 is never initialised at all, which closes the early-boot window and is the correct method when IPv6 is compiled into the kernel rather than built as a module.

# Edit the default GRUB configuration
sudo nano /etc/default/grub

# Append ipv6.disable=1 to the existing parameters, e.g.
# GRUB_CMDLINE_LINUX_DEFAULT="quiet splash ipv6.disable=1"

# Regenerate the bootloader config
sudo update-grub          # Debian/Ubuntu
sudo grub2-mkconfig -o /boot/grub2/grub.cfg   # RHEL family

sudo reboot

This is more thorough and less convenient: changing your mind requires editing GRUB and rebooting again. On a remote machine that is a meaningful cost, and it is why sysctl is the better default.

It also has a sharper failure mode. Software that assumes IPv6 exists — expecting to bind ::1, or to create an IPv6 socket — may fail outright rather than degrade, because the protocol is genuinely absent rather than merely disabled. Some daemons will not start.

The third method sometimes suggested, blacklisting the ipv6 module in modprobe.d, is the least reliable of the three. On most modern distributions IPv6 is compiled in rather than modular, so the blacklist does nothing at all while appearing to have been applied. Do not use it.

Diagnose before you disable

If the symptom is slowness or intermittent failure, spend five minutes finding the actual cause. It is usually one of three things and all three are fixable.

Do you have a working IPv6 route? Check for a global address with ip -6 addr and a default route with ip -6 route. An address with no route is the classic broken configuration and produces exactly the timeout-then-fallback symptom.
Can you reach the IPv6 internet? ping6 a well-known address. If you have an address, a route, and no connectivity, the problem is upstream — your ISP, your cloud network configuration, or a firewall dropping outbound IPv6.
Is DNS returning AAAA records you cannot use? dig AAAA example.com. If your resolver returns IPv6 addresses and you have no working IPv6 path, every lookup produces a connection attempt that must time out.

The fix for the common case is to complete the configuration rather than remove it — either establish working IPv6 connectivity, or stop advertising an address you cannot route from. A host with an IPv6 address and no route is misconfigured in a way that will cause other problems later.

Happy Eyeballs, the algorithm modern clients use, is specifically designed to make this invisible: it races IPv4 and IPv6 connections and uses whichever answers first, so a broken IPv6 path costs milliseconds rather than seconds. If you are seeing multi-second delays, something is not implementing it — often an older library or a language runtime’s default resolver — and that is worth knowing about independently.

Where disabling it is the wrong call

Some situations where turning IPv6 off causes more trouble than it solves.

Mobile networks. Several large carriers run IPv6-only with translation for IPv4. A server that does not speak IPv6 is reached through a translator, which adds latency and occasionally breaks.
Modern cloud networking. Some provider features assume IPv6 is available, and internal service meshes and container networks increasingly use it. Disabling at the kernel level can break things that have nothing to do with the internet.
Localhost expectations. A surprising amount of software resolves localhost to ::1 first. With loopback IPv6 disabled, that fails, and the resulting error usually points somewhere unhelpful.
Anything you will need later. IPv4 address exhaustion is not reversing. Infrastructure built on the assumption that IPv6 does not exist accumulates a migration debt that gets paid eventually.

The proportionate position: on a personal machine with a specific annoyance, disable it and move on. On a server, fix the configuration — assign a working address and route or none at all, firewall both families with a single nftables ruleset, and make sure your applications bind correctly. That takes an hour once and leaves you in a defensible state rather than a workaround you will inherit later.

How this fits the rest of the stack

Most of what this post describes — kernel parameters, dual-family firewalls, verifying a route exists on a machine you cannot reach — is the operational surface that comes with running your own servers, and it does not appear on any bill until it costs you a night. The RunxBuild hosting calculator covers the costs that do: the service, the database, the storage and the bandwidth. On RunxBuild the network layer is managed, services deploy from a repository, and managed databases sit behind private networking rather than a ruleset you maintain per address family.

Useful related references:

FAQ

What is the best way to disable IPv6 on Linux?

The sysctl method: set net.ipv6.conf.all.disable_ipv6, .default.disable_ipv6 and .lo.disable_ipv6 to 1, and persist them in a file under /etc/sysctl.d/. It takes effect immediately, survives reboot, and can be reversed without restarting — which matters on a remote machine.

Does blacklisting the ipv6 module work?

Usually not. On most modern distributions IPv6 is compiled into the kernel rather than built as a module, so a modprobe blacklist has no effect while appearing to have been applied. Use sysctl, or the ipv6.disable=1 kernel parameter if you need it disabled from boot.

Why are my connections slow with IPv6 enabled?

Typically because a hostname resolves to both AAAA and A records, the client tries IPv6, and there is no working route — so it waits for a timeout before falling back to IPv4. Check whether you have a global IPv6 address with a default route. An address with no route is the classic broken configuration.

Is it safe to disable IPv6 on a server?

It is safe in the sense that nothing breaks immediately, but it usually hides a misconfiguration rather than fixing one. The better answer on a server is either working IPv6 with an nftables ruleset covering both families, or no IPv6 address advertised at all. An unfirewalled IPv6 stack is a genuine risk, since iptables rules do not apply to it.

Will disabling IPv6 break anything?

It can. Some software resolves localhost to ::1 first and fails when loopback IPv6 is gone, some daemons will not start without an IPv6 socket, and some cloud and container networking features assume it is available. Disabling at the kernel parameter level is more likely to cause hard failures than the sysctl method.