WordPress тримає власний сайт поза проксі

Константи WP_PROXY_HOST і WP_PROXY_PORT задані. Запит до зовнішнього API використовує проксі, а запит назад до власного імені хоста WordPress — ні. Це може бути передбачувана політика обходу HTTP API.

WP_HTTP_Proxy вирішує, чи має конкретний URI проходити через проксі. Його типова логіка обходить localhost та ім'я хоста, отримане з налаштованого siteurl сайту. Це окремо від простого визначення, чи існують константи проксі.

Перевірте URL, який оцінив WordPress

Тримайте разом запитане ім'я хоста, налаштований URL сайту та WP_PROXY_BYPASS_HOSTS. Запит до публічного імені хоста і запит до внутрішнього псевдоніма можуть ухвалювати різні рішення, навіть якщо обидва доходять до одного застосунку.

WP_PROXY_BYPASS_HOSTS додає налаштований список винятків хостів. Це не набір призначень, дозволених віддаленим проксі, і він не робить інакше заблокований зовнішній запит допустимим.

Типовий виняток власного сайту може бути корисним: він не дає відправляти локальний запит застосунку типу loopback до посередника. Але встановлення, у якому публічне ім'я хоста сайту доступне лише через певний схвалений маршрут, може потребувати іншого свідомого рішення.

Змініть рішення на підтримуваному гачку

Фільтр pre_http_send_through_proxy може перевизначити рішення для кожного URI. Тримайте будь-яке перевизначення вузьким і узгоджуйте його з хостом або умовою, яку воно має обслуговувати. Повернення однієї фіксованої відповіді для кожного URI змінює політику всього HTTP API.

Перегляньте також обраний транспорт. Код, що викликає окремий SDK або сиру мережеву функцію PHP, не використовує автоматично HTTP API WordPress і його фільтр.

Діагностуючи цей шлях, фіксуйте рішення про обхід, не оприлюднюючи повні аргументи запиту. Вони можуть містити файли cookie, інформацію про обліковий запис і секрети проксі. Журнал проксі без відповідного запиту узгоджується з обходом, але сам по собі не достатній, щоб відрізнити його від запиту, який ніколи не виконувався.