Home/Server & Website Managed Operations/Troubleshooting HTTPS Mixed Content: Fixing Missing Lock Icon and Resource Loading Issues
Server & Website Managed Operations

Troubleshooting HTTPS Mixed Content: Fixing Missing Lock Icon and Resource Loading Issues

After enabling HTTPS on the site, you might notice that the browser’s address bar lacks the padlock icon, or the console is filled with warnings and some images and scripts fail to load. These issues are almost always caused by mixed content—where the page itself is served over HTTPS but references HTTP resources.

This doesn’t prevent the website from loading, so it’s often left unaddressed. However, the consequences are real: browsers may block certain resources entirely, resulting in a page with missing functionality for users.

Two Types of Mixed Content, Different Handling Approaches

Type Includes Browser Behavior
Pasive Mixed Content Images, audio, video Usually still loads, but triggers warnings and removes the padlock icon
Active Mixed Content Scripts, stylesheets, iframes, fonts Blocked directly; not loaded

This distinction is critical: HTTP images only cause the padlock icon to disappear, whereas HTTP scripts cause features to break completely. Therefore, when troubleshooting, prioritize resolving active mixed content.

How to Identify

Method 1: Browser Console (Most Direct)

  1. Open the page → Press F12 → Go to Console
  2. Mixed content issues will be clearly reported, indicating the specific URL involved
  3. Switch to the Network panel, filter by Scheme or look for requests marked as blocked

Method 2: Command-Line Scan of the Entire Site

# Find http:// resources in the page source
curl -s https://example.com/ | grep -oE 'http://[^"'"'"' )]+' | sort -u

# Look only within resource tags
curl -s https://example.com/ 
  | grep -oE '(src|href)="http://[^"]+"' | sort -u

# CSS files may also contain references (background images, @import)
curl -s https://example.com/wp-content/themes/xxx/style.css | grep -oE 'http://[^)"'"'"']+'

Method 3: Database Search (Most Common in WordPress)

# Search for http links in post content and options
mysql -e "SELECT ID, post_title FROM wp_posts
          WHERE post_content LIKE '%http://example.com%' LIMIT 20;" dbname

# Absolute links are often stored in theme settings and plugin options
mysql -e "SELECT option_name FROM wp_options
          WHERE option_value LIKE '%http://example.com%';" dbname

How to Fix

① Database Replacement (Mind Serialization)

# Best practice: Use WP-CLI, which correctly handles serialized data
wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run
wp search-replace 'http://example.com' 'https://example.com' --all-tables

# Use --dry-run first to preview how many records will be changed; remove it only after confirmation

Avoid using SQL REPLACE directly. WordPress stores a significant amount of data in serialized formats (where string length is encoded at the beginning). Direct replacement corrupts these length values, causing theme settings and widgets to fail. This is one of the most classic pitfalls during migration and URL replacement scenarios.

② Hardcoded URLs in Themes and Plugins

# Search for hardcoded http in template files
grep -rn "http://" /var/www/html/wp-content/themes/ --include='*.php' | head -20
grep -rn "http://" /var/www/html/wp-content/plugins/ --include='*.php' | head -20

Once found, change them to use the protocol-relative format or WordPress address functions:

// Not recommended: Hardcoded protocol
<img src="http://example.com/logo.png">

// Recommended: Protocol-relative (automatically follows the current page's protocol)
<img src="//example.com/logo.png">

// More recommended in WordPress: Use functions
<img src="<?php echo esc_url( home_url('/logo.png') ); ?>">

③ Special Handling for Reverse Proxy Scenarios

If your site is behind a CDN or reverse proxy (HTTPS terminates at the edge, while origin communication uses HTTP), the application may assume the connection is HTTP and generate http links:

location ~ .php$ {
    fastcgi_param HTTPS on;                        # Explicitly tell the backend that HTTPS is active
    fastcgi_param HTTP_X_FORWARDED_PROTO $scheme;  # Pass the actual protocol
    include fastcgi_params;
}
// WordPress recognizes proxy protocols
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) &&
    $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

④ Fallback Solution: CSP Auto Upgrade

add_header Content-Security-Policy "upgrade-insecure-requests";

This directive instructs browsers to automatically upgrade http requests within the page to https. It can quickly eliminate warnings, but be aware—this assumes those resources are indeed available over HTTPS; otherwise, they will result in 404 errors. Therefore, it is suitable as a transitional measure, not a replacement for proper fixes.

Decision Tree

HTTPS page contains http resources
├─ Check console to determine if passive or active
│  ├─ Active (scripts/styles) → Fix first; browsers block these
│  └─ Passive (images)        → Fix; impacts security lock and trust
├─ Identify source location
│  ├─ Database content/options → Use wp search-replace (do not use direct SQL REPLACE)
│  ├─ Theme/plugin hardcoding  → Modify code; use protocol-relative or home_url()
│  └─ Programmatically generated → If HTTPS terminates at proxy, ensure X-Forwarded-Proto is passed
└─ Need quick mitigation
   └─ CSP upgrade-insecure-requests (for transition only; resources must support HTTPS)

