阅读中文版本

Mixed Content Blocked — HTTPS Page Loading HTTP Resource

Fix mixed content blocking by serving all subresources over HTTPS, updating hardcoded http URLs, and using protocol-relative or same-origin paths.

DevTools → Console → filter "Mixed Content"

grep -rn "http://" src/ public/

Symptoms

This debugging guide addresses “Mixed Content Blocked — HTTPS Page Loading HTTP Resource”. Start from the symptoms, follow the ordered diagnostics, and confirm each hypothesis before moving on; the fix and verification steps then close the loop.

Observed symptoms include:

• Console: “Mixed Content: The page at https://… was loaded over HTTPS, but requested an insecure resource http://…”
• An image, stylesheet, or script silently fails to load only in production
• The browser shows a shield or lock warning icon

Reproduce and Diagnose

Reproduce the failure in isolation before changing any code. Work through the checks below in order; each one narrows the search space.

Step 1: Find insecure requests in the console

DevTools → Console → filter "Mixed Content"

Each entry names the blocked URL and its type, pointing to the exact resource to fix.

Step 2: Scan the source for http:// references

grep -rn "http://" src/ public/

Hardcoded insecure URLs in templates, CSS, or config are the usual cause.

Likely contributors, in order of frequency:

• A subresource URL is hardcoded as http://
• A third-party CDN or API is referenced without HTTPS
• An iframe or form posts to an http endpoint from an https page

Root Cause

Browsers block active and passive mixed content on HTTPS pages to prevent downgrade attacks. An http subresource is refused, so the asset fails even though the page itself loads.

The Fix

Serve every resource over HTTPS, update hardcoded http URLs, use protocol-relative or same-origin paths, and add a Content-Security-Policy upgrade-insecure-requests directive to auto-upgrade remaining http URLs.

Watch out: upgrade-insecure-requests silently rewrites URLs; ensure the target actually supports HTTPS or requests fail differently.

# nginx: add HSTS and CSP upgrade directive
add_header Content-Security-Policy "upgrade-insecure-requests" always;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;

<!-- use an HTTPS URL or a same-origin path -->
<script src="https://cdn.example.com/lib.js"></script>
<img src="/img/logo.png" alt="logo" />

Verify and Prevent

Reload and confirm no mixed content warnings and all assets load; the browser lock icon should show a secure page.

Once verified, add a regression test that reproduces the original symptom so the failure cannot silently return.

This class of failure is usually environmental rather than pure logic, so capture the exact command, the environment variables, and the working directory in your bug report. Reproduce it in the smallest possible script, then widen the scope only once the minimal case is understood. A short written checklist for this failure mode saves hours the next time it appears.