Title: Port 443 (HTTPS) blocked at the network level on a Lightsail instance, despite correct firewall config

Symptom: Until early this morning, my Lightsail instance was reachable over HTTPS (port 443) without any issues. Since then, port 443 has become completely unreachable from the outside world. Every other port I've tested — 22 (SSH), 80 (HTTP), and two ports I opened purely for testing (8080, 8443) — works perfectly. Only 443 is affected.

What I've verified:

1. Inside the instance, ss -tlnp confirms nginx (running in a Docker container, proxied via docker-proxy) is listening correctly on both 0.0.0.0:443 and [::]:443.

2. In the Lightsail console, under Networking > Firewall rules, I have a rule for TCP 443, source 0.0.0.0/0 (Anywhere IPv4), configured correctly. I've tried both the built-in "HTTPS" preset and a manually added "Custom" TCP 443 rule — same result either way. I've also deleted and recreated the rule, rebooted the instance, and detached/reattached the static IP. None of this changed the outcome.

3. I tested from three independent networks (home Wi-Fi, mobile LTE, and a third-party port checker at yougetsignal.com) — all three report port 443 as closed. As a control, I opened a new port (8080) using the exact same firewall panel, and it opened instantly and worked from all three networks. This confirms the firewall rule mechanism itself is functioning normally; it's specifically the existing 443 rule that isn't taking effect.

4. The instance's own OS-level firewall (ufw) is inactive. sudo iptables -L -n -v shows no blocking rules in the INPUT chain (default ACCEPT, no explicit rules), and the Docker NAT/forwarding rules correctly ACCEPT and forward traffic on port 443 to the nginx container (I can see matched packet counters on that rule). So the OS and Docker networking layers are correctly configured to pass 443 traffic through, if it ever arrives.

5. The TLS certificate (Let's Encrypt, covering steeljoon.store, www.steeljoon.store, and api.steeljoon.store) is valid and not expiring for months.

6. I've ruled out account/security issues as a cause: no abuse notifications in my account email, CPU and network in/out metrics in the Lightsail console are flat and unremarkable before and after the outage began, VPC peering is disabled (so no EC2 security group could be involved), and the AWS Health Dashboard shows no open issues for Lightsail in ap-northeast-2.

Additional tests:

• I mapped the same nginx container's SSL config to port 8443 (host 8443 -> container 443) and tested from outside the instance. TLS handshake, certificate validation, and the HTTP 200 response from the app all completed successfully.

• From inside the instance itself, I ran curl -v https://localhost:443 -k, hitting port 443 by its literal number via loopback. This also completed a full TLS handshake and returned a valid HTTP 200 response with the expected application content.

Taken together, these two tests show that neither TLS itself nor anything about the host's own port-443 binding is broken — the exact same nginx process and certificate work flawlessly on 8443, and even work on 443 when accessed via loopback. The failure only occurs on the path between the public internet and this instance, specifically for traffic destined for port 443. Nothing else about the port number, protocol, or application appears to matter.

Request: Could someone from AWS look into what's filtering inbound traffic to port 443 specifically, on this instance, at the network layer in front of it? I'd appreciate help identifying and clearing whatever is causing this, since everything I can control or inspect from the console and the instance itself checks out.