ipv 4 and 6

[Paul]

Hello Max,

On 2026-07-29 21:00, Maxim Dounin wrote:
> 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?

[snip]
> 
> 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.

Many thanks. It was certainly not a pure nginx problem.  Given the 
difficulties, we had opened up the relevant w3c-related AWS (far east) 
addresses (UFW, IPtables and nginx) and emailed W3C (no reply, but might 
have caught their attention.)  A few days later (after significant AWS 
abuse from those blocks), closed them down, retained only the "allow" on 
443 from 52.22.66.203 (also AWS as you noted), and we're back to 
previous full functionality.

It would be hard now for me to "backward analyze" -- our daily nginx 
access.logs normally run 15-20Gb before .gz on rotate.

Again, many thanks and regards,
Bolshoye spaceeba,
Paul

   \\\||//
    (@ @)
ooO_(_)_Ooo__________________________________
|______|_____|_____|_____|_____|_____|_____|_____|
|___|____|_____|_____|_____|_____|_____|_____|____|
|_____|_____| mailto:paul at stormy.ca _|____|____|