Auf meinem Linux Mint installiert, sieht der Einstieg schlicht aus: ein Suchfeld f\u00fcr ein beliebiges Profil, und darunter die eigene Profilansicht mit allen best\u00e4tigten Identity-Claims.<\/p>\n\n\n
![\"Keyoxide-App](\"https:\/\/www.kernel-error.de\/wp-content\/uploads\/2026\/09\/keyoxide-flatpak-suche.png\")
<\/a>![\"Keyoxide-App](\"https:\/\/www.kernel-error.de\/wp-content\/uploads\/2026\/09\/keyoxide-flatpak-profil.png\")
<\/a>Inhaltlich \u00e4ndert das nichts an dem, was im August-Beitrag steht, DNS, GitHub und Matrix bleiben best\u00e4tigt, aber eine native App ist f\u00fcr den t\u00e4glichen Gebrauch angenehmer als jedes Mal die richtige URL zu tippen.<\/p>\n\n\n\n
Das Android-Update<\/h3>\n\n\n\n
Parallel zur Linux-App wurde auch die Android-Version aktualisiert, Version 2.4.4<\/a> auf Codeberg. Gleicher Entwickler, gleiche Codebasis, zwei Plattformen aus einer Quelle.<\/p>\n\n\n\n Die App zeigt unter „Profile ID QR“ einen QR-Code f\u00fcrs eigene Profil, darunter als Klartext den sogenannten Key Link, die WKD-Adresse des \u00f6ffentlichen Schl\u00fcssels. Bevor der hier landet, wollte ich wissen, ob der Code wirklich auf die richtige Datei zeigt und nicht auf einen veralteten Stand.<\/p>\n\n\n Zwei Dinge lassen sich hier unabh\u00e4ngig nachrechnen. Erstens der Pfad selbst: Web Key Directory bildet die Adresse aus einem SHA-1-Hash des lokalen Teils der E-Mail-Adresse, Z-Base-32-kodiert. F\u00fcr Wer selbst mit Keyoxide anfangen will oder unterwegs h\u00e4ngen bleibt, findet jetzt einen eigenen Raum f\u00fcr allgemeine Fragen: #keyoxide:matrix.org<\/a>. Ich lese dort mit.<\/p>\n\n\n\n Eigene Erfahrungen mit Keyoxide, der Flatpak- oder der Android-App? Dann darfst du mich sehr gerne fragen<\/a>.<\/p>\n\n","protected":false},"excerpt":{"rendered":" Der Keyoxide-Beitrag von August bekommt einen kurzen Nachtrag: die Linux-App liegt jetzt im Flathub, die Android-App wurde aktualisiert, und f\u00fcr Fragen gibt es einen eigenen Matrix-Kanal. Dazu der Faktencheck, ob der QR-Code in der App wirklich auf die richtige Datei zeigt.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"activitypub_content_warning":"","activitypub_content_visibility":"","activitypub_max_image_attachments":4,"activitypub_interaction_policy_quote":"anyone","activitypub_status":"federated","footnotes":""},"categories":[272,13,276],"tags":[74,377,134,371,445,301,446,372],"class_list":["post-5453","post","type-post","status-publish","format-standard","hentry","category-it-security","category-kernel-error-blog","category-self-hosting-infrastruktur","tag-dnssec","tag-encryption","tag-gpg","tag-infosec","tag-keyoxide","tag-matrix","tag-openpgp","tag-selfhosted","post-preview"],"_links":{"self":[{"href":"https:\/\/www.kernel-error.de\/wp-json\/wp\/v2\/posts\/5453","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kernel-error.de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kernel-error.de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kernel-error.de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kernel-error.de\/wp-json\/wp\/v2\/comments?post=5453"}],"version-history":[{"count":1,"href":"https:\/\/www.kernel-error.de\/wp-json\/wp\/v2\/posts\/5453\/revisions"}],"predecessor-version":[{"id":5454,"href":"https:\/\/www.kernel-error.de\/wp-json\/wp\/v2\/posts\/5453\/revisions\/5454"}],"wp:attachment":[{"href":"https:\/\/www.kernel-error.de\/wp-json\/wp\/v2\/media?parent=5453"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kernel-error.de\/wp-json\/wp\/v2\/categories?post=5453"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kernel-error.de\/wp-json\/wp\/v2\/tags?post=5453"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}},{"id":5410,"date":"2026-09-11T10:00:00","date_gmt":"2026-09-11T08:00:00","guid":{"rendered":"https:\/\/www.kernel-error.de\/?p=5410"},"modified":"2026-09-11T09:57:39","modified_gmt":"2026-09-11T07:57:39","slug":"quic-dual-stack-socket-df-bit-nginx-freebsd","status":"publish","type":"post","link":"https:\/\/www.kernel-error.de\/2026\/09\/11\/quic-dual-stack-socket-df-bit-nginx-freebsd\/","title":{"rendered":"QUIC auf Dual-Stack-Sockets: das DF-Bit, das nginx f\u00fcr IPv4-Clients nie setzt"},"content":{"rendered":" Ein Listener f\u00fcr IPv4 und IPv6 zusammen klingt nach der besseren L\u00f6sung. Ein Socket statt zwei, eine Konfigurationszeile weniger, ggf. ein Firewall-Regelwerk weniger zu pflegen. Bei QUIC auf diesem Blog lief das genau so, seit hier HTTP\/3 aktiviert ist. Am 9. September 2026 ist mir aufgefallen, dass genau dieser eine Socket seit l\u00e4ngerem daf\u00fcr sorgt, dass nginx f\u00fcr die H\u00e4lfte der Clients ein Bit im IP-Header nie setzt, das QUIC eigentlich zwingend braucht. Kein Absturz, keine Fehlermeldung, kein Eintrag im Error-Log. Nur ein messbar h\u00f6herer Anteil langsamer Verbindungen, der sich erst beim genauen Hinsehen als das entpuppt, was er ist.<\/p>\n\n\n\n Dieser Beitrag ist eine klassische Root-Cause-Analyse. Bug gefunden, Ursache im nginx-Quellcode verifiziert, Ursache zus\u00e4tzlich im FreeBSD-Kernel nachvollzogen, gefixt, mit echten Produktionsdaten so gut wie m\u00f6glich belegt.<\/p>\n\n\n\n Wer nginx mit QUIC betreibt, kennt die Direktive \u00fcblicherweise so:<\/p>\n\n\n\n Ein einziger IPv6-Socket mit Bei QUIC ist genau dieser eine Socket ein Problem, und zwar eines, das man im laufenden Betrieb nicht sieht. Zumindest nicht sofort und nicht \u00fcberall. Es m\u00fcssen schon ein paar Dinge zusammen kommen um das Problem selbst zu f\u00fchlen. F\u00fchlen? Eine lllaaaaannnngggggssssaaaaammmmeeeee Verbindung \u00fcber IPv4.<\/p>\n\n\n\n RFC 9000, Abschnitt 14<\/a>, formuliert das ziemlich hart:<\/p>\n\n\n\n UDP datagrams MUST NOT be fragmented at the IP layer. In IPv4, the Don’t Fragment (DF) bit MUST be set if possible, to prevent fragmentation on the path.<\/p>\n<\/blockquote>\n\n\n\n Das ist keine Empfehlung, das ist ein MUST NOT direkt neben einem MUST. QUIC ermittelt seine eigene passende Paketgr\u00f6\u00dfe f\u00fcr einen Netzwerkpfad, entweder \u00fcber klassisches PMTUD (das auf ICMP-Antworten angewiesen ist und auf der IP-Ebene ansetzt, das DF-Bit ist Teil genau dieses Mechanismus) oder \u00fcber DPLPMTUD nach RFC 8899<\/a>, das mit eigenen Sondierungspaketen arbeitet und ganz ohne ICMP auskommt. Wichtig ist hier nicht, welcher der beiden Mechanismen die Gr\u00f6\u00dfe ermittelt, sondern was beide voraussetzen: ein zu gro\u00dfes Paket muss sauber verworfen werden, mit oder ohne ICMP-Antwort, statt fragmentiert beim Empf\u00e4nger anzukommen. Wer sich jetzt an ICMPv6 f\u00fcr IPv6 erinnert f\u00fchlt, japp \ud83d\ude42<\/p>\n\n\n\n Genau das geht in vielen Netzen schief, sobald ein Paket doch fragmentiert wird. Fragment-Filterung ist eine verbreitete Firmen- und Provider-H\u00e4rtung, gerade weil fragmentierte Pakete historisch f\u00fcr allerlei Unfug missbraucht wurden. Solche Netze werfen fragmentierte QUIC-Pakete einfach weg, ohne jede R\u00fcckmeldung. QUICs eigene Verlusterkennung kann das von gew\u00f6hnlichem Paketverlust nicht unterscheiden, im schlechtesten Fall wird daraus eine Serie von Retransmissions und Timeouts statt eines schnellen, sauberen Fehlers. Bei TCP \u00fcber TLS w\u00fcrde ein fragmentiertes Paket in den allermeisten Netzen einfach ankommen und zusammengesetzt werden, das ist dort seit jeher normaler Betrieb und niemanden juckt das DF-Bit besonders. Bei QUIC ist Fragmentierung der Fall, den das Protokoll bewusst ausschlie\u00dfen will, und genau der tritt hier auf.<\/p>\n\n\n\n Der Fund steckt in Beide Zweige pr\u00fcfen Ein kleines Detail f\u00fcr alle, die selbst nachlesen: der IPv6-Fallback-Zweig (das Wer Der IPv6-Header hat schlicht kein DF-Bit, weil er keines braucht. RFC 8200<\/a> verbietet Routern im Pfad die Fragmentierung von IPv6-Paketen grunds\u00e4tzlich, das steht w\u00f6rtlich in Abschnitt 4.5 (der auf Abschnitt 5 verweist): „unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet’s delivery path“. Und jetzt der Punkt, an dem beide Welten aufeinandertreffen. Ein Die naheliegende Reaktion: warum ruft nginx auf diesem Socket nicht einfach zus\u00e4tzlich Der Options-Handler f\u00fcr einen Ein Das DF-Bit wird nur gesetzt, wenn am PCB (dem Protocol Control Block der Verbindung) das Flag Damit schlie\u00dft sich der Kreis \/ Beisst die Katze sich in den Schwanz, ihr wisst schon. Der Bug, wenn ich das so nennen darf, selbst sitzt im nginx-Quellcode und ist plattformunabh\u00e4ngig. Dieselbe Was sich unterscheidet, ist welche Socket-Option-API \u00fcberhaupt zur Verf\u00fcgung steht. Was ich nicht verifiziert habe, weil mir daf\u00fcr ein Linux-Vergleichssystem fehlt (ich zu faul war eines aus dem Glas zu ziehen): ob sich das praktische Fehlerbild zwischen den beiden Kerneln tats\u00e4chlich unterscheidet, also wie stark Retransmissions ausfallen oder wie der jeweilige Kernel beim v4-mapped-Sendepfad mit dem DF-\u00c4quivalent umgeht. Linux‘ PMTUD-Verhalten f\u00fcr genau diesen Fall k\u00f6nnte sich abweichend verhalten. Ehrliches Fazit an dieser Stelle: der nginx-Bug ist universell im Quellcode, das konkret beobachtete Fehlerbild ist hier ausschlie\u00dflich f\u00fcr FreeBSD dokumentiert. Eine Aussage wie „genauso kaputt auf Linux“ w\u00fcrde ich ohne echten Beleg, also Paketmitschnitt oder Kernel-Quellcode-Analyse auf einem Linux-System, nicht treffen. Vielleicht mache ich mir die M\u00fche noch…. Vielleicht \ud83d\ude00<\/p>\n\n\n\n Die L\u00f6sung ist, den einen Dual-Stack-Listener in zwei eigenst\u00e4ndige Listener zu splitten, damit IPv4-Clients einen echten Ein Stolperstein dabei, den man sich leicht selbst stellt: ein einfaches zus\u00e4tzliches Eine reine Nach dem Restart tauchte in der PROTO-Spalte ausschlie\u00dflich Der erste Durchlauf hat nur den Default-Server-Socket gesplittet. Alle anderen vHosts mit eigenem Die Lehre daraus: bei einem Das nginx-Error-Log auf Level Das ist methodisch wichtig: diese Alert-Meldungen enthalten das Wort „quic“ gar nicht. Ein reines Warum das Error-Log strukturell nicht mehr hergibt: nginx sendet das UDP-Datagramm erfolgreich an den Kernel, die Fragmentierung passiert danach im Netz, an einem Router oder einer Middlebox, oder schon beim sendenden Host selbst, falls das ausgehende Interface-MTU \u00fcberschritten wird. Davon bekommt der laufende nginx-Prozess in keinem Fall etwas mit. Wer nach diesem Bug im Error-Log sucht, wird nichts finden. Das ist erwartbar, nicht beruhigend, und ein blindes nginx zeigt IPv4-Clients, die \u00fcber einen Dual-Stack-Socket hereinkommen, im Access-Log als IPv4-mapped-Adresse ( Ausgewertet habe ich das Access-Log des Blogs (Format Die betroffene IPv4-Gruppe lag vorher bei 5,33 Prozent \u00fcber einer Sekunde, fast das Dreifache der IPv6-Baseline von 1,86 Prozent, und f\u00e4llt nach dem Fix auf 0,42 Prozent, unter die IPv6-Baseline von 2,14 Prozent im selben Zeitraum. Genau dieser Kontrollgruppen-Vergleich macht die Zahlen f\u00fcr mich aussagekr\u00e4ftig, als Korrelation, die zur quellcode-basierten Root-Cause-Analyse passt, nicht als eigenst\u00e4ndigen Fragmentierungsbeweis.<\/p>\n\n\n\n Eine zeitliche Punktprobe passt ins Bild: Restart am 9. September 2026 um 18:38:31 Uhr, letzter Request \u00fcber den kaputten Dual-Stack-Pfad um 17:56:46 Uhr, erster Request \u00fcber den neuen Pfad um 18:41:36 Uhr. Seit dem Restart lief keiner der 946 IPv4-HTTP\/3.0-Requests mehr \u00fcber die alte Darstellung. Das liegt plausibel am Restart-Zeitpunkt, mit einer L\u00fccke ohne Traffic dieser Art von 42 Minuten davor und 3 Minuten danach bis zum ersten neuen Request, aber es ist kein exakter Sekundentreffer und ich beschreibe es auch nicht so.<\/p>\n\n\n\n Genauso wichtig wie die Zahlen sind f\u00fcr mich ihre Grenzen, deshalb ein eigener Absatz daf\u00fcr statt eines Nebensatzes:<\/p>\n\n\n\n Nachtrag vom 12. September 2026: Der vorherige Abschnitt musste ohne einen echten Paketmitschnitt auskommen. Der liegt inzwischen vor. Zwei rund 41 Sekunden lange Aufzeichnungen vom 8. September 2026, einen Tag vor dem Fix, eine direkt auf dem Server, die andere gleichzeitig auf einem Notebook, das die Seite \u00fcber ein anderes Netz aufgerufen hat. Beide zusammen zeigen den echten HTTP\/3-Verkehr eines einzelnen Seitenaufrufs.<\/p>\n\n\n\n Ausgewertet mit Der QR-Code, einmal nachgemessen<\/h3>\n\n\n\n
![\"Keyoxide-App](\"https:\/\/www.kernel-error.de\/wp-content\/uploads\/2026\/09\/keyoxide-flatpak-qr-code.png\")
<\/a>kernel-error@kernel-error.com<\/code> ergibt sha1(\"kernel-error\")<\/code>, Z-Base-32-kodiert, exakt 3gyjbxx9xfdggpkmx5qdd793xy431w5u<\/code>, also genau der Wert im Key Link. Zweitens der Inhalt: die Datei unter diesem Pfad l\u00e4sst sich herunterladen und mit gpg --show-keys<\/code> auswerten, der Fingerabdruck darin ist 45FC D081 ADB5 4872 EA5B 06B9 893D E0CD DE98 6DEB<\/code>, derselbe wie im Screenshot und derselbe wie der seit Juli aktuelle Schl\u00fcssel. Der QR-Code zeigt also tats\u00e4chlich auf die richtige, aktuelle Datei, nicht auf einen Cache-Stand oder eine falsche Kodierung.<\/p>\n\n\n\nEin Matrix-Kanal f\u00fcr Fragen<\/h3>\n\n\n\n
Siehe auch<\/h3>\n\n\n\n
\n
![\"nginx](\"https:\/\/www.kernel-error.de\/wp-content\/uploads\/2026\/09\/quic-nginx-1024x576.png\")
<\/a><\/figure>\n<\/div>\n\n\nEin Socket f\u00fcr beides, das ist doch die naheliegende Wahl<\/h3>\n\n\n\n
listen [::]:443 quic reuseport ipv6only=off default_server;<\/pre>\n\n\n\n
ipv6only=off<\/code> nimmt sowohl echte IPv6-Verbindungen als auch IPv4-Verbindungen an, dank IPv4-mapped-IPv6-Adressen (::ffff:a.b.c.d<\/code>) nach RFC 3493<\/a>. Ein Socket statt zwei, eine Zeile Konfiguration weniger. Genau deshalb ist das die naheliegende Wahl, wenn man von TCP kommt, wo dieser Trick seit Jahrzehnten problemlos funktioniert.<\/p>\n\n\n\nWarum QUIC bei Fragmentierung empfindlicher ist als TCP \u00fcber TLS<\/h3>\n\n\n\n
\n
Die Ursache, gefunden im nginx-Quellcode<\/h3>\n\n\n\n
src\/core\/ngx_connection.c<\/code><\/a>, in der Funktion ngx_configure_listening_sockets()<\/code> (nicht zu verwechseln mit ngx_open_listening_sockets()<\/code>, einer anderen Funktion in derselben Datei, die die Sockets \u00f6ffnet, aber nicht die MTU-Discovery-Optionen setzt). Diese Funktion l\u00e4uft beim Start und bei jedem Restart \u00fcber alle bereits gebundenen Listen-Sockets und setzt dort die passenden Socket-Optionen. Der entscheidende Ausschnitt, w\u00f6rtlich aus nginx 1.30.4:<\/p>\n\n\n\n#if (NGX_HAVE_IP_MTU_DISCOVER)\n\n if (ls[i].quic && ls[i].sockaddr->sa_family == AF_INET) {\n value = IP_PMTUDISC_DO;\n\n if (setsockopt(ls[i].fd, IPPROTO_IP, IP_MTU_DISCOVER,\n (const void *) &value, sizeof(int))\n == -1)\n {\n ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_socket_errno,\n \"setsockopt(IP_MTU_DISCOVER) \"\n \"for %V failed, ignored\",\n &ls[i].addr_text);\n }\n }\n\n#elif (NGX_HAVE_IP_DONTFRAG)\n\n if (ls[i].quic && ls[i].sockaddr->sa_family == AF_INET) {\n value = 1;\n\n if (setsockopt(ls[i].fd, IPPROTO_IP, IP_DONTFRAG,\n (const void *) &value, sizeof(int))\n == -1)\n {\n ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_socket_errno,\n \"setsockopt(IP_DONTFRAG) \"\n \"for %V failed, ignored\",\n &ls[i].addr_text);\n }\n }\n\n#endif\n\n#if (NGX_HAVE_INET6)\n\n#if (NGX_HAVE_IPV6_MTU_DISCOVER)\n\n if (ls[i].quic && ls[i].sockaddr->sa_family == AF_INET6) {\n value = IPV6_PMTUDISC_DO;\n\n if (setsockopt(ls[i].fd, IPPROTO_IPV6, IPV6_MTU_DISCOVER,\n (const void *) &value, sizeof(int))\n == -1)\n {\n ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_socket_errno,\n \"setsockopt(IPV6_MTU_DISCOVER) \"\n \"for %V failed, ignored\",\n &ls[i].addr_text);\n }\n }\n\n#elif (NGX_HAVE_IP_DONTFRAG)\n\n if (ls[i].quic && ls[i].sockaddr->sa_family == AF_INET6) {\n value = 1;\n\n if (setsockopt(ls[i].fd, IPPROTO_IPV6, IPV6_DONTFRAG,\n (const void *) &value, sizeof(int))\n == -1)\n {\n ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_socket_errno,\n \"setsockopt(IPV6_DONTFRAG) \"\n \"for %V failed, ignored\",\n &ls[i].addr_text);\n }\n }\n\n#endif\n#endif<\/pre>\n\n\n\nls[i].sockaddr->sa_family<\/code>, also die Adressfamilie des Listen-Sockets selbst, fest zum Zeitpunkt des Socket-Setups. Nicht die Familie des Ziels, an das ein bestimmtes Paket sp\u00e4ter geht. F\u00fcr listen [::]:443 quic ... ipv6only=off;<\/code> ist sa_family<\/code> immer AF_INET6<\/code>, egal ob ein konkretes Paket an einen echten IPv6-Host oder an eine IPv4-mapped-Adresse geht. Der AF_INET<\/code>-Zweig, der IP_DONTFRAG<\/code> f\u00fcrs echte IPv4-Datagramm setzen w\u00fcrde, wird f\u00fcr diesen Socket schlicht nie erreicht.<\/p>\n\n\n\n#elif (NGX_HAVE_IP_DONTFRAG)<\/code> im letzten Block) ist mit demselben Feature-Makro abgesichert wie der IPv4-Zweig, nicht mit dem separat getesteten NGX_HAVE_IPV6_DONTFRAG<\/code>. Auf FreeBSD \u00e4ndert das am Ergebnis nichts, hier sind beide Makros gesetzt, aber es ist eine kleine Ungenauigkeit im nginx-Quellcode selbst. So zumindest meine Interpretation, korrigiert mich gerne!<\/p>\n\n\n\nDer eigentliche Denkfehler dahinter: IPv6 hat gar kein DF-Bit<\/h3>\n\n\n\n
IPV6_DONTFRAG<\/code> im Code sieht, k\u00f6nnte annehmen, dass damit dasselbe Problem f\u00fcr IPv6 gel\u00f6st wird wie IP_DONTFRAG<\/code> f\u00fcr IPv4. Ist es nicht, und der Unterschied ist der eigentliche Kern dieses Bugs.<\/p>\n\n\n\nIPV6_DONTFRAG<\/code> ist die tats\u00e4chliche RFC-3542-Option, Abschnitt 11.2<\/a> der Spezifikation, aber sie steuert nur, ob der sendende Host selbst \u00fcber einen Fragment-Extension-Header fragmentieren darf. Ein Problem, das aus Sicht von IPv6 gar nicht existiert, sobald man es nicht selbst provoziert.<\/p>\n\n\n\nIP_DONTFRAG<\/code> auf der IPv4-Seite ist dagegen keine RFC-3542-Option, sondern eine BSD-Socket-Erweiterung au\u00dferhalb dieses Standards. Zwei Optionen, die im Code wie ein symmetrisches Paar aussehen, l\u00f6sen in Wirklichkeit zwei v\u00f6llig verschiedene Probleme.<\/p>\n\n\n\nsend()<\/code> auf diesem IPv6-Socket an eine IPv4-mapped-Zieladresse bringt am Ende ein echtes IPv4-Datagramm auf die Leitung, das ist Standardverhalten von Dual-Stack-Sockets nach RFC 3493. Dieses Datagramm braucht ein gesetztes DF-Bit im IPv4-Header, ein komplett anderes Feld als alles, was IPV6_DONTFRAG<\/code> je anfasst. Der oben gezeigte Code-Pfad kommt an dieses Feld nie heran, weil er f\u00fcr einen AF_INET6<\/code>-Socket ausschlie\u00dflich die IPv6-Variante der Option setzt. Kann man das also auch irgendwie ein legacy IPv4 Problem nennen?<\/p>\n\n\n\nWarum ein einfacher Zusatz-Aufruf auf FreeBSD gar nicht helfen w\u00fcrde<\/h3>\n\n\n\n
setsockopt(IPPROTO_IP, IP_DONTFRAG)<\/code> auf? Ich bin dem im FreeBSD-Kernel-Quellcode nachgegangen, und die Antwort ist, dass das auf FreeBSD gar nicht funktionieren w\u00fcrde.<\/p>\n\n\n\nAF_INET6<\/code>-Socket ist ip6_ctloutput()<\/code> in sys\/netinet6\/ip6_output.c<\/code><\/a>, und der lehnt Optionen au\u00dferhalb von IPPROTO_IPV6<\/code> rundweg ab:<\/p>\n\n\n\nlevel = sopt->sopt_level;\n...\nif (level != IPPROTO_IPV6) {\n error = EINVAL;\n ...\n}<\/pre>\n\n\n\nsetsockopt(fd, IPPROTO_IP, IP_DONTFRAG, ...)<\/code> auf einem AF_INET6<\/code>-Socket landet also mit EINVAL<\/code> im Nichts. Das allein w\u00e4re schon Antwort genug, aber der zweite Teil ist genauso wichtig: wo genau setzt der Kernel das DF-Bit f\u00fcr einen IPv4-mapped-Send, der \u00fcber einen IPv6-Socket rausgeht? In udp_usrreq.c<\/code><\/a>, in der Funktion, die das eigentliche IPv4-UDP-Paket zusammenbaut:<\/p>\n\n\n\nif (inp->inp_flags & INP_DONTFRAG)\n ((struct ip *)ui)->ip_off |= htons(IP_DF);<\/pre>\n\n\n\n
INP_DONTFRAG<\/code> h\u00e4ngt. Und dieses Flag setzt ausschlie\u00dflich ip_ctloutput()<\/code> in ip_output.c<\/code>, wenn IP_DONTFRAG<\/code> auf IPPROTO_IP<\/code>-Ebene erfolgreich gesetzt wurde, also genau der Aufruf, der auf einem AF_INET6<\/code>-Socket mit EINVAL<\/code> scheitert. Der IPv4-mapped-Sendepfad selbst f\u00fchrt \u00fcbrigens tats\u00e4chlich \u00fcber genau diese Funktion: udp6_send()<\/code> in udp6_usrreq.c<\/code><\/a> erkennt eine v4-mapped-Zieladresse auf einem Dual-Stack-Socket, gibt die eigenen Locks frei und ruft direkt udp_send()<\/code>, also dieselbe IPv4-UDP-Ausgabefunktion, die auch ein echter AF_INET<\/code>-Socket benutzt.<\/p>\n\n\n\nINP_DONTFRAG<\/code> kann nur \u00fcber einen erfolgreichen IP_DONTFRAG<\/code>-Aufruf auf einem echten AF_INET<\/code>-Socket gesetzt werden, und ein AF_INET6<\/code>-Socket kann diesen Aufruf laut ip6_ctloutput()<\/code> gar nicht erst absetzen. Der Socket-Split ist auf FreeBSD damit nicht nur der pragmatische, sondern der einzig m\u00f6gliche Fix. Ein hypothetischer nginx-Patch, der einfach den fehlenden setsockopt<\/code>-Aufruf erg\u00e4nzt, w\u00fcrde am Kernel selbst scheitern, bevor er \u00fcberhaupt etwas bewirkt.<\/p>\n\n\n\nWas sich zwischen FreeBSD und Linux unterscheidet, und was nicht<\/h3>\n\n\n\n
sa_family<\/code>-Abfrage wird auf Linux und FreeBSD gleich kompiliert und ist auf beiden gleicherma\u00dfen falsch.<\/p>\n\n\n\nIP_MTU_DISCOVER<\/code> mit dem Wert IP_PMTUDISC_DO<\/code> ist eine Linux-Erweiterung (auch musl bringt das Makro mit, nicht nur glibc), auf FreeBSD schlicht nicht deklariert. FreeBSD bietet stattdessen IP_DONTFRAG<\/code> und IPV6_DONTFRAG<\/code>. nginx testet im configure<\/code>-Lauf beide Varianten (auto\/unix<\/code>, Feature-Tests f\u00fcr NGX_HAVE_IP_MTU_DISCOVER<\/code>, NGX_HAVE_IP_DONTFRAG<\/code>, NGX_HAVE_IPV6_DONTFRAG<\/code>) und w\u00e4hlt zur Kompilierzeit die passende Variante. Auf dieser FreeBSD-Installation landet man im IP_DONTFRAG<\/code>\/IPV6_DONTFRAG<\/code>-Zweig, und genau der ist von dem oben beschriebenen Bug betroffen.<\/p>\n\n\n\nDer Fix: zwei Listener statt einem<\/h3>\n\n\n\n
AF_INET<\/code>-Socket bekommen, f\u00fcr den der obere Codepfad tats\u00e4chlich greift:<\/p>\n\n\n\nlisten [::]:443 quic reuseport ipv6only=on default_server;\nlisten 443 quic reuseport default_server;<\/pre>\n\n\n\n
listen 443 quic;<\/code> neben einem unver\u00e4nderten Dual-Stack-Socket kollidiert mit „Address already in use“, weil der alte Socket die IPv4-Wildcard-Adresse \u00fcber ipv6only=off<\/code> ja schon abdeckt. ipv6only<\/code> muss auf dem IPv6-Listener also explizit auf on<\/code> gesetzt werden, sonst gibt es keinen sauberen Split, sondern nur einen Fehlstart. Je nachdem, wie „ordentlich“ seine Konfiguration ist, kann es einen Moment dauern, alle diese Stellen zu finden, denn das muss f\u00fcr die komplette nginx Konfiguration angepasst sein!<\/p>\n\n\n\nErster Stolperstein: ein reload reicht nicht<\/h3>\n\n\n\n
ipv6only<\/code>-\u00c4nderung an einem bestehenden QUIC-Socket erkennt nginx‘ Socket-Reuse-Logik bei einem reload<\/code> nicht als neuen Socket. Bei mir blieb der alte Dual-Stack-Socket nach einem reinen reload<\/code> laut sockstat<\/code> weiter als udp46<\/code> aktiv, trotz fehlerfrei gepr\u00fcfter Konfiguration (nginx -t<\/code>) und trotz eines nginx -T<\/code>-Dumps, der die neue Konfiguration bereits korrekt anzeigte. Ist bei solchen Dingen hin und wieder so, machen andere Dienste ja auch. Gro\u00dfe Dinge wie Socket, wird oft nur bei einem echten Neustart vom Deinst gesetzt.<\/p>\n\n\n\nnginx -t<\/code> pr\u00fcft Syntax und versucht, referenzierte Dateien zu \u00f6ffnen. Es sagt nichts dar\u00fcber aus, ob ein bereits offener, laufender Listen-Socket bei einem Reload tats\u00e4chlich neu gebunden wird. Erst ein vollst\u00e4ndiger service nginx restart<\/code> hat die getrennten Sockets tats\u00e4chlich neu gebunden:<\/p>\n\n\n\nsockstat -4 -l | grep 443 # nur udp4\nsockstat -6 -l | grep 443 # nur udp6<\/pre>\n\n\n\n
udp4<\/code> und udp6<\/code> auf, kein einziges udp46<\/code> mehr auf Port 443. Das ist der eigentliche Beleg f\u00fcr den Reload-Stolperstein, keine Datei-Deskriptor-Analyse, nur der Blick auf einen laufenden Prozess. Das reiht sich in ein Muster ein, das mir auf dieser Infrastruktur schon \u00f6fter untergekommen ist: ein neues geladenes Modul, ein neuer server_name<\/code> in einer bestehenden reuseport<\/code>-Gruppe, jetzt ein ipv6only<\/code>-Wechsel. Immer wieder dasselbe Grundmuster, ein Reload reicht bei bestimmten \u00c4nderungen an Listen-Sockets schlicht nicht. Aber ich wiederhole mich, hm?<\/p>\n\n\n\nZweiter Stolperstein: jeder vHost braucht den Split<\/h3>\n\n\n\n
listen [::]:443 quic;<\/code>, aber ohne eigenes listen 443 quic;<\/code>, hingen danach nur noch am neuen IPv6-only-Socket. IPv4-QUIC-Verbindungen zu diesen Domains landeten beim Default-vHost, weil die SNI-Zuordnung auf dem neuen IPv4-Socket schlicht ins Leere lief. Sichtbar wurde das am falschen ausgelieferten TLS-Zertifikat und an einer Default-Antwort statt der eigentlich erwarteten.<\/p>\n\n\n\nreuseport<\/code>-Split m\u00fcssen alle Server-Bl\u00f6cke der Adressgruppe angepasst werden, nicht nur der Default-Server. Der IPv4-Listener eines jeden weiteren vHosts docken danach ohne reuseport<\/code> und ohne default_server<\/code> einfach an die schon bestehende Gruppe an:<\/p>\n\n\n\nlisten [::]:443 quic;\nlisten 443 quic;<\/pre>\n\n\n\n
Was im Error-Log nicht zu finden ist<\/h3>\n\n\n\n
info<\/code>, die komplette 15-Tage-Rotation samt .bz2<\/code>-Archiven, enth\u00e4lt keine einzige [warn]<\/code>, [error]<\/code> oder [crit]<\/code>-Zeile mit QUIC-Bezug, weder vor noch nach dem Fix. Eine gezielte Suche nach den vier exakten Alert-Meldungen, die der oben zitierte Code beim Fehlschlagen eines setsockopt<\/code>-Aufrufs loggen w\u00fcrde, kommt in der gesamten Historie null Mal vor. Vielleicht sollte ich das noch im Logging aufbohren, wenn m\u00f6glich?!<\/p>\n\n\n\ngrep -i quic<\/code> im Error-Log h\u00e4tte einen echten Fehlschlag dieser Aufrufe also gar nicht gefunden, selbst wenn es einen gegeben h\u00e4tte. Erst die gezielte Suche nach dem exakten Meldungstext schlie\u00dft aus, dass die Socket-Optionen fehlgeschlagen sind. Sie wurden erfolgreich gesetzt, nur eben die falsche Option f\u00fcr die falsche Adressfamilie. Kein Aufruf-Fehler, sondern genau der beschriebene Bug.<\/p>\n\n\n\ngrep quic<\/code> h\u00e4tte selbst einen echten Konfigurationsfehler an dieser Stelle \u00fcbersehen. Genau das ist der Punkt. Man sieht es am Server fast nur, wenn man auch einen tcpdump macht und auswertet. Denn die UDP Pakete gehen ja auf die Reise, sind sie nicht als „unzerteilbar“ markiert, kann und wird auf dem Weg aber bestimmt irgendein Router oder eine Firewall anfangen die Pakete klein zu hacken und dann ist es „kaputt“.<\/p>\n\n\n\nVerifikation \u00fcber das Access-Log, und ihre Grenzen<\/h3>\n\n\n\n
::ffff:a.b.c.d<\/code>). Nach dem Fix kommen IPv4-QUIC-Clients \u00fcber einen echten AF_INET<\/code>-Socket herein und erscheinen als reine IPv4-Adresse ohne dieses Pr\u00e4fix. Diese Darstellung allein beweist schon, durch welchen Socket eine Verbindung lief, unabh\u00e4ngig von jeder Performance-Messung, aber eben auch unabh\u00e4ngig von jeder direkten Fragmentierungs-Messung.<\/p>\n\n\n\ngoa_ext<\/code>, enth\u00e4lt $request_time<\/code>), 13 Tage vor dem Fix plus den laufenden Tag danach, alle HTTP\/3.0<\/code>-Requests, aufgeteilt nach Adressdarstellung:<\/p>\n\n\n\nZeitraum<\/th> Requests<\/th> \u00d8 request_time<\/th> Max<\/th> Anteil \u00fcber 1 s<\/th><\/tr><\/thead> vorher, IPv4 \u00fcber kaputten Dual-Stack-Socket<\/td> 12.537<\/td> 0,461 s<\/td> 130,3 s<\/td> 5,33 %<\/td><\/tr> nachher, IPv4 \u00fcber eigenen udp4-Socket<\/td> 946<\/td> 0,037 s<\/td> 1,4 s<\/td> 0,42 %<\/td><\/tr> Kontrollgruppe, natives IPv6, vorher<\/td> 17.320<\/td> 0,113 s<\/td> 67,3 s<\/td> 1,86 %<\/td><\/tr> Kontrollgruppe, natives IPv6, nachher<\/td> 1.168<\/td> 0,082 s<\/td> 5,7 s<\/td> 2,14 %<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n \n
$remote_addr<\/code> umschreiben k\u00f6nnte.<\/li>\n\n\n\nEin Paketmitschnitt vom Tag vor dem Fix schlie\u00dft einen Teil der L\u00fccke<\/h3>\n\n\n\n
tcpdump -r <Datei> -n -v<\/code>, ein tshark<\/code> stand mir nicht zur Verf\u00fcgung. Jedes Paket tr\u00e4gt im IP-Header ein Identification-Feld, und das ist in beiden Mitschnitten innerhalb des Beobachtungsfensters durchgehend eindeutig, keine einzige Dopplung unter den mehr als dreitausend vom Server verschickten Paketen. Dar\u00fcber lassen sich einzelne Datagramme zwischen den beiden Aufzeichnungen zweifelsfrei einander zuordnen, nicht nur \u00fcber Summen vergleichen.<\/p>\n\n\n\n
![\"Aptio](\"https:\/\/www.kernel-error.de\/wp-content\/uploads\/2026\/08\/s236.png\")
<\/figure>\n<\/div>\n\n\n![\"Aptio](\"https:\/\/www.kernel-error.de\/wp-content\/uploads\/2026\/08\/s235.png\")
<\/figure>\n<\/div>\n\n\n![\"Aptio](\"https:\/\/www.kernel-error.de\/wp-content\/uploads\/2026\/08\/s237.png\")
<\/figure>\n<\/div>\n\n\n