HTTP 504 Gateway Timeout לעומת פסק הזמן של הלקוח שלך
הבחינו בין בקשה במעלה הזרם שפג זמנה בשער לבין פסק הזמן שהוגדר בלקוח הפרוקסי שלכם.
הלקוח שלך מוכן להמתין שישים שניות. עשר שניות לאחר מכן הוא מקבל HTTP 504. העלאת פסק הזמן של הלקוח לשתי דקות אינה נותנת לשער עוד חמישים שניות עבודה.
504 מתאר שער או פרוקסי שלא קיבל תגובת במעלה הזרם בזמן, בעודו מנסה להשלים את הבקשה. השער כבר קיבל את החלטתו והחזיר תגובה. הלקוח שלך יכול לקרוא את התגובה הזו בהצלחה.
איזה מתווך החזיר אותה?
הפרוקסי הקדמי עשוי להיות המנפיק. גם שער מאוחר יותר המופעל על ידי האתר. עם TLS רגיל מקצה לקצה בתוך CONNECT, תגובת HTTP מתוך אותו חילוף מוגן עם היעד אינה זהה לדחייה של CONNECT עצמו.
שמרו את השלב, את כותרות התגובה, את הנוסח של עמוד השגיאה ואת היומנים המתאימים כשהם זמינים. תווית שרת יכולה להיות רמז, אך אין להתייחס אליה כייחוס שאינו טועה. במסלול עשויים להיות יותר מתווכים מזה שהוגדר בלקוח שלך.
לאחר מכן בדקו מדוע אותה פעולה במעלה הזרם לא הושלמה. נגישות, שירותים עמוסים, גוף בקשה שהבמעלה הזרם אינו יכול לעבד כצפוי, והתנהגות היישום — כל אלה יכולים להיות רלוונטיים. הסטטוס המספרי לבדו אינו מוכיח ששינוי User-Agent או הוספת אפשרות פסק זמן אחת הם הפתרון האוניברסלי.
השוו את אותה בקשה
כשכלי אחר עובד, השוו שיטה, יעד, קידוד גוף, אימות ומסלול. "הכתובת נפתחת בדפדפן" אינה השוואה שלמה לשליחת multipart דרך לקוח שירות.
אם אתם מפעילים את השער המנפיק, יישרו את תקציב במעלה הזרם שלו עם עומס העבודה הנתמך ועם מועדי היעד שסביבו. אם לא, שמרו את תוצאתו כראיה והשתמשו במסלול הגישה או התמיכה המתועד של המפעיל. המתנה ארוכה יותר באופן מקומי אינה יכולה לשנות תגובה שכבר הגיעה.