IPv6 pro web: co přináší, co se rozbije a kontrolní seznam

Web funguje přes IPv6, když platí čtyři věci: v DNS je záznam AAAA, webový server naslouchá na adrese IPv6, firewall propouští porty 80 a 443 i pro IPv6 a certifikát se servíruje také přes IPv6. Polovina uživatelů Googlu už přichází přes IPv6 (50,10 % k 28. březnu 2026), takový web k nim tedy má přímou cestu. Záznam AAAA bez ostatních kroků ale škodí víc, než kdyby neexistoval: na našem testovacím stendu klienti s IPv6 web neotevřeli, prohlížeč ztrácel 0,3 s při každém připojení, skript v PHP to vzdal po 60 s a Let’s Encrypt odmítl vydat certifikát.

Kolik návštěvníků už používá IPv6

Google počítá uživatele vlastních služeb, kdežto APNIC měří vzorek prostřednictvím zobrazení reklam, proto se čísla liší: Pulse uvádí pro Francii 73 %, APNIC 86 %. Stránka Googlu ukazuje jen graf; hodnoty APNIC v tabulce jsou 30denní průměry ze záznamu z 31.10.2026 (staženo 10.11.2026). Závěr je stejný: v západní Evropě má IPv6 většinu, ve střední a východní Evropě je zatím v menšině, v Česku ho podle APNIC používá necelých 38 % klientů. Ještě jedno číslo z Common Crawl: přibližně každý třicátý web se záznamem AAAA přes IPv6 neodpovídal. Přesně tento případ jsme zopakovali.

Co IPv6 webu skutečně dává

• Přímou cestu k uživatelům IPv6. Mobilní operátoři se sítěmi jen s IPv6 se k webům na IPv4 dostávají přes překladače NAT64. Web s funkčním záznamem AAAA na nich nezávisí.
• Skutečnou adresu návštěvníka. Za NATem operátora (CGNAT) sdílejí stovky zákazníků jednu adresu IPv4, takže blokace pokusu o hádání hesla zasáhne všechny. S IPv6 má každý zákazník vlastní síť /64.
• Co nečekat: znatelné zrychlení. Na stendu trvala spojení přes IPv4 i IPv6 stejných 3-15 ms. Zisk je možný jen tam, kde operátor vede IPv4 přes přetížený NAT.

Co se rozbije: sedm scénářů z testovacího stendu

1. Záznam AAAA existuje, ale nginx naslouchá jen na IPv4

Konfigurace s listen 80; a listen 443 ssl; otevře pouze sokety IPv4. Klient, který zná obě adresy, nejdřív zkusí IPv6, dostane odmítnutí a během milisekund přejde na IPv4:

$ curl -v https://site.lab/
*   Trying [2001:db8:20::10]:443...
* connect to 2001:db8:20::10 port 443 from 2001:db8:20::100 port 37444 failed: Connection refused
*   Trying 192.0.2.10:443...
* Connected to site.lab (192.0.2.10) port 443

Proto majitel webu s domácím připojením přes IPv4 nic nepozná. Chromium se chovalo stejně, ale IPv6 zkoušelo znovu při každém novém spojení. Klient jen s IPv6 web vůbec neotevřel: curl hlásil Couldn't connect to server, Chromium ERR_CONNECTION_REFUSED. Oprava v nginx:

server {
    listen 80;
    listen [::]:80;
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com www.example.com;
}

Varianta s jediným soketem listen [::]:80 ipv6only=off; funguje také, ale má dva háčky. Obyčejné nginx -s reload nezmění už otevřené sokety: na stendu po něm IPv4 prostě přestalo odpovídat a pomohl až úplný restart. A PHP vidí návštěvníky z IPv4 jako ::ffff:192.0.2.100 (více níže).

2. Firewall se otevřel pro IPv4 a na IPv6 se zapomnělo

Pravidla iptables a ip6tables jsou oddělená. Na stendu mělo IPv4 politiku DROP s povolenými porty 22, 80 a 443, ip6tables mělo stejnou politiku, ale povolovalo jen SSH, DNS a ICMPv6. Pakety na port 443 přes IPv6 se tiše zahazovaly a každý klient reagoval po svém:

Člověk v prohlížeči ztratí 0,3 s, zatímco úlohy cron, platební webhooky a pluginy, které volají váš web přes file_get_contents(), visí celé minuty nebo selžou. Porovnejte pravidla pro oba protokoly a otevřete stejné porty:

iptables -S
ip6tables -S
ip6tables -A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT

Pokud je IPv6 zavřené záměrně, spojení odmítejte, místo abyste je zahazovali. Obyčejné -j REJECT (ICMPv6 port unreachable) bere jádro Linuxu jako měkkou chybu a curl to vzdal až po 1,02 s. S -j REJECT --reject-with tcp-reset přijde odmítnutí za 1 ms a prohlížeč okamžitě přejde na IPv4.

