On 2026-07-29 16:08, Maxim Dounin wrote:
Hello!
On Wed, Jul 29, 2026 at 11:40:39AM -0400, Paul wrote:
nginx/1.18.0 (Ubuntu). For decades we have never explicitly "listened" for
1pv6, using only "listen 443 ssl;" on a couple of dozen websites.
As of two days ago, W3C (world wide web consortium) html, css, etc
verification tools are no longer functional -- our websites "time out" "500
Can't connect to mysite.com:443 (Connection timed out)"
W3C have nslookup showing ipv4 and ipv6 addresses. There is nothing in our
firewalls "denying" them, there is nothing in the nginx logs.
I'm reticent to just add trillions of ipv6 possibilities of abuse (we're
experiencing om/off ddos attacks from ai/automated/bots to the tune of
56^6/day).
Any thoughts?
So, your website names resolves to both IPv4 and IPv6 addresses,
but you don't have any IPv6 listens, correct?
Maxim, many thanks. This might, or not, be IPv6 related
Our names only resolve to IPv4 (static 70.52.195.238 for nearly thirty
years.) For example:
CLI curl https://ultramarine.ca is functional through nginx proxied to
apache2
But
<https://validator.w3.org/check?uri=https%3A%2F%2Fultramarine.ca&charset=%28detect+automatically%29&doctype=Inline&group=0>
returns "500 Can't connect to ultramarine.ca:443 (Connection timed out)"
and if I do a curl ultramarine.ca:443 on that same exact url I get
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx</center>
So W3C are reporting "time out" and nginx is apparently sending "400"
There is nothing in the nginx access or error logs
Spaseeba ee dobrey vyecher
Paul
This looks like a configuration error to me, and the fact that W3C
tools fail isn't surprising. There are two obvious solutions:
either add relevant IPv6 listen directives, or remove the IPv6
addresses from the website names.
