הגדרת IP פרוקסי לבקשת Guzzle
השתמשו באפשרות proxy לכל בקשה ב-Guzzle והבינו את זמן ההמתנה לחיבור התלוי ב-handler ואת רשימת העקיפה המפורשת.
האפשרות proxy של Guzzle מקבלת URL מלא של נקודת הקצה. הגדירו אותה בבקשה כשרק הפעולה הזאת צריכה להשתמש ב-IP שבחרתם.
<?php
require __DIR__ . '/vendor/autoload.php';
$client = new GuzzleHttp\Client();
$response = $client->request('GET', 'https://example.com/', [
'proxy' => 'http://203.0.113.10:8080',
'connect_timeout' => 5,
'timeout' => 15,
'http_errors' => false,
]);
echo $response->getStatusCode(), PHP_EOL;
echo (string) $response->getBody();
הדוגמה מניחה ש-Guzzle 7 מותקן באמצעות Composer. החליפו את כתובת התיעוד בפרוקסי HTTP אמיתי מהספק או מרשימת שרתי פרוקסי HTTP. השאירו את היעד ב-URL הבקשה: הפרוקסי הוא מתווך, לא המשאב שמורידים.
כאן http_errors הוא false כדי שתגובת שגיאת HTTP תישאר זמינה לבדיקה. כשלי חיבור עדיין זורקים חריגות העברה. לכן מנהרת HTTPS שנדחתה בעת ההקמה עלולה להיכשל לפני שתקבלו אובייקט תגובה רגיל מהאתר.
בדקו את ה-handler אם מגבלות החיבור מתנהגות אחרת
Guzzle יכול להשתמש ב-handlers שונים של HTTP. התיעוד אומר ש-handler ה-cURL המובנה תומך ב-connect_timeout. handler מותאם או סביבה ללא PHP cURL אינם בהכרח שקולים. בדקו את ה-handler של היישום לפני שתניחו שאפשרות זמן קצוב שהועתקה אכן פועלת.
כדאי להגדיר גם את timeout הכולל. רשומות ברשימות חינמיות עשויות להפסיק לענות בין בדיקות, וברירת המחדל אינה מועד סיום מועיל לבקשה שחייבת להסתיים מהר.
שימוש במפת פרוקסי
מפה מאפשרת לבחור מסלולים לפי סכמת היעד ולציין במפורש מארחים שיעקפו את הפרוקסי:
'proxy' => [
'http' => 'http://203.0.113.10:8080',
'https' => 'http://203.0.113.10:8080',
'no' => [],
],
השתמשו במערך הזה במקום אפשרות המחרוזת. המפתח HTTPS בוחר יעדי HTTPS; ערך HTTP שלו עדיין מתאר את המאזין של הפרוקסי. פרוטוקול האזנה אחר דורש תצורת נקודת קצה אחרת.
כשאתם מספקים בעצמכם את אפשרות proxy של הבקשה, Guzzle מצפה שתספקו גם ערכי no רצויים, במקום להעתיק אותם אוטומטית מ-NO_PROXY. רשימה ריקה שימושית לבדיקת פרוקסי מבודדת. אם ליישום יש כללי עקיפה מכוונים, שמרו עליהם במפורש.