3. Opačná chyba: IPv6 dokořán

Stává se to i obráceně: někdo vyprázdnil ip6tables a politika se změnila na ACCEPT. Na stendu byla interní služba na portu 8080 pro IPv4 zavřená (curl čekal 5 s a vzdal to), přes IPv6 ale odpovídala kódem 200. Každá služba naslouchající na [::] je dostupná z internetu, jakmile má server veřejnou adresu IPv6. Kontrolujte proto ip6tables -S nebo nft list ruleset nejen po zapnutí IPv6, ale po každé změně pravidel.

4. IPv6 servíruje jiný web nebo jiný certifikát

Ovládací panely často vážou web na konkrétní adresu IPv4, zatímco soket IPv6 na portu 443 skončí u výchozího serveru. Na stendu bylo přes IPv4 vše v pořádku, přes IPv6 ale curl hlásil SSL: no alternative certificate subject name matches target host name. Uvidíte to jen při testu přes IPv6:

$ openssl s_client -connect 192.0.2.10:443 -servername site.lab
subject=CN = site.lab
$ openssl s_client -connect [2001:db8:20::10]:443 -servername site.lab
subject=CN = server.default.lab

Návštěvníci přes IPv6 dostanou varování „Vaše připojení není soukromé“, ostatní nevidí nic.

5. Let’s Encrypt kontroluje nejdřív IPv6

Při validaci HTTP-01 si certifikační autorita sama stáhne soubor z /.well-known/acme-challenge/, a pokud má doména AAAA, jde přes IPv6. Testovací server Pebble na stendu používal jen IPv6 a na IPv4 nikdy nepřešel:

AAAA, nginx only on IPv4:
  Detail: ... dial tcp [2001:db8:20::10]:80: connect: connection refused
ip6tables DROP tcp/80:
  Detail: ... context deadline exceeded (Client.Timeout exceeded while awaiting headers)
[::]:80 served by another site:
  Detail: Non-200 status code from HTTP: http://le3.example.com:80/.well-known/acme-challenge/... returned 404
dual stack:
  Successfully received certificate.

Skutečný Let’s Encrypt je shovívavější. Podle zdrojového kódu jeho serveru Boulder (va/http.go, ověřeno 10.11.2026) vezme první adresu IPv6 a na IPv4 přejde jen tehdy, když selže samotné spojení: odmítnutí nebo timeout při navazování spojení, pokud ještě nevypršel celkový čas validace. Když server přes IPv6 odpoví, třeba i jiným webem s chybou 404, je výsledek konečný. Dřívější běh na stendu ukázal totéž: se záznamem AAAA začínala validace přes IPv6. Všechny způsoby, jak certifikát získat, popisuje náš návod na SSL zdarma od Let’s Encrypt.

6. PHP, WordPress a .htaccess vidí adresu IPv6

Tohle dostal stejný skript v PHP od návštěvníka přes IPv4 a přes IPv6:

IPv4: REMOTE_ADDR=192.0.2.100        ip2long: 3221226084   v4-only allowlist: ALLOW
IPv6: REMOTE_ADDR=2001:db8:20::100   ip2long: false        v4-only allowlist: DENY
IPv4 via listen [::]:80 ipv6only=off: REMOTE_ADDR=::ffff:192.0.2.100   v4-only allowlist: DENY

Funkce jako ip2long(), regulární výrazy na čtyři čísla oddělená tečkami a filtr FILTER_FLAG_IPV4 se objevují v pluginech na ochranu administrace, v omezeních počtu požadavků a v geoblokaci. S IPv6 buď zamknou majitele venku, nebo pustí dovnitř každého. Spolehlivá kontrola používá inet_pton() a porovnání prefixu, aby seznam mohl obsahovat 192.0.2.0/24 i 2001:db8:20::/64. V samotném WordPressu 6.4.3 má sloupec comment_author_IP 100 znaků, ale v multisite ukládá tabulka wp_registration_log IP do sloupce o 30 znacích, přičemž plná adresa IPv6 zabere až 39.

Apache na tom není jinak. Pravidlo Require ip 192.0.2.0/24 v souboru .htaccess pustilo IPv4 s kódem 200 a klienta přes IPv6 zastavilo kódem 403 a řádkem AH01630: client denied by server configuration. Pomohlo doplnit naši síť IPv6 na stejný řádek:

Require ip 192.0.2.0/24 2001:db8:20::/64

Přidávejte síť /64 (nebo /56, kterou vám přidělí poskytovatel), ne jednu adresu: zařízení střídají dočasné adresy IPv6 a včerejší pravidlo zítra nesedí.

7. Logy: adresy s dvojtečkami

