English Posts

Containerized Ghost: Fixing the ‘Content Must Be Served Over HTTPS’ Mixed Content Error

Joel Tejeda

— 1 min read
Containerized Ghost: Fixing the ‘Content Must Be Served Over HTTPS’ Mixed Content Error
Photo by David Pupăză / Unsplash

A little bit of a background on how I ended up having this error:

💡
My infrastructure is running a containerized version of Ghost using Docker Compose. The application is deployed behind a containerized Nginx reverse proxy that handles HTTPS termination using Let's Encrypt certificates. In this setup, the reverse proxy is responsible for serving the site over HTTPS while the Ghost container itself communicates internally over HTTP.

Everything appeared to be working correctly at first. The site loaded over HTTPS without issues, but when accessing certain features — particularly the members portal — the browser began blocking requests due to a Mixed Content error. The page was served securely over HTTPS, but Ghost was attempting to request internal API resources over HTTP.

This resulted in me doing a network inspect inside google chrome and the following error showed up:

Mixed Content: The page at 'https://training-stack.com'
was loaded over HTTPS, but requested an insecure resource
'http://training-stack.com/members/api/member/'.
This request has been blocked; the content must be served over HTTPS.

Why this happens?
Short answer:
Ghost generates URLs based on the configured site URL, not the proxy.

Long answer:
This usually happens when Ghost is running behind a reverse proxy that handles SSL (like Nginx or nginx-proxy). If the Ghost url configuration is set to http:// instead of https://, Ghost will generate internal API requests using HTTP, even though the public site is served over HTTPS.

Step 1 — Update Ghost URL inside the Docker-Compose, Dockerfile or Env.

GHOST_URL=https://yourdomain.com

Step 2 — Ensure Ghost trusts the proxy:

server__trustProxy: "true"

Step 3 — Recreate the container:

docker compose down
docker compose up -d --force-recreate ghost

Issues like this are common when applications run behind reverse proxies. The key takeaway is that the application must know the public URL being used, even if SSL is handled externally.

Dictionary:
Reverse Proxy is a server that sits between the user and your application.
What's the use of it?

  • To allow multiple services running in one server.
  • Handling HTTPs
  • Security and rate limiting
  • Load Balancing

Read more