502 Bad Gateway EOF غیر منتظره

شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات

علامت

برنامه مشتری کد وضعیت HTTP 502 را با پیام Bad Gateway به عنوان پاسخی برای تماس های API دریافت می کند.

کد وضعیت HTTP 502 به این معنی است که مشتری پاسخ معتبری از سرورهای باطن دریافت نمی کند که در واقع باید درخواست را برآورده کند.

پیام های خطا

برنامه مشتری کد پاسخ زیر را دریافت می کند:

HTTP/1.1 502 Bad Gateway

علاوه بر این، ممکن است پیغام خطای زیر را مشاهده کنید:

{
   "fault": {
      "faultstring": "Unexpected EOF at target",
      "detail": {
           "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget"
       }
    }
}

علل احتمالی

یکی از دلایل معمول 502 Bad Gateway Error خطای Unexpected EOF است که می تواند به دلایل زیر ایجاد شود:

مراحل تشخیص رایج

برای تشخیص خطا می توانید از یکی از روش های زیر استفاده کنید:

• مانیتورینگ API
• ابزار ردیابی
• گزارش های دسترسی NGINX

علت: پیکربندی نادرست سرور هدف

سرور هدف برای پشتیبانی از اتصالات TLS/SSL به درستی پیکربندی نشده است.

تشخیص

1. برای تعیین شناسه پیام، کد خطا و منبع خطا برای خطای 502 از API Monitoring ، Trace tool یا گزارش های دسترسی NGINX استفاده کنید.
2. ردیابی را در UI برای API آسیب دیده فعال کنید.
3. اگر ردیابی درخواست API ناموفق موارد زیر را نشان دهد:
   1. خطای 502 Bad Gateway به محض شروع درخواست جریان هدف مشاهده می شود.
   2. error.class messaging.adaptors.http.UnexpectedEOF.

      سپس به احتمال زیاد این مشکل به دلیل پیکربندی نادرست سرور هدف ایجاد شده است.

4. با استفاده از فراخوانی API مدیریت Edge، تعریف سرور مورد نظر را دریافت کنید:
   1. اگر کاربر Public Cloud هستید، از این API استفاده کنید:

      curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

   2. اگر کاربر Private Cloud هستید، از این API استفاده کنید:

      curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

      نمونه تعریف TargetServer معیوب:

      <TargetServer  name="target1">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer >

5. تعریف TargetServer مصور مثالی برای یکی از پیکربندی های اشتباه معمولی است که به شرح زیر توضیح داده شده است:

   بیایید فرض کنیم که سرور هدف mocktarget.apigee.net برای پذیرش اتصالات امن (HTTPS) در پورت 443 پیکربندی شده است. با این حال، اگر به تعریف سرور هدف نگاه کنید، هیچ ویژگی/پرچم دیگری وجود ندارد که نشان دهد برای اتصالات امن در نظر گرفته شده است. این باعث می‌شود که Edge با درخواست‌های API که به سرور هدف خاص می‌روند به‌عنوان درخواست‌های HTTP (غیر امن) رفتار کند. بنابراین Edge فرآیند SSL Handshake را با این سرور مورد نظر آغاز نخواهد کرد.

   از آنجایی که سرور هدف به گونه ای پیکربندی شده است که فقط درخواست های HTTPS (SSL) را روی 443 بپذیرد، درخواست Edge را رد می کند یا اتصال را می بندد. در نتیجه، یک خطای UnexpectedEOFAtTarget در پردازشگر پیام دریافت می کنید. پردازشگر پیام 502 Bad Gateway به عنوان پاسخ به مشتری ارسال می کند.

قطعنامه

همیشه مطمئن شوید که سرور مورد نظر مطابق با نیاز شما به درستی پیکربندی شده است.

