502 Hatalı Ağ Geçidi Beklenmeyen EOF

Apigee Edge belgelerini görüntülüyorsunuz.
Apigee X belgelerine gidin. bilgi

Belirti

İstemci uygulaması, API çağrılarına yanıt olarak Bad Gateway mesajıyla birlikte 502 HTTP durum kodunu alır.

502 HTTP durum kodu, istemcinin arka uç sunucularından isteği yerine getirmesi gereken geçerli bir yanıt alamadığı anlamına gelir.

Hata mesajları

İstemci uygulaması aşağıdaki yanıt kodunu alır:

HTTP/1.1 502 Bad Gateway

Ayrıca, aşağıdaki hata mesajını da görebilirsiniz:

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

Olası nedenler

502 Bad Gateway Error hatasının tipik nedenlerinden biri Unexpected EOF hatasıdır. Bunun nedeni aşağıdakilerden biri olabilir:

Neden	Ayrıntılar	Şunun için verilen adımlar:
Yanlış yapılandırılmış hedef sunucu	Hedef sunucu, TLS/SSL bağlantılarını destekleyecek şekilde düzgün yapılandırılmamış.	Edge Herkese Açık ve Özel Bulut kullanıcıları
Arka Uç Sunucusundan EOFException	Arka uç sunucusu EOF aniden gönderebilir.	Yalnızca Edge Private Cloud kullanıcıları
Canlı tutma zaman aşımı yanlış yapılandırılmış	Apigee ve arka uç sunucusunda yanlış yapılandırılmış canlı zaman aşımlarını koruyun.	Edge Herkese Açık ve Özel Bulut kullanıcıları

Yaygın teşhis adımları

Hatayı teşhis etmek için aşağıdaki yöntemlerden herhangi birini kullanabilirsiniz:

• API İzleme
• İzleme aracı
• NGINX erişim günlükleri

Neden: Hedef sunucu yanlış yapılandırılmış

Hedef sunucu, TLS/SSL bağlantılarını destekleyecek şekilde düzgün yapılandırılmamış.

Teşhis

1. 502 hatasının mesaj kimliğini, hata kodunu ve hata kaynağını belirlemek için API İzleme, İzleme aracı veya NGINX erişim günlüklerini kullanın.
2. Etkilenen API için kullanıcı arayüzünde izlemeyi etkinleştirin.
3. Başarısız API isteğinin izi aşağıdakileri gösteriyorsa:
   1. 502 Bad Gateway hatası, hedef akış isteği başlar başlamaz görülür.
   2. error.class, messaging.adaptors.http.UnexpectedEOF. değerini gösterir

      Bu sorun büyük olasılıkla hedef sunucu yapılandırmasının yanlış olmasından kaynaklanıyordur.

4. Edge Management API çağrısını kullanarak hedef sunucu tanımını alın:
   1. Herkese Açık Bulut kullanıcısıysanız şu API'yi kullanın:

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

   2. Private Cloud kullanıcısıysanız şu API'yi kullanın:

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

      Hatalı TargetServer tanımı örneği:

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

5. Resimdeki TargetServer tanımı, aşağıdaki gibi açıklanan tipik yanlış yapılandırmalardan birine örnektir:

   mocktarget.apigee.net hedef sunucusunun, 443 bağlantı noktasında güvenli (HTTPS) bağlantıları kabul edecek şekilde yapılandırıldığını varsayalım. Ancak, hedef sunucu tanımına bakarsanız bunun güvenli bağlantılara yönelik olduğunu belirten başka özellik/bayrak yoktur. Bu durum, Edge'in belirli hedef sunucuya giden API isteklerini HTTP (güvenli olmayan) istekleri olarak işlemesine neden olur. Bu nedenle Edge, bu hedef sunucuyla SSL El Sıkışma işlemini başlatmaz.

   Hedef sunucu, 443 üzerinde yalnızca HTTPS (SSL) isteklerini kabul edecek şekilde yapılandırıldığından Edge'den gelen isteği reddeder veya bağlantıyı kapatır. Bu nedenle, Mesaj İşleyici'de UnexpectedEOFAtTarget hatası alırsınız. Mesaj İşleyici, istemciye yanıt olarak 502 Bad Gateway gönderir.

Çözünürlük

Hedef sunucunun her zaman gereksinimlerinize uygun şekilde yapılandırıldığından emin olun.

