WordPress משאיר את האתר שלו מחוץ לפרוקסי

הקבועים WP_PROXY_HOST ו-WP_PROXY_PORT מוגדרים. בקשה ל-API חיצוני משתמשת בפרוקסי, אך בקשה חזרה לשם המארח של WordPress עצמו אינה עושה זאת. זו יכולה להיות מדיניות העקיפה המיועדת של ה-HTTP API.

WP_HTTP_Proxy מחליט אם URI מסוים צריך לעבור דרך הפרוקסי. ההיגיון המוגדר כברירת מחדל עוקף את localhost ואת שם המארח הנגזר מה-siteurl המוגדר של האתר. זה נפרד מלהחליט רק אם קיימים קבועי פרוקסי.

בדקו את הכתובת ש-WordPress העריך

החזיקו יחד את שם המארח המבוקש, כתובת האתר המוגדרת ואת WP_PROXY_BYPASS_HOSTS. בקשה לשם מארח ציבורי ובקשה לכינוי פנימי עשויות לקבל החלטות שונות גם אם שתיהן מגיעות לאותה אפליקציה.

WP_PROXY_BYPASS_HOSTS מוסיף רשימה מוגדרת של החרגות מארח. זו אינה קבוצה של יעדים שהפרוקסי המרוחק מתיר, והיא אינה הופכת בקשת חוץ חסומה אחרת למותרת.

ההחרגה המוגדרת כברירת מחדל של האתר עצמו עשויה להועיל: היא מונעת הוצאת בקשת אפליקציה מקומית מסוג loopback אל מתווך. אך התקנה שבה שם המארח הציבורי של האתר נגיש רק דרך מסלול מאושר מסוים עשויה להזדקק להחלטה מכוונת אחרת.

שנו את ההחלטה ב-hook הנתמך

המסנן pre_http_send_through_proxy יכול לעקוף את ההחלטה לכל URI. שמרו על כל עקיפה צרה והתאימו אותה למארח או לתנאי שהיא אמורה לטפל בו. החזרת תשובה קבועה אחת לכל URI משנה את המדיניות של כל ה-HTTP API.

בדקו גם את אמצעי התעבורה שנבחר. קוד שקורא ל-SDK נפרד או לפונקציית רשת PHP גולמית אינו משתמש אוטומטית ב-HTTP API של WordPress ובמסנן שלו.

בעת אבחון המסלול הזה, תעדו את החלטת העקיפה בלי לשפוך החוצה את מלוא ארגומנטי הבקשה. הם עשויים להכיל קובצי cookie, פרטי חשבון וסודות פרוקסי. יומן פרוקסי בלי בקשה מתאימה תואם לעקיפה, אך אינו מספיק כשלעצמו כדי להבדיל בינה לבין בקשה שמעולם לא נעשתה.