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 і яго фільтр.

Дыягнастуючы гэты шлях, запісвайце рашэнне аб абыходзе, не публікуючы поўныя аргументы запыту. Яны могуць змяшчаць кукі, інфармацыю пра ўліковы запіс і сакрэты проксі. Журнал проксі без адпаведнага запыту ўзгадняецца з абыходам, але сам па сабе не дастатковы, каб адрозніць яго ад запыту, які ніколі не рабіўся.