Yukarıdaki örnek için güvenli (HTTPS/SSL) bir hedef sunucusuna istek göndermek istiyorsanız enabled işareti true olarak ayarlanmış SSLInfo özelliklerini eklemeniz gerekir. Hedef uç nokta tanımında hedef sunucu için SSLInfo özelliklerinin eklenmesine izin verilse de karışıklığı önlemek için SSLInfo özelliklerinin hedef sunucu tanımının bir parçası olarak eklenmesi önerilir.

1. Arka uç hizmeti tek yönlü SSL iletişimi gerektiriyorsa:
   1. enabled işaretinin doğru olarak ayarlandığı SSLInfo özelliklerini aşağıda gösterildiği gibi ekleyerek TargetServer tanımında TLS/SSL'yi etkinleştirmeniz gerekir:

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

   2. Hedef sunucunun sertifikasını Edge'de doğrulamak istiyorsanız güven deposunu (hedef sunucunun sertifikasını içerir) aşağıda gösterildiği gibi de eklememiz gerekir:

      <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. Arka uç hizmeti iki yönlü SSL iletişimi gerektiriyorsa:
   1. Aşağıda gösterildiği gibi ClientAuthEnabled, Keystore, KeyAlias ve Truststore işaretlerine sahip SSLInfo özelliklerinin uygun şekilde ayarlanmış olması gerekir:

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

Referanslar

Arka uç sunucuları arasında yük dengeleme

Neden: Arka uç sunucudan EOFException

Arka uç sunucusu EOF (Dosya Sonu) aniden gönderebilir.

Teşhis

1. 502 hatasının mesaj kimliğini, hata kodunu ve hata kaynağını belirlemek için API İzleme, İzleme aracı veya NGINX erişim günlüklerini kullanın.
2. Mesaj İşleyici günlüklerini (/opt/apigee/var/log/edge-message-processor/logs/system.log) kontrol edip belirli API için eof unexpected olup olmadığını veya API isteği için benzersiz messageid olup olmadığını öğrenmek amacıyla arama yapın.

   İleti İşleyici günlüğündeki istisna yığını izleme örneği

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

   Yukarıdaki örnekte, Mesaj İşleyici arka uç sunucusundan bir yanıt okumaya çalışırken java.io.EOFException: eof unexpected hatasının oluştuğunu görebilirsiniz. Bu istisna, dosya bitişinin (EOF) veya akış sonuna beklenmedik bir şekilde ulaşıldığını gösterir.

   Diğer bir deyişle, Mesaj İşleyici, API isteğini arka uç sunucusuna göndermiş ve yanıtı bekliyordur veya okumaktadır. Ancak, Mesaj İşleyici yanıtı almadan veya yanıtın tamamını okuyamadan arka uç sunucusu bağlantıyı aniden sonlandırdı.

3. Arka uç sunucu günlüklerinizi kontrol edin ve arka uç sunucusunun bağlantıyı aniden sonlandırmasına yol açmış olabilecek herhangi bir hata veya bilgi olup olmadığını kontrol edin. Herhangi bir hata veya bilgi bulursanız Çözüm bölümüne gidin ve arka uç sunucunuzda sorunu uygun şekilde düzeltin.
4. Arka uç sunucunuzda herhangi bir hata veya bilgi bulamazsanız Mesaj İşleyicilerinde tcpdump çıkışını toplayın:
   1. Arka uç sunucusu ana makinenizin tek bir IP adresi varsa aşağıdaki komutu kullanın:

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

   2. Arka uç sunucusu ana makinenizde birden fazla IP adresi varsa aşağıdaki komutu kullanın:

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

      Genellikle bu hatanın nedeni, Mesaj İşleyici isteği arka uç sunucusuna gönderir göndermez arka uç sunucusunun [FIN,ACK] ile yanıt vermesidir.

5. Aşağıdaki tcpdump örneğini inceleyin.

   502 Bad Gateway Error (UnexpectedEOFAtTarget) gerçekleştiğinde tcpdump örneği alındı

   

6. TCPDump sonucundan aşağıdaki etkinlik sırasını görürsünüz:
   1. 985 paketinde, Mesaj İşleyici API isteğini arka uç sunucusuna gönderir.
   2. 986 paketinde, arka uç sunucusu hemen [FIN,ACK] ile yanıt verir.
   3. 987 paketinde Mesaj İşleyici, arka uç sunucusuna [FIN,ACK] ile yanıt verir.
   4. Sonuçta her iki taraftan da [ACK] ve [RST] ile olan bağlantılar kapanır.
   5. Arka uç sunucu [FIN,ACK] bilgisini gönderdiğinden Mesaj İşleyici'de java.io.EOFException: eof unexpected istisnasına sahip olursunuz.