برای مثال نشان داده شده در بالا، اگر می‌خواهید به یک سرور هدف ایمن (HTTPS/SSL) درخواست بدهید، باید ویژگی‌های SSLInfo با پرچم enabled تنظیم شده روی true وارد کنید. در حالی که مجاز است ویژگی‌های SSLInfo برای یک سرور هدف در خود تعریف نقطه پایانی هدف اضافه کند، توصیه می‌شود برای جلوگیری از هرگونه سردرگمی، ویژگی‌های SSLInfo را به عنوان بخشی از تعریف سرور هدف اضافه کنید.

1. اگر سرویس باطن به ارتباط SSL یک طرفه نیاز دارد، پس:
   1. شما باید TLS/SSL را در تعریف TargetServer با گنجاندن ویژگی‌های SSLInfo در جایی که پرچم enabled روی true تنظیم شده است، فعال کنید.

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
        <SSLInfo>
            <Enabled>true</Enabled>
        </SSLInfo>
      </TargetServer>

   2. اگر می‌خواهید گواهی سرور هدف را در Edge تأیید کنید، باید طبق شکل زیر، Truststore (حاوی گواهی سرور هدف) را نیز اضافه کنیم:

      <TargetServer  name="mocktarget">
          <Host>mocktarget.apigee.net</Host>
          <Port>443</Port>
          <IsEnabled>true</IsEnabled>
          <SSLInfo>
              <Ciphers/>
              <ClientAuthEnabled>false</ClientAuthEnabled>
              <Enabled>true</Enabled>
              <IgnoreValidationErrors>false</IgnoreValidationErrors>
              <Protocols/>
              <TrustStore>mocktarget-truststore</TrustStore>
          </SSLInfo>
      </TargetServer>

2. اگر سرویس پشتیبان به ارتباط دو طرفه SSL نیاز دارد، پس:
   1. شما باید ویژگی‌های SSLInfo را با پرچم‌های ClientAuthEnabled ، Keystore ، KeyAlias ​​و Truststore به طور مناسب تنظیم کنید، همانطور که در زیر نشان داده شده است:

      <TargetServer  name="mocktarget">
           <IsEnabled>true</IsEnabled>
           <Host>www.example.com</Host>
           <Port>443</Port>
           <SSLInfo>
               <Ciphers/>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <Enabled>true</Enabled>
               <IgnoreValidationErrors>false</IgnoreValidationErrors>
               <KeyAlias>keystore-alias</KeyAlias>
               <KeyStore>keystore-name</KeyStore>
               <Protocols/>
               <TrustStore>truststore-name</TrustStore>
           </SSLInfo>
        </TargetServer >

مراجع

تعادل بار در سرورهای باطن

علت: EOFE استثنا از سرور باطن

سرور Backend ممکن است EOF (پایان فایل) را به طور ناگهانی ارسال کند.

تشخیص

1. برای تعیین شناسه پیام، کد خطا و منبع خطا برای خطای 502 از API Monitoring ، Trace tool یا گزارش های دسترسی NGINX استفاده کنید.
2. گزارش‌های پردازشگر پیام ( /opt/apigee/var/log/edge-message-processor/logs/system.log ) را بررسی کنید و جستجو کنید تا ببینید آیا شما eof unexpected برای API خاص دارید یا messageid منحصر به فرد برای API دارید درخواست کنید، سپس می توانید آن را جستجو کنید.

   نمونه ردیابی پشته استثنایی از گزارش پردازشگر پیام

   "message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {}
   java.io.EOFException: eof unexpected
   at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na]
   at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na]
   at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na]
   at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na]
   at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"

   در مثال بالا، می‌توانید ببینید که خطای java.io.EOFException: eof unexpected در حالی رخ داده است که پردازشگر پیام در تلاش برای خواندن پاسخی از سرور باطن است. این استثنا نشان می دهد که پایان فایل (EOF)، یا پایان جریان به طور غیرمنتظره ای رسیده است.

   یعنی پردازشگر پیام درخواست API را به سرور باطن ارسال کرد و منتظر بود یا پاسخ را می خواند. با این حال، سرور باطن قبل از اینکه پردازشگر پیام پاسخ را دریافت کند یا بتواند پاسخ کامل را بخواند، اتصال را به طور ناگهانی قطع کرد.

