WordPress अपनी ही साइट को प्रॉक्सी से बाहर रखता है

WP_PROXY_HOST और WP_PROXY_PORT सेट हैं। बाहरी API को अनुरोध प्रॉक्सी का उपयोग करता है, लेकिन WordPress के अपने होस्टनाम पर लौटने वाला अनुरोध नहीं करता। यह HTTP API की इच्छित बायपास नीति हो सकती है।

WP_HTTP_Proxy तय करता है कि कोई विशेष URI प्रॉक्सी से गुज़रना चाहिए या नहीं। इसका डिफ़ॉल्ट तर्क localhost और साइट के कॉन्फ़िगर किए गए siteurl से प्राप्त होस्टनाम को बायपास करता है। यह केवल यह तय करने से अलग है कि प्रॉक्सी कॉन्स्टेंट मौजूद हैं या नहीं।

वह URL जाँचें जिसका WordPress ने मूल्यांकन किया

अनुरोधित होस्टनाम, कॉन्फ़िगर किया गया साइट URL और WP_PROXY_BYPASS_HOSTS को साथ रखें। सार्वजनिक होस्टनाम को अनुरोध और आंतरिक उपनाम को अनुरोध अलग निर्णय ले सकते हैं, भले ही दोनों एक ही एप्लिकेशन तक पहुँचें।

WP_PROXY_BYPASS_HOSTS कॉन्फ़िगर की गई होस्ट अपवादों की सूची जोड़ता है। यह दूरस्थ प्रॉक्सी द्वारा अनुमत गंतव्यों का समूह नहीं है, और यह अन्यथा अवरुद्ध बाहरी अनुरोध को अनुमेय नहीं बनाता।

डिफ़ॉल्ट स्व-साइट अपवाद उपयोगी हो सकता है: यह स्थानीय लूपबैक प्रकार के एप्लिकेशन अनुरोध को मध्यस्थ तक ले जाने से बचाता है। लेकिन ऐसा इंस्टॉलेशन जिसमें सार्वजनिक साइट होस्टनाम केवल किसी विशेष अनुमोदित मार्ग से पहुँचा जा सकता है, उसे अलग सुविचारित निर्णय की आवश्यकता हो सकती है।

समर्थित हुक पर निर्णय बदलें

pre_http_send_through_proxy फ़िल्टर प्रति-URI निर्णय को ओवरराइड कर सकता है। किसी भी ओवरराइड को संकीर्ण रखें और उसे उस होस्ट या शर्त से मिलाएँ जिसे वह संभालने के लिए है। हर URI के लिए एक निश्चित उत्तर लौटाना पूरे HTTP API की नीति बदल देता है।

चुने गए ट्रांसपोर्ट की भी समीक्षा करें। अलग SDK या कच्चे PHP नेटवर्किंग फ़ंक्शन को कॉल करने वाला कोड अपने आप WordPress के HTTP API और उसके फ़िल्टर का उपयोग नहीं करता।

इस मार्ग का निदान करते समय, पूर्ण अनुरोध आर्गुमेंट सार्वजनिक रूप से उड़ाए बिना बायपास निर्णय दर्ज करें। उनमें कुकीज़, खाता जानकारी और प्रॉक्सी रहस्य हो सकते हैं। मेल खाते अनुरोध के बिना प्रॉक्सी लॉग बायपास के अनुरूप है, पर कभी न किए गए अनुरोध से उसे अलग करने के लिए अकेला पर्याप्त नहीं है।