‫۵۰۲ دروازه نادرست پایان غیرمنتظره فایل

درحال مشاهده اسناد 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 است که می‌تواند به‌دلایل زیر ایجاد شود:

مراحل متداول تشخیص خرابی

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

• پایش میانای برنامه‌سازی کاربردی
• ابزار ردیابی
• گزارش‌های دسترسی NGINX

دلیل: سرور مقصد به‌درستی پیکربندی نشده است

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

تشخیص

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

      در این صورت، احتمالاً این مشکل ناشی از پیکربندی نادرست سرور مقصد است.

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

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

   2. اگر کاربر «ابر خصوصی» هستید، از این 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 درخواست‌های میانای برنامه‌سازی کاربردی را که به سرور هدف خاص می‌روند به‌عنوان درخواست‌های HTTP (غیرایمن) درنظر بگیرد. بنابراین Edge فرایند «دست دادن SSL» را با این سرور هدف آغاز نخواهد کرد.

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

وضوح

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

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

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

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

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

      <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 >

مرجع‌ها

تراز کردن بار در سرورهای زیرینه

دلیل: EOFException از سرور زیرینه

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

تشخیص

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

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

   "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 که ازقبل برقرار شده است تا دوباره استفاده شود، عملکرد را بهبود دهند، که این امر سربار تأخیر را کاهش می‌دهد. مدت زمانی که اتصال باید پایدار بماند ازطریق دارایی مهلت زمان زنده نگه داشتن (keepalive.timeout.millis) کنترل می‌شود.

هم سرور زیرینه و هم «پردازنده پیام Apigee» از مهلت‌های زمانی «اتصال زنده» برای باز نگه داشتن اتصال‌های بین خود استفاده می‌کنند. وقتی در مدت زمان وقفه زنده نگه داشتن داده‌ای دریافت نشود، سرور زیرینه یا «پردازشگر پیام» می‌تواند اتصال با طرف دیگر را ببندد.

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

پیامد پیکربندی نادرست مهلت زمان زنده نگه داشتن

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

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

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

در این مورد، مشاهده کردیم که خطای 502 به‌دلیل پیکربندی مقدار زمان اتمام یکسان ۶۰ ثانیه‌ای برای هر دو «پردازشگر پیام» و سرور زیرینه رخ داده است. به‌همین ترتیب، اگر مقدار بالاتری برای مهلت زمانی فعال نگه داشتن در «پردازشگر پیام» نسبت به سرور زیرینه پیکربندی شده باشد، این مشکل نیز ممکن است رخ دهد.

تشخیص

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

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

      می‌توانید با کمک 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 است. برای اعتبارسنجی این مورد، مقایسه مهلت زمانی فعال نگه داشتن در Apigee و سرور نهایی را ببینید.

مقایسه کردن زمان اتمام زنده نگه داشتن در Apigee و سرور زیرینه

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

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

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

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

   در مثال بالا، ویژگی مهلت زمان اتمام زنده نگه داشتن با مقدار ۳۰ ثانیه (30000 میلی‌ثانیه) ملغی می‌شود.

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

وضوح

مطمئن شوید که ویژگی مهلت زمانی فعال نگه داشتن در Apigee (در «پراکسی API» و جزء «پردازشگر پیام») همیشه کمتر از مقدار آن در سرور زیرینه باشد.

1. مقدار تنظیم‌شده برای مهلت زمانی فعال نگه داشتن در سرور نهایی را تعیین کنید.
2. مقدار مناسبی برای ویژگی مهلت اتمام اتصال فعال در «پراکسی API» یا «پردازشگر پیام» پیکربندی کنید، به‌طوری‌که ویژگی مهلت اتمام اتصال فعال کمتر از مقدار تنظیم‌شده در کارساز زیرینه باشد، بااستفاده از مراحلی که در پیکربندی مهلت اتمام اتصال فعال در «پردازشگرهای پیام» توضیح داده شده است.

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

روال مطلوب

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

1. مهلت زمانی فعال نگه داشتن مشتری باید کمتر از مهلت زمانی فعال نگه داشتن «روتر لبه» باشد.
2. مهلت زمانی فعال نگه داشتن «مسیریاب لبه» باید کمتر از مهلت زمانی فعال نگه داشتن «پردازشگر پیام» باشد.
3. مهلت زمانی فعال نگه داشتن «پردازشگر پیام» باید کمتر از مهلت زمانی فعال نگه داشتن سرور هدف باشد.
4. اگر جهش‌های دیگری در جلو یا پشت Apigee دارید، همین قانون باید اعمال شود. همیشه باید مسئولیت بستن اتصال با بالادست را برعهده کارخواه پایین‌دست بگذارید.

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

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

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

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

اگر کاربر «ابر خصوصی» هستید، اطلاعات زیر را ارائه دهید:

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