3. گزارش‌های سرور بک‌اند خود را بررسی کنید و ببینید آیا خطا یا اطلاعاتی وجود دارد که می‌تواند منجر به قطع ناگهانی اتصال سرور باطن شود. اگر خطا/اطلاعاتی پیدا کردید، به Resolution بروید و مشکل را به طور مناسب در سرور باطن خود برطرف کنید.
4. اگر هیچ خطا یا اطلاعاتی در سرور باطن خود پیدا نکردید، خروجی tcpdump را در پردازشگرهای پیام جمع آوری کنید:
   1. اگر میزبان سرور باطن شما یک آدرس IP واحد دارد، از دستور زیر استفاده کنید:

      tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME

   2. اگر میزبان سرور باطن شما چندین آدرس IP دارد، از دستور زیر استفاده کنید:

      tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME

      به طور معمول، این خطا به این دلیل ایجاد می شود که به محض اینکه پردازشگر پیام درخواست را به سرور باطن ارسال می کند، با [FIN,ACK] پاسخ می دهد.

5. مثال tcpdump زیر را در نظر بگیرید.

   نمونه tcpdump زمانی که 502 Bad Gateway Error ( UnexpectedEOFAtTarget ) رخ داد گرفته شد

   

6. از خروجی TCPDump ، دنباله ای از رویدادها را متوجه می شوید:
   1. در بسته 985 ، پردازشگر پیام درخواست API را به سرور باطن ارسال می کند.
   2. در بسته 986 ، سرور پشتیبان بلافاصله با [FIN,ACK] پاسخ می دهد.
   3. در بسته 987 ، پردازشگر پیام با [FIN,ACK] به سرور پشتیبان پاسخ می دهد.
   4. در نهایت اتصالات با [ACK] و [RST] از هر دو طرف بسته می شوند.
   5. از آنجایی که سرور باطن [FIN,ACK] را می فرستد، شما استثنا java.io.EOFException: eof unexpected در پردازشگر پیام دریافت می کنید.
7. اگر مشکلی در شبکه در سرور پشتیبان وجود داشته باشد، ممکن است این اتفاق بیفتد. تیم عملیات شبکه خود را برای بررسی بیشتر این موضوع درگیر کنید.

قطعنامه

مشکل را در سرور باطن به طور مناسب برطرف کنید.

اگر مشکل همچنان ادامه دارد و برای عیب‌یابی 502 Bad Gateway Error به کمک نیاز دارید یا مشکوک هستید که مشکلی در Edge است، با پشتیبانی Apigee Edge تماس بگیرید.

علت: پیکربندی نادرست، مهلت زمانی ماندن زنده است

قبل از اینکه تشخیص دهید آیا این دلیل خطاهای 502 است، لطفاً مفاهیم زیر را بخوانید.

اتصالات مداوم در Apigee

Apigee به‌طور پیش‌فرض (و به دنبال استاندارد HTTP/1.1) هنگام برقراری ارتباط با سرور باطن هدف، از اتصالات دائمی استفاده می‌کند. اتصالات دائمی می توانند با اجازه دادن به استفاده مجدد از اتصال TCP از قبل ایجاد شده و (در صورت وجود) TLS/SSL، کارایی را افزایش دهند، که سربار تأخیر را کاهش می دهد. مدت زمانی که یک اتصال باید ادامه داشته باشد از طریق ویژگی keep alive timeout کنترل می شود ( keepalive.timeout.millis ).

هر دو سرور Backend و Apigee Message Processor از وقفه های زمانی استفاده می کنند تا اتصالات را با یکدیگر باز نگه دارند. هنگامی که هیچ داده ای در مدت زمان باز ماندن زنده دریافت نشد، سرور پشتیبان یا پردازشگر پیام می تواند ارتباط را با دیگری ببندد.

