WordPress त्याची स्वतःची साइट प्रॉक्सीच्या बाहेर ठेवते

WP_PROXY_HOST आणि WP_PROXY_PORT सेट केले आहेत. बाह्य API कडे जाणारी विनंती प्रॉक्सी वापरते, पण WordPress च्या स्वतःच्या होस्टनावाकडे परत जाणारी विनंती वापरत नाही. हे HTTP API चे इच्छित बायपास धोरण असू शकते.

WP_HTTP_Proxy ठरवते की एखादा विशिष्ट URI प्रॉक्सीमधून जावा की नाही. त्याचे डीफॉल्ट तर्क localhost आणि साइटच्या कॉन्फिगर केलेल्या siteurl वरून मिळणारे होस्टनाव बायपास करते. हे फक्त प्रॉक्सी कॉन्स्टंट अस्तित्वात आहेत की नाही हे ठरवण्यापासून वेगळे आहे.

WordPress ने मूल्यांकन केलेली URL तपासा

विनंती केलेले होस्टनाव, कॉन्फिगर केलेली साइट URL आणि WP_PROXY_BYPASS_HOSTS एकत्र ठेवा. सार्वजनिक होस्टनावाकडे जाणारी विनंती आणि अंतर्गत उपनावाकडे जाणारी विनंती दोन्ही एकाच अनुप्रयोगाकडे पोहोचली तरी वेगवेगळे निर्णय घेऊ शकतात.

WP_PROXY_BYPASS_HOSTS कॉन्फिगर केलेली होस्ट वगळण्यांची यादी जोडते. हा दूरस्थ प्रॉक्सीने परवानगी दिलेल्या गंतव्यांचा संच नाही आणि तो अन्यथा अवरोधित बाह्य विनंतीला परवानगीयोग्य करत नाही.

डीफॉल्ट स्व-साइट वगळणे उपयुक्त ठरू शकते: ते स्थानिक लूपबॅक प्रकारची अनुप्रयोग विनंती मध्यस्थाकडे नेणे टाळते. पण ज्या स्थापनेत सार्वजनिक साइट होस्टनाव फक्त विशिष्ट मंजूर मार्गाने पोहोचता येते तिला वेगळा सुविचारित निर्णय लागू शकतो.

समर्थित हुकवर निर्णय बदला

pre_http_send_through_proxy फिल्टर प्रत्येक URI चा निर्णय ओव्हरराइड करू शकतो. कोणतेही ओव्हरराइड अरुंद ठेवा आणि ते ज्या होस्ट किंवा अटीला हाताळायचे आहे त्याच्याशी जुळवा. प्रत्येक URI साठी एक निश्चित उत्तर परत केल्याने संपूर्ण HTTP API चे धोरण बदलते.

निवडलेल्या वाहतुकीचाही आढावा घ्या. वेगळे SDK किंवा कच्चे PHP नेटवर्किंग फंक्शन कॉल करणारा कोड आपोआप WordPress चे HTTP API आणि त्याचा फिल्टर वापरत नाही.

हा मार्ग निदान करताना, संपूर्ण विनंती आर्ग्युमेंट सार्वजनिकपणे न ओतता बायपास निर्णय नोंदवा. त्यात कुकीज, खाते माहिती आणि प्रॉक्सी रहस्ये असू शकतात. जुळणारी विनंती नसलेला प्रॉक्सी लॉग बायपासशी सुसंगत आहे, पण कधीही न केलेल्या विनंतीपासून तो वेगळा करण्यासाठी तो एकटा पुरेसा नाही.