Een verschil tussen WordPress Home URL en Site URL breekt AI-verbindingen
Home URL en Site URL gebruiken verschillende schema’s, hosts of paden.
Vergelijk Home URL, Site URL, publieke canonieke host en REST-basisadres.
Waarschijnlijke oorzaken
- Home URL en Site URL gebruiken verschillende schema’s, hosts of paden.
- Een omleiding wijzigt schema, host of pad en kan authenticatieheaders verliezen.
- De browser gebruikt HTTPS, maar WordPress herkent het verzoek bij de origin niet als veilig.
- De client gebruikt het verkeerde domein, basispad, REST-endpoint of MCP-endpoint.
- Permalink- of rewriteconfiguratie verhindert het verwachte REST-basispad.
Diagnosevolgorde
- Vergelijk Home URL, Site URL, publieke canonieke host en REST-basisadres.
- Volg elke omleiding en controleer schema, host, pad en Authorization.
- Controleer of WordPress zelf het verzoek als HTTPS herkent, niet alleen de browser.
- Vraag de REST-index op en controleer verwachte namespaces en authenticatiemetadata.
- Bevestig schema, host, basispad en endpoint in de clientconfiguratie.
- Leg versies van WordPress, plugin, client, connector en server vast vóór wijzigingen.
Pas de kleinst mogelijke correctie toe
- Lijn Home URL, Site URL, publieke host, HTTPS-schema en REST-basis uit.
- Verwijder of corrigeer de omleiding die het geauthenticeerde verzoek onverwacht wijzigt.
- Corrigeer vertrouwde proxy- en originafhandeling zodat WordPress het oorspronkelijke HTTPS-verzoek herkent.
- Herstel de benodigde REST-route of beschikbaarheid met authenticatie en permission callbacks.
- Corrigeer endpoint, transport, toolnaam of credentialreferentie zonder rechten te verbreden.
Controleer het resultaat
- 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.
- De goedgekeurde beperkte leesactie werkt met reproduceerbare reactie.
Wat u niet moet doen
- Bewerk WordPress core of externe pluginbestanden niet als eerste stap.
- Voeg geen permanente onbewezen proxyomweg toe vóór bevestiging van het vertrouwde pad.
- Geef geen beheerderstoegang alleen om een verbindingstest te laten slagen.
- Schakel WAF of beveiligingsplugin niet algemeen uit voor één verzoek.
- Deel geen Application Password, Authorization-header, token of cookie in prompt, ticket, log of screenshot.
Gerelateerde handleidingen
- Omleidingslus bij een WordPress-AI-verbinding: HTTP, HTTPS en canonieke URL
- WordPress detecteert HTTPS niet achter Cloudflare of een reverse proxy
- WordPress /wp-json/ geeft 404: diagnose van de REST API
- Waarom WAP AI Assistant een HTTPS-waarschuwing toont op een HTTPS-site
- WordPress-applicatiewachtwoorden voor AI-verbindingen
Bronnen en verificatie
Deze pagina is gecontroleerd aan de hand van de volgende primaire bronnen. Laatste broncontrole: .
- home_url() · WordPress Developer Resources
- site_url() · WordPress Developer Resources
- is_ssl() · WordPress Developer Resources
- Routes and Endpoints · WordPress Developer Resources