پروکسی‌های API مستقر در یک پردازشگر پیام در Apigee، به‌طور پیش‌فرض، دارای بازه زمانی ماندن زنده روی 60s هستند، مگر اینکه لغو شوند. هنگامی که هیچ داده ای برای 60s دریافت نشد، Apigee اتصال با سرور باطن را می بندد. سرور بک‌اند نیز یک بازه زمانی نگه‌داشتن زنده را حفظ می‌کند، و پس از انقضای آن، سرور باطن ارتباط را با پردازشگر پیام می‌بندد.

مفهوم پیکربندی نادرست زمان توقف زنده نگه داشتن زنده

اگر Apigee یا سرور بک‌اند با وقفه‌های نگه داشتن زنده نادرست پیکربندی شده باشند، منجر به یک شرایط مسابقه می‌شود که باعث می‌شود سرور باطن در پاسخ به درخواست منبع، یک End Of File (FIN) ارسال کند.

به عنوان مثال، اگر مهلت زمانی نگه داشتن زنده در پروکسی API یا پردازشگر پیام با مقداری بزرگتر یا مساوی با زمان پایان سرور باطن بالا پیکربندی شده باشد، شرایط مسابقه زیر می تواند رخ دهد. یعنی اگر پردازشگر پیام هیچ داده ای را تا زمانی که خیلی نزدیک به آستانه سرور باطن زنده نگه دارد دریافت نکند، آنگاه یک درخواست ارسال می شود و با استفاده از اتصال موجود به سرور باطن ارسال می شود. این می تواند به دلیل خطای EOF غیرمنتظره منجر به 502 Bad Gateway شود که در زیر توضیح داده شده است:

1. فرض کنید بازه زمانی نگه داشتن زنده روی هر دو پردازشگر پیام و سرور باطن 60 ثانیه است و هیچ درخواست جدیدی تا 59 ثانیه پس از ارائه درخواست قبلی توسط پردازشگر پیام خاص ارائه نشده است.
2. پردازشگر پیام ادامه می‌دهد و درخواستی را که در ثانیه ۵۹ وارد شده است با استفاده از اتصال موجود پردازش می‌کند (زیرا بازه زمانی نگه داشتن زنده هنوز سپری نشده است) و درخواست را به سرور باطن ارسال می‌کند.
3. با این حال، قبل از رسیدن درخواست به سرور باطن، از آستانه باز ماندن زنده در سرور باطن فراتر رفته است.
4. درخواست پردازشگر پیام برای یک منبع در حین پرواز است، اما سرور باطن تلاش می کند با ارسال یک بسته FIN به پردازشگر پیام، اتصال را ببندد.
5. در حالی که پردازشگر پیام منتظر دریافت داده است، در عوض FIN غیرمنتظره را دریافت می کند و اتصال قطع می شود.
6. این منجر به یک Unexpected EOF می شود و متعاقباً یک 502 توسط پردازشگر پیام به مشتری بازگردانده می شود.

در این مورد، ما مشاهده کردیم که خطای 502 رخ داده است زیرا همان مقدار بازه زمانی 60 ثانیه ای حفظ زنده روی هر دو پردازشگر پیام و سرور باطن پیکربندی شده بود. به طور مشابه، اگر مقدار بالاتری برای زمان ماندن زنده در پردازشگر پیام نسبت به سرور باطن پیکربندی شده باشد، این مشکل ممکن است رخ دهد.

تشخیص

1. اگر کاربر Public Cloud هستید:
   1. از ابزار مانیتورینگ یا ردیابی API (همانطور که در مراحل تشخیص رایج توضیح داده شده است) استفاده کنید و بررسی کنید که هر دو تنظیمات زیر را دارید:
      • کد خطا: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • منبع خطا: target
   2. برای بررسی بیشتر به استفاده از tcpdump بروید.
