SSL (+ nginx) suddenly stopped working / site unreachable "took too long to respond"


I noticed yesterday that my small, personal blog wasn’t reachable anymore at its usual url of, with error “… took too long to respond”.

Everything was working the last time I checked, a few weeks ago. Today I wanted to write some posts and found out that the site isn’t reachable anymore except when using the local IP of the machine (a Raspberry Pi 4 running Raspbian Bullseye) and I can’t see it in full because every file and image is sent through https and consequently at the moment doesn’t show up. Also, whenever connected my browsers (Safari and Chrome both) give me an error regarding the certificate (which I had generated using Certbot/Letsencrypt).

It’s really frustrating because I haven’t touched anything in any configuration; I may have shut down or rebooted the Pi in these last few weeks, though. Anyway, I tried to understand what’s going on, but I can’t seem to.

Everything (except for nginx) is running in Docker containers. Here’s my docker-compose.yml for further info:

version: '3.3'

    image: arm64v8/ghost:latest
    restart: always
      - 8080:2368
      - ./data/content:/var/lib/ghost/content
      # see
      TZ: Europe/Rome
      database__client: mysql
      database__connection__host: DB
      database__connection__user: USER
      database__connection__password: PASSWORD
      database__connection__database: DBNAME
      NODE_ENV: production
      mail__transport: SMTP
      mail__options__service: Gmail
      mail__options__port: 465
      mail__options__secure: "true"
      mail__options__auth__user: "MAIL"
      mail__options__auth__pass: "PASSWORD"

    image: arm64v8/mysql:oracle
    restart: always
      - ./data/db:/var/lib/mysql
      - "13928:3306"
      TZ: Europe/Rome

I get no errors when Ghost starts up (command used: docker logs [container name]):

[2022-07-10 12:08:48] INFO Ghost is running in production...
[2022-07-10 12:08:48] INFO Your site is now available on
[2022-07-10 12:08:48] INFO Ctrl+C to shut down
[2022-07-10 12:08:48] INFO Ghost server started in 5.269s
[2022-07-10 12:08:49] INFO Database is in a ready state.

Database I’m using is mySQL, also in a Docker container.
I’m suspecting that nginx might the problem, but again, nothing was touched.

Here’s what I have in my /etc/nginx/sites-available/ configuration:

server {

    listen 443 ssl;
    ssl_certificate /etc/letsencrypt/live/; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/; # managed by Certbot

	ssl_session_cache  builtin:1000  shared:SSL:10m;
	ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
	ssl_prefer_server_ciphers on;


    client_max_body_size 5M;

    access_log /var/log/nginx/blog.log;
    error_log  /var/log/nginx/blog-error.log error;

    location / {

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_pass http://localhost:8080;
        proxy_redirect http://localhost:8080;


Port 443 is open in my router configurations and in ufw too. I also tried disabling ufw to see if that was the problem, but nothing changed.

I’m unsure if more configurations or files could be useful here so I’ll just wait for some tips on where and what I can look up.

Thank you!

It looks like you’re using dynamic DNS, so I’d check that this is functional. Maybe the host server has changed IP, and you’re forwarding 443 to the wrong destination?

If you’re using the IP on your LAN, this is to be expected. Add the host to you hosts file, and you should resolve correctly.

1 Like

I had checked that my dDNS was working yesterday too, but a more in depth check resulted in me finding out that the public address that the dDNS was supposed to update… had not been updated.
Even though I had repeatedly and manually asked for an update, I had to grab my newly discovered current public IP and manually paste it in the configuration, replacing the old one. Very weird thing and it had not happened before; the service of the No-Ip DUC never had any issues.

I figured this out by running a simple:


and noticing that the IP under the “ANSWER SECTION” wasn’t my current public IP.

So essentially, your suggestion actually solved the problem. I was losing my sanity over this, and turns out it was such a small thing…! Thank you. Also thanks for the tip about the hosts file.

1 Like

It’s good to learn that the matter is resolved. Please mark my post as the solution. Thanks.

I’d love to, but I can’t seem to find a way to do so. :sweat_smile: Hint please?