7. Bu durum, arka uç sunucuda bir ağ sorunu olduğunda ortaya çıkabilir. Bu sorunu daha ayrıntılı bir şekilde araştırmaları için ağ operasyonları ekibinizle iletişime geçin.

Çözünürlük

Arka uç sunucuda sorunu uygun şekilde düzeltin.

Sorun devam ediyorsa ve 502 Bad Gateway Error ile ilgili sorunları giderme konusunda yardıma ihtiyacınız varsa veya bunun Edge'de sorun olduğundan şüpheleniyorsanız Apigee Edge Destek Ekibi ile iletişime geçin.

Neden: Yanlış yapılandırılmış "Keep alive zaman aşımı" yanlış

502 hatalarının nedeninin bu olup olmadığını teşhis etmeden önce lütfen aşağıdaki kavramları okuyun.

Apigee'deki kalıcı bağlantılar

Apigee, varsayılan olarak (ve HTTP/1.1 standardına uygun olarak) hedef arka uç sunucusuyla iletişim kurarken kalıcı bağlantılar kullanır. Kalıcı bağlantılar, kurulu bir TCP'nin ve (varsa) TLS/SSL bağlantısının yeniden kullanılmasına izin vererek performansı artırabilir. Bu da gecikme ek yükünü azaltır. Bir bağlantının sürdürülmesi gereken süre, bir keep alive zaman aşımı (keepalive.timeout.millis) özelliği aracılığıyla kontrol edilir.

Hem arka uç sunucusu hem de Apigee Mesaj İşleyicisi, bağlantıların birbiriyle açık kalmasını sağlamak için zaman aşımlarını sürekli olarak kullanır. Canlı tutma zaman aşımı süresi içinde hiçbir veri alınmadığında arka uç sunucusu veya Mesaj İşleyici, diğer sunucuyla olan bağlantıyı kapatabilir.

Apigee'de Mesaj İşleyiciye dağıtılan API Proxy'lerinde varsayılan olarak, geçersiz kılınmadığı sürece koruma zaman aşımı 60s olarak ayarlanır. 60s için veri alınmadığında Apigee, arka uç sunucusuyla bağlantıyı kapatır. Arka uç sunucusu da canlı tutma zaman aşımını korur ve bu süre sona erdiğinde arka uç sunucusu, Mesaj İşleyici ile bağlantıyı kapatır.

Hatalı "canlı tutma zaman aşımı" yapılandırmasının belirtilmesi

Apigee veya arka uç sunucusu yanlış keep alive zaman aşımlarıyla yapılandırılırsa bu durum, arka uç sunucusunun kaynak isteğine yanıt olarak beklenmedik bir End Of File (FIN) göndermesine neden olan bir yarış koşuluna neden olur.

Örneğin, keep alive zaman aşımı API Proxy'sinde veya Mesaj İşleyici'de yukarı akış arka uç sunucusunun zaman aşımından büyük ya da buna eşit bir değerle yapılandırılmışsa aşağıdaki yarış koşulu gerçekleşebilir. Yani Mesaj İşleyici, arka uç sunucusunun canlı kalma zaman aşımı eşiğine çok yakın olana kadar herhangi bir veri almazsa bir istek gelir ve mevcut bağlantıyı kullanarak arka uç sunucusuna gönderilir. Bu durum, aşağıda açıklandığı gibi Beklenmeyen EOF hatası nedeniyle 502 Bad Gateway sorununa yol açabilir:

1. Hem Mesaj İşleyici hem de arka uç sunucusunda saklama zaman aşımı süresinin 60 saniye olduğunu ve belirli Mesaj İşleyici tarafından önceki isteğin sunulmasının üzerinden 59 saniye geçmeden yeni istek gelmediğini varsayalım.
2. Mesaj İşleyici devam edip 59. saniyede gelen isteği mevcut bağlantıyı kullanarak işler (koruma zaman aşımı henüz sona ermediğinden) ve isteği arka uç sunucusuna gönderir.
3. Ancak, istek arka uç sunucuya ulaşmadan önce arka uç sunucusunda koruma zaman aşımı eşiği aşılmıştır.
4. Mesaj İşleyici'nin bir kaynak isteği devam ediyor, ancak arka uç sunucusu Mesaj İşleyici'ye bir FIN paketi göndererek bağlantıyı kapatmaya çalışıyor.
5. Mesaj İşleyici verilerin alınmasını beklerken bunun yerine beklenmedik FIN alır ve bağlantı sonlandırılır.
6. Bu, bir Unexpected EOF ile sonuçlanır ve daha sonra, Mesaj İşleyici tarafından istemciye bir 502 döndürülür.