2. اگر کاربر خصوصی Cloud هستید:
   1. از ابزار Trace یا گزارش های دسترسی NGINX برای تعیین شناسه پیام، کد خطا و منبع خطا برای خطای 502 استفاده کنید.
   2. شناسه پیام را در گزارش پردازشگر پیام جستجو کنید
      ( /opt/apigee/var/log/edge-message-processor/logs/system.log ).
   3. java.io.EOFEXception: eof unexpected مطابق شکل زیر خواهید دید:

      2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1  NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() :  ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms  lastIO=479ms  isOpen=true.onExceptionRead exception: {}
              java.io.EOFException: eof unexpected
              at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45)
              at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103)
              at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80)
              at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51)
              at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)

   4. خطای java.io.EOFException: eof unexpected نشان می دهد که پردازشگر پیام یک EOF دریافت کرده در حالی که هنوز منتظر خواندن پاسخ از سرور باطن بود.
   5. مشخصه useCount=7 در پیغام خطای بالا نشان می دهد که Message Processor حدود هفت بار از این اتصال مجدد استفاده کرده است و ویژگی bytesWritten=159 نشان می دهد که Message Processor بار درخواستی 159 بایتی را به سرور backend ارسال کرده است. با این حال، هنگامی که EOF غیرمنتظره رخ داد، صفر بایت را دریافت کرد.

   6. این نشان می‌دهد که پردازشگر پیام چندین بار از یک اتصال مشابه استفاده کرده است و در این مورد داده‌ها را ارسال می‌کند اما کمی بعد قبل از دریافت هر گونه داده، یک EOF دریافت می‌کند. این به این معنی است که احتمال زیادی وجود دارد که مهلت زمانی زنده نگه داشتن سرور باطن کمتر یا برابر با تنظیم شده در پراکسی API باشد.

      همانطور که در زیر توضیح داده شده است می توانید با کمک tcpdump بیشتر بررسی کنید.

با استفاده از tcpdump

1. با دستور زیر یک tcpdump در سرور باطن ضبط کنید:

   tcpdump -i any -s 0 host MP_IP_Address -w File_Name

2. tcpdump گرفته شده را تجزیه و تحلیل کنید:

   در اینجا یک نمونه خروجی tcpdump آمده است:

   

   در نمونه tcpdump بالا، می توانید موارد زیر را مشاهده کنید:

   1. در بسته 5992, سرور باطن یک درخواست GET دریافت کرد.
   2. در بسته 6064 با 200 OK.
   3. در بسته 6084 ، سرور باطن درخواست GET دیگری دریافت کرد.
   4. در بسته 6154 با 200 OK پاسخ می دهد.
   5. در بسته 6228 ، سرور پشتیبان سومین درخواست GET را دریافت کرد.
   6. این بار، سرور باطن یک FIN, ACK به پردازشگر پیام (بسته 6285 ) باز می‌گرداند و بسته شدن اتصال را آغاز می‌کند.

   در این مثال از همان اتصال مجدداً دو بار با موفقیت استفاده شد، اما در درخواست سوم، سرور باطن شروع به بسته شدن اتصال می‌کند، در حالی که پردازشگر پیام منتظر داده‌های سرور باطن است. این نشان می دهد که مهلت زمانی زنده نگه داشتن سرور باطن به احتمال زیاد کوتاه تر یا برابر با مقدار تنظیم شده در پراکسی API است. برای تأیید این موضوع، به Compare keep alive timeout در Apigee و سرور باطن مراجعه کنید.

زمان ماندن زنده را در سرور Apigee و باطن مقایسه کنید

1. به‌طور پیش‌فرض، Apigee از مقدار 60 ثانیه برای ویژگی timeout keep alive استفاده می‌کند.

2. با این حال، ممکن است شما مقدار پیش فرض را در API Proxy لغو کرده باشید. شما می توانید این را با بررسی تعریف TargetEndpoint خاص در پروکسی API ناموفق که خطاهای 502 می دهد تأیید کنید.

   نمونه پیکربندی TargetEndpoint:

   <TargetEndpoint name="default">
     <HTTPTargetConnection>
       <URL>https://mocktarget.apigee.net/json</URL>
       <Properties>
         <Property name="keepalive.timeout.millis">30000</Property>
       </Properties>
     </HTTPTargetConnection>
   </TargetEndpoint>

   در مثال بالا، ویژگی keep alive timeout با مقدار 30 ثانیه ( 30000 میلی ثانیه) لغو شده است.

