ووردبريس يُبقي موقعه الخاص خارج الوسيط

ثوابت WP_PROXY_HOST وWP_PROXY_PORT مضبوطة. الطلب إلى واجهة برمجية خارجية يستخدم الوسيط، أما الطلب العائد إلى اسم المضيف الخاص بووردبريس فلا يستخدمه. قد يكون هذا هو سياسة التجاوز المقصودة في واجهة HTTP.

يقرر WP_HTTP_Proxy ما إذا كان عنوان URI معيّن ينبغي أن يمرّ عبر الوسيط. منطقه الافتراضي يتجاوز localhost واسم المضيف المشتق من siteurl المضبوط للموقع. وهذا منفصل عن مجرد تقرير وجود ثوابت الوسيط.

افحص العنوان الذي قيّمه ووردبريس

اجمع اسم المضيف المطلوب وعنوان الموقع المضبوط وWP_PROXY_BYPASS_HOSTS معًا. الطلب إلى اسم مضيف عام وآخر إلى اسم مستعار داخلي قد يتخذان قرارين مختلفين حتى لو وصلا إلى التطبيق نفسه.

يضيف WP_PROXY_BYPASS_HOSTS قائمة مضبوطة باستثناءات المضيفين. وهي ليست مجموعة وجهات يسمح بها الوسيط البعيد، ولا تجعل طلبًا خارجيًا محجوبًا مسموحًا.

قد يكون استثناء الموقع الذاتي الافتراضي مفيدًا: فهو يمنع إخراج طلب تطبيق محلي من نوع loopback إلى وسيط. لكن تثبيتًا لا يُبلغ فيه اسم المضيف العام للموقع إلا عبر مسار معتمد معيّن قد يحتاج إلى قرار متعمّد مختلف.

غيّر القرار عند الخطاف المدعوم

يمكن لمرشّح pre_http_send_through_proxy تجاوز القرار لكل URI. أبقِ أي تجاوز ضيّقًا وطابقه مع المضيف أو الشرط الذي يُفترض أن يعالجه. إرجاع إجابة ثابتة واحدة لكل URI يغيّر سياسة واجهة HTTP بأكملها.

راجع وسيلة النقل المختارة أيضًا. الكود الذي يستدعي SDK منفصلًا أو دالة شبكة PHP خامًا لا يستخدم تلقائيًا واجهة HTTP في ووردبريس ومرشّحها.

عند تشخيص هذا المسار، سجّل قرار التجاوز دون نشر وسائط الطلب الكاملة علنًا. فقد تحتوي على ملفات تعريف الارتباط ومعلومات الحساب وأسرار الوسيط. سجل وسيط بلا طلب مطابق يتوافق مع التجاوز، لكنه وحده لا يكفي للتمييز بينه وبين طلب لم يُجرَ قط.