Bu durumda, 502 hatasının, hem Mesaj İşleyici hem de arka uç sunucusunda 60 saniyelik aynı keep alive zaman aşımı değerinin yapılandırılmış olması nedeniyle oluştuğunu gözlemledik. Benzer şekilde, Mesaj İşleyici'de koruma zaman aşımı için arka uç sunucusuna göre daha yüksek bir değer yapılandırıldığında da bu sorun ortaya çıkabilir.

Teşhis

1. Herkese Açık Bulut kullanıcısıysanız:
   1. API İzleme veya İzleme aracını kullanın (Yaygın teşhis adımları bölümünde açıklandığı gibi) ve aşağıdaki ayarların ikisine de sahip olduğunuzu doğrulayın:
      • Hata kodu: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • Hata kaynağı: target
   2. Daha fazla inceleme için tcpdump kullanma bölümüne gidin.
2. Private Cloud kullanıcısıysanız:
   1. 502 hatasının mesaj kimliğini, hata kodunu ve hata kaynağını belirlemek için İzleme aracını veya NGINX erişim günlüklerini kullanın.
   2. Mesaj İşleyici günlüğünde
      (/opt/apigee/var/log/edge-message-processor/logs/system.log) mesaj kimliğini arayın.
   3. java.io.EOFEXception: eof unexpected aşağıdaki şekilde görünür:

      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 hatası, Mesaj İşleyicinin arka uç sunucusundan yanıt okumayı beklerken bir EOF aldığını belirtir.
   5. Yukarıdaki hata mesajındaki useCount=7 özelliği, Mesaj İşleyici'nin bu bağlantıyı yaklaşık yedi kez yeniden kullandığını ve bytesWritten=159 özelliği, Mesaj İşleyicinin 159 baytlık istek yükünü arka uç sunucuya gönderdiğini belirtir. Ancak, beklenmedik EOF gerçekleştiğinde sıfır bayt geri aldı.

   6. Bu durum, Mesaj İşleyicinin aynı bağlantıyı birden çok kez yeniden kullandığını ve bu örnekte, veri gönderdiğini ancak kısa süre sonra herhangi bir veri alınmadan önce bir EOF aldığını gösterir. Bu da arka uç sunucusunun aktif tutma zaman aşımı süresinin API proxy'sinde ayarlanandan daha kısa veya bu süreye eşit olma olasılığının yüksek olduğu anlamına gelir.

      Aşağıda açıklandığı gibi tcpdump yardımıyla daha ayrıntılı inceleme yapabilirsiniz.

tcpdump kullanma

1. Aşağıdaki komutla arka uç sunucuda tcpdump yakalayın:

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

2. Yakalanan tcpdump öğesini analiz edin:

   Örnek tcpdump çıkışını burada bulabilirsiniz:

   

   Yukarıdaki tcpdump örneğinde şunları görebilirsiniz:

   1. 5992, paketinde arka uç sunucusu GET isteği aldı.
   2. 6064 paketinde 200 OK. ile yanıt veriyor
   3. 6084 paketinde, arka uç sunucusu başka bir GET isteği aldı.
   4. 6154 paketinde 200 OK ile yanıt verir.
   5. 6228 paketinde, arka uç sunucusu üçüncü bir GET isteği aldı.
   6. Bu kez arka uç sunucusu, bağlantıyı kapatma işlemini başlatmak için Mesaj İşleyiciye (6285 paketi) bir FIN, ACK döndürür.

   Bu örnekte aynı bağlantı iki kez başarıyla yeniden kullanılmış, ancak üçüncü istekte arka uç sunucusu bağlantı kapatma işlemini başlatırken Mesaj İşleyici arka uç sunucudan gelen verileri bekliyordur. Bu, arka uç sunucusunun hayatta kalma zaman aşımı süresinin büyük olasılıkla API proxy'sinde ayarlanan değere eşit veya daha kısa olduğunu gösterir. Bu durumu doğrulamak için Apigee ve arka uç sunucusunda keep alive zaman aşımını karşılaştırma başlıklı makaleyi inceleyin.

Apigee ile arka uç sunucusunda koruma zaman aşımını karşılaştırma

1. Apigee, keep alive zaman aşımı özelliği için varsayılan olarak 60 saniyelik bir değer kullanır.