3. سپس، ویژگی keep alive timeout پیکربندی شده در سرور باطن خود را بررسی کنید. فرض کنید سرور باطن شما با مقدار 25 seconds پیکربندی شده است.
4. اگر تعیین کنید که مقدار ویژگی keep alive timeout در Apigee از مقدار ویژگی keep alive timeout در سرور باطن مانند مثال بالا بالاتر است، آنگاه این دلیل خطاهای 502 است.

قطعنامه

اطمینان حاصل کنید که ویژگی keep alive timeout همیشه در Apigee (در جزء API Proxy و Message Processor) در مقایسه با سرور backend کمتر است.

1. مقدار تنظیم شده برای بازه زمانی نگه داشتن زنده در سرور باطن را تعیین کنید.
2. با استفاده از مراحل تشریح شده در Configuring keep alive timeout در پردازشگر پیام، مقدار مناسبی را برای ویژگی keep alive timeout در پروکسی API یا پردازشگر پیام پیکربندی کنید، به گونه‌ای که خاصیت timeout نگه‌داشتن زنده کمتر از مقدار تنظیم‌شده در سرور backend باشد.

اگر مشکل همچنان ادامه داشت، به اطلاعات تشخیصی باید جمع‌آوری شود بروید.

بهترین تمرین

اکیداً توصیه می‌شود که مؤلفه‌های پایین‌دست همیشه آستانه‌ای کمتر از زمانی که در سرورهای بالادست پیکربندی شده‌اند، داشته باشند تا از این نوع شرایط مسابقه و خطاهای 502 جلوگیری شود. هر جهش پایین دست باید کمتر از هر پرش بالادست باشد. در Apigee Edge، استفاده از دستورالعمل های زیر تمرین خوبی است:

1. مهلت زمانی نگه داشتن زنده کلاینت باید کمتر از مهلت زمانی Edge Router keep alive باشد.
2. مهلت زمانی Edge Router keep alive باید کمتر از Message Processor keep alive timeout باشد.
3. مهلت زمانی نگه داشتن زنده پردازشگر پیام باید کمتر از مهلت زمانی حفظ زنده بودن سرور مورد نظر باشد.
4. اگر جهش دیگری در جلو یا پشت Apigee دارید، همان قانون باید اعمال شود. همیشه باید آن را به عهده مشتری پایین دستی بگذارید تا ارتباط با بالادست را ببندید.

باید اطلاعات تشخیصی را جمع آوری کرد

اگر حتی پس از پیروی از دستورالعمل‌های بالا، مشکل همچنان ادامه داشت، اطلاعات تشخیصی زیر را جمع‌آوری کنید و سپس با پشتیبانی Apigee Edge تماس بگیرید.

اگر کاربر Public Cloud هستید، اطلاعات زیر را ارائه دهید:

• نام سازمان
• نام محیط زیست
• نام پروکسی API
• برای بازتولید خطای 502 دستور curl را کامل کنید
• فایل ردیابی حاوی درخواست‌های دارای 502 Bad Gateway - Unexpected EOF
• اگر خطاهای 502 در حال حاضر رخ نمی دهند، دوره زمانی را با اطلاعات منطقه زمانی که خطاهای 502 در گذشته رخ داده است ارائه دهید.

اگر کاربر Private Cloud هستید، اطلاعات زیر را ارائه دهید:

• پیام خطای کامل برای درخواست های ناموفق مشاهده شد
• سازمان، نام محیط و نام پروکسی API که برای آنها خطاهای 502 مشاهده می کنید
• بسته پروکسی API
• فایل ردیابی حاوی درخواست‌های دارای 502 Bad Gateway - Unexpected EOF
• گزارش های دسترسی NGINX
  /opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log
• گزارش‌های پردازشگر پیام
  /opt/apigee/var/log/edge-message-processor/logs/system.log
• دوره زمانی با اطلاعات منطقه زمانی که خطاهای 502 رخ داده است
• Tcpdumps جمع آوری شده در پردازشگرهای پیام یا سرور باطن یا هر دو هنگام وقوع خطا