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

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

علامت

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

کد وضعیت HTTP 502 به این معنی است که کلاینت پاسخ معتبری از سرورهای backend که باید درخواست را انجام دهند، دریافت نمی‌کند.

پیام‌های خطا

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

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 یا گزارش‌های دسترسی NGINX استفاده کنید.
2. ردیابی را در رابط کاربری برای API آسیب‌دیده فعال کنید.
3. اگر ردیابی درخواست ناموفق API موارد زیر را نشان دهد:
   1. خطای 502 Bad Gateway به محض شروع درخواست جریان هدف مشاهده می‌شود.
   2. کلاس error.class messaging.adaptors.http.UnexpectedEOF.

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

4. تعریف سرور هدف را با استفاده از فراخوانی API مدیریت Edge دریافت کنید:
   1. اگر کاربر فضای ابری عمومی هستید، از این 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 flag) که روی true تنظیم شده است، وارد کنید. اگرچه اضافه کردن ویژگی‌های SSLInfo برای یک سرور هدف در تعریف خود نقطه پایانی هدف مجاز است، اما توصیه می‌شود ویژگی‌های SSLInfo را به عنوان بخشی از تعریف سرور هدف اضافه کنید تا از هرگونه سردرگمی جلوگیری شود.

1. اگر سرویس backend به ارتباط 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. اگر سرویس backend به ارتباط 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 >

منابع

متعادل‌سازی بار در سرورهای بک‌اند

علت: خطای EOFException از سرور backend

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

تشخیص

1. برای تعیین شناسه پیام، کد خطا و منبع خطا برای خطای 502 ، از API Monitoring ، ابزار Trace یا گزارش‌های دسترسی NGINX استفاده کنید.
2. لاگ‌های پردازشگر پیام ( /opt/apigee/var/log/edge-message-processor/logs/system.log ) را بررسی کنید و جستجو کنید تا ببینید آیا برای API خاص eof unexpected دارید یا اگر 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 در حالی رخ داده است که پردازنده‌ی پیام (Message Processor) در تلاش برای خواندن پاسخی از سرور backend است. این خطا نشان می‌دهد که فایل (EOF) به پایان رسیده است، یا به طور غیرمنتظره‌ای به پایان جریان (stream) رسیده است.

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

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

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

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

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

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

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

   نمونه tcpdump گرفته شده هنگام وقوع 502 Bad Gateway Error ( UnexpectedEOFAtTarget )

   

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

وضوح تصویر

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

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

علت: پیکربندی نادرست زمان انقضای keep-alive

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

اتصالات پایدار در Apigee

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

هم سرور backend و هم پردازشگر پیام Apigee از وقفه‌های keep alive برای باز نگه داشتن ارتباط با یکدیگر استفاده می‌کنند. زمانی که هیچ داده‌ای در مدت زمان وقفه keep alive دریافت نشود، سرور backend یا پردازشگر پیام می‌توانند ارتباط با یکدیگر را ببندند.

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

پیامد پیکربندی نادرست زمان‌بندی keep-alive

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

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

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

در این مورد، مشاهده کردیم که خطای 502 به این دلیل رخ داده است که مقدار زمان انتظار keep alive در هر دو سمت پردازشگر پیام و سرور backend یکسان و برابر با ۶۰ ثانیه تنظیم شده است. به طور مشابه، اگر مقدار زمان انتظار keep alive در پردازشگر پیام بالاتر از سرور backend باشد، این مشکل می‌تواند رخ دهد.

تشخیص

1. اگر شما یک کاربر فضای ابری عمومی هستید:
   1. از ابزار API Monitoring یا Trace (همانطور که در مراحل تشخیص مشترک توضیح داده شده است) استفاده کنید و تأیید کنید که هر دو تنظیمات زیر را دارید:
      • کد خطا: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • منبع خطا: target
   2. برای بررسی بیشتر به بخش استفاده از tcpdump مراجعه کنید.
2. اگر شما یک کاربر فضای ابری خصوصی هستید:
   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 نشان می‌دهد که پردازنده پیام، در حالی که هنوز منتظر خواندن پاسخی از سرور backend بوده، یک EOF دریافت کرده است.
   5. ویژگی useCount=7 در پیام خطای بالا نشان می‌دهد که پردازنده پیام حدود هفت بار از این اتصال استفاده مجدد کرده است و ویژگی bytesWritten=159 نشان می‌دهد که پردازنده پیام درخواست 159 بایتی را به سرور backend ارسال کرده است. با این حال، هنگام وقوع EOF غیرمنتظره، صفر بایت دریافت کرده است.

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

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

استفاده از tcpdump

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

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

2. tcpdump ضبط شده را تجزیه و تحلیل کنید:

   این هم یک نمونه خروجی tcpdump:

   

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

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

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

مقایسه زمان انتظار Keep Alive در سرور Apigee و سرور backend

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

2. با این حال، ممکن است مقدار پیش‌فرض را در API Proxy تغییر داده باشید. می‌توانید با بررسی تعریف خاص TargetEndpoint در API Proxy که خطای 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 که در سرور backend شما پیکربندی شده است را بررسی کنید. فرض کنید سرور backend شما با مقدار 25 seconds پیکربندی شده است.
4. اگر مانند مثال بالا تشخیص دهید که مقدار ویژگی keep alive timeout در Apigee بیشتر از مقدار ویژگی keep alive timeout در سرور backend است، در این صورت دلیل خطای 502 همین است.

وضوح تصویر

مطمئن شوید که مقدار زمان انتظار keep alive در Apigee (در کامپوننت‌های API Proxy و Message Processor) همیشه کمتر از مقدار آن در سرور backend باشد.

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

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

بهترین روش

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

1. زمان انتظار Keep Alive کلاینت باید کمتر از زمان انتظار Keep Alive روتر لبه‌ای باشد.
2. زمان انتظار برای keep-alive روتر لبه باید کمتر از زمان انتظار keep-alive پردازنده پیام باشد.
3. زمان انتظار keep alive در پردازشگر پیام باید کمتر از زمان انتظار keep alive در سرور هدف باشد.
4. اگر هر هاپ دیگری در جلو یا پشت Apigee دارید، همین قانون باید اعمال شود. شما همیشه باید مسئولیت قطع ارتباط با آپ‌استریم را به کلاینت پایین‌دست بسپارید.

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

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

اگر کاربر فضای ابری عمومی هستید، اطلاعات زیر را ارائه دهید:

• نام سازمان
• نام محیط
• نام پروکسی API
• دستور curl را برای بازتولید خطای 502 کامل کنید
• فایل ردیابی حاوی درخواست‌هایی با خطای 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 هنگام بروز خطا روی پردازنده‌های پیام یا سرور backend یا هر دو جمع‌آوری شده‌اند