Log ze stendu obsahoval 16 požadavků: 8 od klienta přes IPv4 a 8 od jednoho návštěvníka přes IPv6, který střídal dočasné adresy v rámci jedné sítě /64. Obvyklé příkazy daly tento výsledek:

$ grep -oE '^[0-9]{1,3}(\.[0-9]{1,3}){3}' access.log | sort | uniq -c
      7 192.0.2.100
$ awk '{print $1}' access.log | awk -F: '{print $1":"$2":"$3":"$4}' | sort | uniq -c
      7 192.0.2.100:::
      2 2001:db8:20:
      6 2001:db8:20:0
      1 ::ffff:192.0.2.100

První vzor ztratil 9 z 16 řádků, druhý rozdělil jednu síť na dvě, protože 2001:db8:20::100 se zapisuje ve zkráceném tvaru. V chybovém logu Apache je adresa uvedena i s portem ([client 2001:db8:20::100:34996]) a awk -F: vrátí jen 2001. Port odřízněte u poslední dvojtečky a adresy seskupte modulem ipaddress v Pythonu:

awk '{print $1}' access.log | python3 -c '
import sys, ipaddress, collections
c = collections.Counter()
for line in sys.stdin:
    ip = ipaddress.ip_address(line.strip())
    if ip.version == 6 and ip.ipv4_mapped: ip = ip.ipv4_mapped
    c[str(ipaddress.ip_network(f"{ip}/{64 if ip.version == 6 else 32}", strict=False))] += 1
for net, n in c.most_common(): print(n, net)'

Výsledek: 8 192.0.2.100/32 a 8 2001:db8:20::/64, tedy dva návštěvníci, přesně jak to bylo. Jak obecně číst přístupové a chybové logy, vysvětluje náš návod k logům serveru na hostingu.

Kontrolní seznam: co ověřit, příkaz, očekávaný výsledek

Kontroly spouštějte z počítače, který má IPv6. Bez trasy IPv6 se Chromium na stendu na AAAA ani nezeptalo a šlo přes IPv4, takže z notebooku bez IPv6 problém neuvidíte.

Když X, udělejte Y

Záznam AAAA se přidává a maže ve stejné zóně DNS jako ostatní DNS záznamy a změna neplatí okamžitě: starý záznam zůstává v cache, dokud nevyprší jeho TTL. Jak dlouho to v praxi trvá, jsme změřili v článku o tom, jak dlouho trvá propagace DNS.

IPv6 na hostingu: na co se zeptat podpory

Na sdíleném hostingu spravuje adresy, listen a firewall poskytovatel, vám zůstává DNS a kód webu. Položte podpoře čtyři otázky: je ve vašem tarifu adresa IPv6 pro web, je v ovládacím panelu přiřazená k doméně, přidává panel záznam AAAA sám a funguje vydávání certifikátů Let’s Encrypt přes IPv6? Hostingové tarify RichHost zahrnují vlastní ovládací panel s asistentem AI a SSL zdarma od Let’s Encrypt; zda je pro váš web dostupná adresa IPv6, se zeptejte podpory (k dispozici od 10:00 do 20:00 kyjevského času, odpověď zhruba do 30 minut). Pak projděte kontrolní seznam výše.

Časté otázky

Potřebuji IPv6, když je moje publikum v zemi s nízkým rozšířením?

Ne nutně: APNIC měří zhruba 15 % klientů s IPv6 na Ukrajině a 20 % v Polsku, zbytek obslouží IPv4. V Česku je to přibližně 38 %, tedy už znatelná část návštěvníků. Pokud ale záznam AAAA už existuje, musí fungovat, jinak doplatí jako první právě tito návštěvníci. Pro publikum v Německu nebo Francii je IPv6 už hlavním protokolem.

Zrychlí IPv6 můj web?

Samo o sobě ne: na stendu trvala spojení přes oba protokoly 3-15 ms. Viditelný rozdíl vzniká jen při špatně nastaveném IPv6, a pak ve prospěch IPv4.

Proč prohlížeč web otevře, zatímco úloha cron nebo skript visí?

Prohlížeče a curl po 200-300 ms souběžně zkusí IPv4. Mnoho jiných klientů (wget, Python urllib, PHP file_get_contents()) čeká na timeout IPv6: 60-134 sekund na stendu.

Mohu záznam AAAA prostě smazat?

Ano, pokud server na IPv6 připravený není, je to nejjednodušší cesta zpět: klienti začnou používat IPv4, jakmile vyprší TTL starého záznamu. Pokud prohlížeč ukazuje DNS_PROBE_FINISHED_NXDOMAIN, problém není v IPv6, ale v samotné doméně: viz náš návod k chybě DNS_PROBE_FINISHED_NXDOMAIN.