WordPress trzyma własną witrynę poza proxy

Stałe WP_PROXY_HOST i WP_PROXY_PORT są ustawione. Żądanie do zewnętrznego API korzysta z proxy, ale żądanie z powrotem do własnej nazwy hosta WordPressa już nie. To może być zamierzona polityka omijania HTTP API.

WP_HTTP_Proxy decyduje, czy dany URI ma przejść przez proxy. Jego domyślna logika omija localhost oraz nazwę hosta wyprowadzoną ze skonfigurowanego siteurl witryny. To jest osobne od samego ustalania, czy stałe proxy istnieją.

Sprawdź adres URL oceniony przez WordPressa

Trzymaj razem żądaną nazwę hosta, skonfigurowany adres URL witryny i WP_PROXY_BYPASS_HOSTS. Żądanie do publicznej nazwy hosta i żądanie do wewnętrznego aliasu mogą podejmować różne decyzje, nawet jeśli oba docierają do tej samej aplikacji.

WP_PROXY_BYPASS_HOSTS dodaje skonfigurowaną listę wyjątków hostów. To nie jest zbiór miejsc docelowych dozwolonych przez zdalne proxy i nie czyni inaczej zablokowanego żądania zewnętrznego dopuszczalnym.

Domyślny wyjątek własnej witryny może być użyteczny: zapobiega wysłaniu lokalnego żądania aplikacji typu loopback do pośrednika. Instalacja, w której publiczna nazwa hosta witryny jest osiągalna tylko przez określoną zatwierdzoną trasę, może jednak wymagać innej świadomej decyzji.

Zmień decyzję w obsługiwanym haku

Filtr pre_http_send_through_proxy może nadpisać decyzję dla każdego URI. Każde nadpisanie trzymaj wąsko i dopasuj je do hosta lub warunku, który ma obsługiwać. Zwracanie jednej stałej odpowiedzi dla każdego URI zmienia politykę całego HTTP API.

Przejrzyj także wybrany transport. Kod wywołujący osobny SDK lub surową funkcję sieciową PHP nie korzysta automatycznie z HTTP API WordPressa ani jego filtra.

Diagnozując tę ścieżkę, zapisz decyzję o ominięciu, nie ujawniając publicznie pełnych argumentów żądania. Mogą zawierać pliki cookie, informacje o koncie i sekrety proxy. Dziennik proxy bez pasującego żądania jest spójny z ominięciem, ale sam w sobie nie wystarcza, aby odróżnić je od żądania, którego nigdy nie wykonano.