WordPress ohranja svoje lastno spletišče zunaj proxyja

WP_PROXY_HOST in WP_PROXY_PORT sta nastavljena. Zahteva na zunanji API uporablja proxy, zahteva nazaj na lastno ime gostitelja WordPressa pa ne. To je lahko predvidena politika obhoda HTTP API.

WP_HTTP_Proxy odloča, ali naj določen URI gre skozi proxy. Njegova privzeta logika obide localhost in ime gostitelja, izpeljano iz nastavljenega siteurl spletišča. To je ločeno od samega odločanja, ali proxy konstante obstajajo.

Preglejte URL, ki ga je WordPress ovrednotil

Držite skupaj zahtevano ime gostitelja, nastavljeni URL spletišča in WP_PROXY_BYPASS_HOSTS. Zahteva na javno ime gostitelja in zahteva na notranji vzdevek se lahko odločita različno, tudi če obe dosežeta isto aplikacijo.

WP_PROXY_BYPASS_HOSTS doda nastavljen seznam izjem gostiteljev. To ni nabor ciljev, ki jih dovoljuje oddaljeni proxy, in ne naredi sicer blokirane zunanje zahteve dopustne.

Privzeta izjema lastnega spletišča je lahko koristna: prepreči pošiljanje lokalne aplikacijske zahteve tipa loopback k posredniku. Namestitev, v kateri je javno ime gostitelja spletišča dosegljivo le prek določene odobrene poti, pa lahko potrebuje drugačno premišljeno odločitev.

Spremenite odločitev na podprtem kavlju

Filter pre_http_send_through_proxy lahko preglasi odločitev za vsak URI. Vsak preglas naj bo ozek in usklajen z gostiteljem ali pogojem, ki naj bi ga obravnaval. Vračanje enega fiksnega odgovora za vsak URI spremeni politiko celotnega HTTP API.

Preglejte tudi izbrani prenos. Koda, ki kliče ločen SDK ali surovo PHP omrežno funkcijo, samodejno ne uporablja HTTP API WordPressa in njegovega filtra.

Pri diagnosticiranju te poti zabeležite odločitev o obhodu, ne da bi javno razkrili celotne argumente zahteve. Ti lahko vsebujejo piškotke, podatke o računu in skrivnosti proxyja. Dnevnik proxyja brez ustrezne zahteve je skladen z obhodom, a sam po sebi ne zadostuje, da bi ga ločil od zahteve, ki ni bila nikoli izvedena.