WP_PROXY_HOST dan WP_PROXY_PORT telah diatur. Permintaan ke API eksternal memakai proksi, tetapi permintaan kembali ke nama host WordPress sendiri tidak. Itu bisa jadi kebijakan lewatan yang dimaksudkan oleh HTTP API.

WP_HTTP_Proxy memutuskan apakah URI tertentu harus melewati proksi. Logika bawaannya melewati localhost dan nama host yang diturunkan dari siteurl terkonfigurasi situs. Ini terpisah dari sekadar memutuskan apakah konstanta proksi ada.

Periksa URL yang dievaluasi WordPress

Simpan bersama nama host yang diminta, URL situs terkonfigurasi, dan WP_PROXY_BYPASS_HOSTS. Permintaan ke nama host publik dan permintaan ke alias internal dapat mengambil keputusan berbeda meskipun keduanya mencapai aplikasi yang sama.

WP_PROXY_BYPASS_HOSTS menambahkan daftar pengecualian host yang dikonfigurasi. Itu bukan himpunan tujuan yang diizinkan oleh proksi jarak jauh, dan tidak membuat permintaan eksternal yang sebaliknya diblokir menjadi boleh.

Pengecualian situs sendiri bawaan bisa berguna: ia menghindari pengiriman permintaan aplikasi lokal bergaya loopback ke perantara. Namun instalasi yang nama host situs publiknya hanya dapat dijangkau melalui rute yang disetujui tertentu mungkin memerlukan keputusan sengaja yang berbeda.

Ubah keputusan pada kait yang didukung

Filter pre_http_send_through_proxy dapat menimpa keputusan per URI. Jaga setiap penimpaan tetap sempit dan cocokkan dengan host atau kondisi yang harus ditanganinya. Mengembalikan satu jawaban tetap untuk setiap URI mengubah kebijakan seluruh HTTP API.

Tinjau juga transportasi yang dipilih. Kode yang memanggil SDK terpisah atau fungsi jaringan PHP mentah tidak otomatis memakai HTTP API WordPress dan filternya.

Saat mendiagnosis jalur ini, catat keputusan lewatan tanpa membuang argumen permintaan lengkap ke publik. Itu bisa memuat cookie, informasi akun, dan rahasia proksi. Log proksi tanpa permintaan yang cocok konsisten dengan lewatan, tetapi itu saja tidak cukup untuk membedakannya dari permintaan yang tidak pernah dibuat.

Artikel terkait