2. Bununla birlikte, API proxy'sindeki varsayılan değeri geçersiz kılmış olabilirsiniz. 502 hatalarını veren başarısız API Proxy'sindeki belirli TargetEndpoint tanımını kontrol ederek bunu doğrulayabilirsiniz.

   Örnek TargetEndpoint yapılandırması:

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

   Yukarıdaki örnekte, keep alive zaman aşımı özelliği 30 saniye (30000 milisaniye) değeriyle geçersiz kılınmıştır.

3. Ardından, arka uç sunucunuzda yapılandırılan keep alive zaman aşımı özelliğini kontrol edin. Arka uç sunucunuzun 25 seconds değeriyle yapılandırıldığını varsayalım.
4. Apigee'deki keep alive zaman aşımı özelliğinin değerinin, yukarıdaki örnekte olduğu gibi arka uç sunucusundaki keep alive zaman aşımı özelliğinin değerinden yüksek olduğunu belirlerseniz 502 hatalarının nedeni budur.

Çözünürlük

Canlı tutma zaman aşımı özelliğinin, Apigee'deki (API Proxy ve Mesaj İşleyici bileşeninde) arka uç sunucusuna kıyasla her zaman daha düşük olduğundan emin olun.

1. Arka uç sunucusunda "canlı tutma zaman aşımı" için ayarlanan değeri belirleyin.
2. Mesaj İşleyicilerinde Keep zaman aşımını yapılandırma bölümünde açıklanan adımları uygulayarak API Proxy'sinde veya Mesaj İşleyici'de Keep alive zaman aşımı özelliği için uygun bir değeri yapılandırın.

Sorun devam ederse Teşhis bilgileri toplanmalı bölümüne gidin.

En İyi Uygulama

Bu tür yarış koşullarından ve 502 hatalarından kaçınmak için aşağı akış bileşenlerinin, yukarı akış sunucularında yapılandırılandan her zaman daha düşük bir canlı tutma zaman aşımı eşiğine sahip olması kesinlikle önerilir. Her aşağı akış durak, her bir yukarı akıştan düşük olmalıdır. Apigee Edge'de aşağıdaki yönergeleri kullanmak iyi bir uygulamadır:

1. İstemciyi canlı tutma zaman aşımı, Uç Yönlendiricinin etkin tutma zaman aşımı değerinden kısa olmalıdır.
2. Uç Yönlendiricinin canlı tutma zaman aşımı değeri, Mesaj İşleyiciyi canlı tutma zaman aşımından kısa olmalıdır.
3. Mesaj İşleyiciyi canlı tutma zaman aşımı, hedef sunucunun canlı tutma zaman aşımından kısa olmalıdır.
4. Apigee'nin önünde veya arkasında başka duraklarınız varsa aynı kural uygulanmalıdır. Yukarı akış bağlantısını kapatmayı her zaman aşağı akış istemcisinin sorumluluğunda bırakmalısınız.

Teşhis bilgileri toplanmalıdır

Yukarıdaki talimatları uygulamanıza rağmen sorun devam ederse aşağıdaki teşhis bilgilerini toplayıp Apigee Edge Destek Ekibi ile iletişime geçin.

Herkese Açık Bulut kullanıcısıysanız aşağıdaki bilgileri sağlayın:

• Kuruluş adı
• Ortam adı
• API Proxy adı
• 502 hatasını yeniden oluşturmak için curl komutunu tamamlayın
• 502 Bad Gateway - Unexpected EOF hatasına sahip istekleri içeren izleme dosyası
• Şu anda 502 hataları ortaya çıkmıyorsa geçmişte 502 hatalarının meydana geldiği zaman dilimiyle ilgili tarih aralığını sağlayın.

Private Cloud kullanıcısıysanız aşağıdaki bilgileri sağlayın:

• Başarısız istekler için gözlemlenen tam hata mesajı
• 502 hatalarını gözlemlediğiniz kuruluş, ortam adı ve API proxy adı
• API Proxy paketi
• 502 Bad Gateway - Unexpected EOF hatasına sahip istekleri içeren izleme dosyası
• NGINX erişim günlükleri
  /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
• Mesaj İşleyici günlükleri
  /opt/apigee/var/log/edge-message-processor/logs/system.log
• 502 hatalarının oluştuğu saat dilimi bilgilerinin yer aldığı dönem
• Hata oluştuğunda Mesaj İşleyicilerinde, arka uç sunucusunda veya her ikisinde birden toplanan Tcpdumps