WordPress detecteert HTTPS niet achter Cloudflare of een reverse proxy
De browser gebruikt HTTPS, maar WordPress herkent het verzoek bij de origin niet als veilig.
Controleer of de exact gebruikte URL met geldige HTTPS-verbinding opent.
Waarschijnlijke oorzaken
- De browser gebruikt HTTPS, maar WordPress herkent het verzoek bij de origin niet als veilig.
- De proxy stuurt niet de schema-informatie door die WordPress nodig heeft voor HTTPS-detectie.
- Home URL en Site URL gebruiken verschillende schema’s, hosts of paden.
- Een omleiding wijzigt schema, host of pad en kan authenticatieheaders verliezen.
- Een andere plugin wijzigt HTTPS-detectie, REST-toegang of beschikbaarheid van Application Passwords.
Diagnosevolgorde
- Controleer of de exact gebruikte URL met geldige HTTPS-verbinding opent.
- Controleer of WordPress zelf het verzoek als HTTPS herkent, niet alleen de browser.
- Bekijk vertrouwde proxyheaders die het oorspronkelijke HTTPS-schema doorgeven.
- Vergelijk Home URL, Site URL, publieke canonieke host en REST-basisadres.
- Volg elke omleiding en controleer schema, host, pad en Authorization.
- Leg versies van WordPress, plugin, client, connector en server vast vóór wijzigingen.
Pas de kleinst mogelijke correctie toe
- Corrigeer vertrouwde proxy- en originafhandeling zodat WordPress het oorspronkelijke HTTPS-verzoek herkent.
- Lijn Home URL, Site URL, publieke host, HTTPS-schema en REST-basis uit.
- Verwijder of corrigeer de omleiding die het geauthenticeerde verzoek onverwacht wijzigt.
- Pas alleen de bevestigde false-positive-regel, route of methode aan.
- Escaleer met opgeschoond versiegebonden bewijs wanneer het gedrag pluginspecifiek blijft.
Controleer het resultaat
- De melding verdwijnt alleen onder de gecorrigeerde voorwaarde en keert niet terug op ongerelateerde adminpagina’s.
- Het geauthenticeerde verzoek bereikt het canonieke endpoint zonder onverwachte omleiding.
- De REST-index antwoordt via de canonieke HTTPS-URL en toont verwachte namespaces.
- Het geauthenticeerde verzoek hoort bij de bedoelde toegewezen gebruiker.
Wat u niet moet doen
- Voeg geen permanente onbewezen proxyomweg toe vóór bevestiging van het vertrouwde pad.
- Schakel WAF of beveiligingsplugin niet algemeen uit voor één verzoek.
- Bewerk WordPress core of externe pluginbestanden niet als eerste stap.
- Geef geen beheerderstoegang alleen om een verbindingstest te laten slagen.
- Deel geen Application Password, Authorization-header, token of cookie in prompt, ticket, log of screenshot.
Veelgestelde vragen
Moet ik HTTPS afdwingen met een permanent codefragment?
Alleen nadat het hosting- en proxycontract duidelijk is. Een generiek fragment kan een originfout verbergen of een niet-geverifieerde forwarded header vertrouwen.
Gerelateerde handleidingen
- Waarom WAP AI Assistant een HTTPS-waarschuwing toont op een HTTPS-site
- WordPress Application Passwords zijn uitgeschakeld: oorzaken en controles
- Een verschil tussen WordPress Home URL en Site URL breekt AI-verbindingen
- Omleidingslus bij een WordPress-AI-verbinding: HTTP, HTTPS en canonieke URL
- De WordPress Authorization-header ontbreekt of wordt verwijderd
Bronnen en verificatie
Deze pagina is gecontroleerd aan de hand van de volgende primaire bronnen. Laatste broncontrole: .
- is_ssl() · WordPress Developer Resources
- home_url() · WordPress Developer Resources
- site_url() · WordPress Developer Resources
- Cloudflare SSL/TLS Encryption Modes · Cloudflare