ipv 4 and 6

[Maxim Dounin]

Hello!

On Wed, Jul 29, 2026 at 08:26:18PM -0400, Stormy Weather wrote:

> 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"

It looks like 400 as shown by curl is due to no HTTPS protocol 
specified to curl.  Try "curl https://ultramarine.ca:443" instead, 
or just "curl https://ultramarine.ca".

> There is nothing in the nginx access or error logs

I suspect the "Can't connect" error as reported by validator is 
real, and the question is where the connection is dropped.

In my tests, validator requests look like:

52.22.66.203 - - [30/Jul/2026:03:50:30 +0300] "GET /?validator HTTP/1.1" 200 1893 "-" "W3C_Validator/1.3 libwww-perl/6.78"

The IP seems to be fixed, but it belongs to the AWS netblock, so 
might be banned at various levels due to hostile AI-scraping.  As 
a first step I would recommend checking with tcpdump on the 
incoming interface if packets arrive from the IP address at all 
when you start validation, and then start digging either into the 
host configuration or into the network.

> Spaseeba ee dobrey vyecher

:)

-- 
Maxim Dounin
http://mdounin.ru/