Scenario Analysis: Missing Padlock with No Obvious Errors on Page

Symptom: The site has fully enabled HTTPS, but the security indicator in the address bar has disappeared. Some styles and scripts are not taking effect. The page appears to load normally, making it difficult to identify which specific resource is causing the issue.

  1. Check the console for error messages first → The console explicitly indicates which requests are blocked,
    eliminating the need to guess resource by resource. This step provides an immediate list and is the fastest entry point.
  2. Categorize the extracted URLs from the list → Classify them into “absolute paths on your own site,” “protocol-relative paths,” and “external site addresses.”
    Different categories require different remediation strategies.
  3. Handle existing absolute addresses → Hardcoded legacy protocol addresses in database content and article bodies are a primary source;
    these need to be replaced based on domain.
  4. Handle hardcoded resource addresses in templates → External references in theme files should be changed to use protocol-relative notation.
  5. Manage external resources beyond your control → Third-party resources that do not support HTTPS must either have their source replaced or be hosted locally;
    there are no other options.
  6. Clear cache and verify item by item → Page caching can make modifications appear ineffective; clear the cache and then check if any blocked items remain in the console.
# Identify residual old-protocol addresses in the body (check volume first to determine replacement scope)
mysqldump db_name | grep -o 'src="http://[^"]*"' | sort | uniq -c | sort -rn | head
mysqldump db_name | grep -o "src='http://[^']*'" | sort | uniq -c | sort -rn | head

# Hardcoded resource references in templates
grep -rIn 'http://' /path/to/website/wp-content/themes/ | head -20

# Replacement: Use tools that understand serialized formats, otherwise theme configurations will be corrupted
wp search-replace 'http://example.com' 'https://example.com' --dry-run --report-changed-only

# Confirm no unencrypted references remain in the page
curl -s https://example.com/ | grep -oE 'src="http://|href="http://' | head

Root Cause: Enabling HTTPS only changed the access method for the main page,
while the addresses of resources referenced within the page were not updated simultaneously—residuals may exist in article content, templates, and external links.

Two key points to remember:

  • Start troubleshooting mixed content from the console, not by visual inspection.
    Browsers directly list the inventory of blocked resources; this is the only entry point to obtain all information at once.
  • After enabling HTTPS, perform a body-level address replacement, not just Web server configuration.
    Configuring the server only changes the entry point on your side; hardcoded resource references within pages will not automatically change just because a redirect is configured.

8 Common Pitfalls

  1. Using SQL REPLACE on serialized data: This corrupts length values, causing theme settings to fail entirely. Use wp search-replace instead.
  2. Only updating the homepage: Links in the body text of older articles will not update accordingly.
  3. Ignoring HTTP in CSS: Background images and @import statements also count as mixed content.
  4. Missing protocol in proxy scenarios: The program assumes HTTP is still in use and continues to generate http:// links.
  5. Treating CSP as a final solution: Resources that do not support HTTPS will result in direct 404 errors.
  6. Failing to distinguish between active and passive mixed content: Scripts using HTTP cause functionality failures and take precedence over other issues.
  7. Skipping dry-run before bulk replacement: Since this is an irreversible operation, always verify the scope of impact first.
  8. Not clearing cache after changes: Page or CDN caches remain unchanged, so you won’t see the fix immediately.

Real Customer Feedback (from reviews and inquiries on similar cloud marketplace offerings)

The following excerpts are taken from genuine buyer reviews and consultations for similar IT operations services on Alibaba Cloud, Tencent Cloud, and Huawei Cloud marketplaces (service providers include our store and competitors; these are provided solely as authentic feedback references and do not constitute fabricated tickets).

1****b Rating: 5.0 | 2022-01-05 16:21 Very serious and responsible d****x Rating: 5.0 | 2021-12-02 11:34 Easy to use Yi****ji Rating: 5.0 | 2020-07-08 14:04 Configuration completed. Thank you. Zhi****si Rating: 5.0 | 2020-07-08 11:25 Fast configuration. Good job. p****t Rating: 5.0 | 2020-02-11 15:08 None 1

h****6 Rating: 5.0 | 2022-06-07 09:37 b****h Rating: 5.0 | 2022-04-01 15:11 Che****che Rating: 5.0 | 2022-02-25 11:24

2****0 Rating: 5.0 | 2022-11-03 14:39 j****1 Rating: 5.0 | 2022-04-25 10:07 y****6 Rating: 5.0 | 2022-04-19 16:27 Chong****0 Rating: 5.0 | 2021-11-11 22:29 OK h****3 Rating: 5.0 | 2021-09-07 11:19 Easy to use 8****0 Rating: 5.0 | 2021-07-22 11:29 Extremely responsive and fast completion! h****3 Rating: 5.0 | 2020-09-07 14:05 Timely configuration. 1

FREE CHECKUP

Free server checkup

We will send a problem checklist and remediation advice within one business day — no obligation to engage.

135 410 16684
Weekdays Mon – Fri 10:00 – 22:00 (UTC+8) · 7×24 emergency response
Call now
CONTACT

Contact Us

How can we help?

* Required