وردپرس سایت خودش را بیرون از پروکسی نگه می‌دارد

ثابت‌های WP_PROXY_HOST و WP_PROXY_PORT تنظیم شده‌اند. درخواست به یک API بیرونی از پروکسی استفاده می‌کند، اما درخواست بازگشتی به نام میزبان خود وردپرس این کار را نمی‌کند. این می‌تواند سیاست عبور مورد نظر HTTP API باشد.

WP_HTTP_Proxy تصمیم می‌گیرد که آیا یک URI خاص باید از پروکسی عبور کند. منطق پیش‌فرض آن localhost و نام میزبانی را که از siteurl تنظیم‌شده سایت گرفته می‌شود، دور می‌زند. این جدا از تصمیم‌گیری صرف درباره وجود ثابت‌های پروکسی است.

نشانی‌ای را که وردپرس ارزیابی کرده بررسی کنید

نام میزبان درخواستی، نشانی تنظیم‌شده سایت و WP_PROXY_BYPASS_HOSTS را کنار هم نگه دارید. درخواست به یک نام میزبان عمومی و درخواست به یک نام مستعار داخلی می‌توانند تصمیم‌های متفاوتی بگیرند، حتی اگر هر دو به یک برنامه برسند.

WP_PROXY_BYPASS_HOSTS فهرستی تنظیم‌شده از استثناهای میزبان اضافه می‌کند. این مجموعه مقصدهایی نیست که پروکسی راه دور مجاز می‌داند، و درخواست بیرونی‌ای را که در غیر این صورت مسدود است مجاز نمی‌کند.

استثنای پیش‌فرض خود سایت می‌تواند مفید باشد: مانع بردن یک درخواست محلی برنامه از نوع loopback به یک واسط می‌شود. اما نصبی که در آن نام میزبان عمومی سایت فقط از طریق مسیری تأییدشده و مشخص قابل دسترسی است، ممکن است به تصمیم آگاهانه دیگری نیاز داشته باشد.

تصمیم را در قلاب پشتیبانی‌شده تغییر دهید

فیلتر pre_http_send_through_proxy می‌تواند تصمیم هر URI را بازنویسی کند. هر بازنویسی را باریک نگه دارید و آن را با میزبان یا شرطی که باید مدیریت کند هماهنگ کنید. بازگرداندن یک پاسخ ثابت برای هر URI سیاست کل HTTP API را تغییر می‌دهد.

حمل‌ونقل انتخاب‌شده را هم بررسی کنید. کدی که یک SDK جداگانه یا یک تابع شبکه خام PHP را فراخوانی می‌کند، به‌طور خودکار از HTTP API وردپرس و فیلتر آن استفاده نمی‌کند.

هنگام عیب‌یابی این مسیر، تصمیم عبور را ثبت کنید بدون اینکه آرگومان‌های کامل درخواست را علنی بیرون بریزید. آن‌ها می‌توانند کوکی‌ها، اطلاعات حساب و رازهای پروکسی داشته باشند. گزارش پروکسی بدون درخواست منطبق با عبور سازگار است، اما به‌تنهایی برای تمایز آن از درخواستی که هرگز انجام نشده کافی نیست.