PAGUP Agent ControlAccesso WordPress per assistenti IA
Prova gratis

WordPress non rileva HTTPS dietro Cloudflare o un reverse proxy

Il browser usa HTTPS, ma WordPress non riconosce come sicura la richiesta ricevuta dall’origine.

Conferma che l’URL esatto usato dall’assistente si apra con HTTPS valido.

Cause probabili

  • Il browser usa HTTPS, ma WordPress non riconosce come sicura la richiesta ricevuta dall’origine.
  • Il proxy non inoltra l’informazione di schema necessaria a WordPress per riconoscere HTTPS.
  • Home URL e Site URL usano schemi, host o percorsi differenti.
  • Un reindirizzamento cambia schema, host o percorso e può rimuovere gli header di autenticazione.
  • Un altro plugin modifica rilevamento HTTPS, accesso REST o disponibilità delle Application Password.

Sequenza diagnostica

  1. Conferma che l’URL esatto usato dall’assistente si apra con HTTPS valido.
  2. Conferma che WordPress riconosca la richiesta come HTTPS, non solo il browser.
  3. Esamina gli header del proxy attendibile che comunicano lo schema HTTPS originale.
  4. Confronta Home URL, Site URL, host canonico pubblico e base REST.
  5. Segui ogni reindirizzamento e verifica schema, host, percorso e Authorization.
  6. Registra versioni di WordPress, plugin, client, connettore e server prima di cambiare qualcosa.

Applicare la correzione minima

  1. Correggi gestione di proxy attendibile e origine affinché WordPress riconosca l’HTTPS originale.
  2. Allinea Home URL, Site URL, host pubblico, schema HTTPS e base REST.
  3. Rimuovi o correggi il reindirizzamento che altera la richiesta autenticata.
  4. Modifica solo regola, route o metodo del falso positivo confermato.
  5. Invia prove ripulite e versionate se il comportamento resta specifico del plugin.

Verificare il risultato

  • L’avviso scompare solo nella condizione corretta e non torna su pagine amministrative estranee.
  • La richiesta autenticata raggiunge l’endpoint canonico senza reindirizzamenti inattesi.
  • L’indice REST risponde dall’URL HTTPS canonico e mostra i namespace attesi.
  • La richiesta autenticata corrisponde all’utente dedicato previsto.

Cosa non fare

  • Non aggiungere una soluzione proxy permanente non verificata prima di confermare il percorso attendibile.
  • Non disattivare globalmente WAF o plugin di sicurezza per una singola richiesta.
  • Non modificare core WordPress o file di plugin terzi come primo passo.
  • Non concedere accesso amministratore solo per superare un test di connessione.
  • Non inserire Application Password, Authorization, token o cookie in prompt, ticket, log o screenshot.

Domande frequenti

Devo forzare HTTPS con uno snippet permanente?

Solo dopo aver compreso il contratto di hosting e proxy. Uno snippet generico può nascondere una configurazione errata dell’origine o fidarsi di un header inoltrato non verificato.

Guide correlate

Fonti e verifica

Questa pagina è stata verificata in base alle seguenti fonti primarie. Ultima revisione delle fonti: .