Trang này được dịch bởi Cloud Translation API.

502 Cổng kết nối bị lỗi EOF không mong muốn

Bạn đang xem tài liệu về Apigee Edge.
Chuyển đến Tài liệu về Apigee X. thông tin

Triệu chứng

Ứng dụng khách sẽ nhận được mã trạng thái HTTP 502 kèm theo thông báo Bad Gateway làm phản hồi cho lệnh gọi API.

Mã trạng thái HTTP 502 có nghĩa là ứng dụng không nhận được phản hồi hợp lệ từ các máy chủ phụ trợ thực sự đáp ứng yêu cầu.

Thông báo lỗi

Ứng dụng sẽ nhận được mã phản hồi sau đây:

HTTP/1.1 502 Bad Gateway

Ngoài ra, bạn có thể nhận thấy thông báo lỗi sau:

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

Các nguyên nhân có thể

Một trong những nguyên nhân điển hình gây ra 502 Bad Gateway Error là Unexpected EOF , có thể do các nguyên nhân sau gây ra:

Nguyên nhân	Thông tin chi tiết	Các bước được cung cấp cho
Máy chủ mục tiêu được định cấu hình không chính xác	Máy chủ đích không được định cấu hình đúng cách để hỗ trợ kết nối TLS/SSL.	Người dùng Edge công khai và riêng tư
EOFException từ máy chủ phụ trợ	Máy chủ phụ trợ có thể gửi EOF đột ngột.	Chỉ dành cho người dùng Edge Private Cloud
Thời gian chờ duy trì hoạt động không được định cấu hình đúng	Duy trì thời gian chờ trực tiếp được định cấu hình không chính xác trên Apigee và máy chủ phụ trợ.	Người dùng Edge công khai và riêng tư

Các bước chẩn đoán phổ biến

Để chẩn đoán lỗi, bạn có thể sử dụng một trong những phương pháp sau:

Giám sát API
Công cụ theo dõi
Nhật ký truy cập NGINX

Giám sát API

Cách chẩn đoán lỗi bằng tính năng Giám sát API:

Khi sử dụng tính năng Giám sát API, bạn có thể điều tra các lỗi 502, bằng cách làm theo các bước như được giải thích trong Tìm hiểu các vấn đề. Đó là:

Chuyển đến trang tổng quan Điều tra.
Chọn Mã trạng thái trong trình đơn thả xuống và đảm bảo chọn đúng thời điểm khoảng thời gian được chọn khi xảy ra 502 lỗi.
Nhấp vào hộp trong ma trận khi bạn thấy số lượng lỗi 502 ở mức cao.
Ở phía bên phải, nhấp vào View Logs (Xem nhật ký) cho các lỗi 502 có thể có dạng như sau:

Tại đây, chúng ta có thể xem những thông tin sau:

Nguồn lỗi là target
Mã lỗi là messaging.adaptors.http.UnexpectedEOFAtTarget

Điều này cho thấy lỗi 502 là do mục tiêu gây ra do EOF ngoài dự kiến.

Ngoài ra, hãy ghi lại Request Message ID cho lỗi 502 để biết thêm cuộc điều tra này.

Công cụ theo dõi

Cách chẩn đoán lỗi bằng công cụ Theo dõi:

Bật theo dõi và thực hiện lệnh gọi API để tái hiện vấn đề 502 Bad Gateway.
Chọn một trong các yêu cầu không thành công rồi kiểm tra dấu vết.
Điều hướng qua các giai đoạn khác nhau của dấu vết và xác định nơi xảy ra lỗi.
Bạn sẽ thấy lỗi sau khi yêu cầu được gửi đến máy chủ đích như minh hoạ dưới đây:

Xác định giá trị của X-Apigee.fault-source và X-Apigee.fault-code trong Giai đoạn AX (Dữ liệu Analytics đã ghi lại) trong dấu vết.

Nếu giá trị của X-Apigee.fault-source và X-Apigee.fault-code khớp với các giá trị hiển thị trong bảng sau, bạn có thể xác nhận rằng lỗi 502 là đến từ máy chủ đích:

Tiêu đề phản hồi	Giá trị
X-Apigee.fault-source	`target`
Mã X-Apigee.fault	`messaging.adaptors.http.flow.UnexpectedEOFAtTarget`

Ngoài ra, hãy ghi lại X-Apigee.Message-ID cho lỗi 502 để điều tra thêm.

Nhật ký truy cập NGINX

Cách chẩn đoán lỗi bằng NGINX:

Bạn cũng có thể tham khảo nhật ký truy cập NGINX để xác định nguyên nhân của trạng thái 502 . Điều này đặc biệt hữu ích nếu vấn đề đã xảy ra trong quá khứ hoặc nếu vấn đề không liên tục và bạn không thể thu thập dấu vết trong giao diện người dùng. Hãy làm theo các bước sau để xác định thông tin này từ nhật ký truy cập NGINX:

Kiểm tra nhật ký truy cập NGINX.
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
Tìm kiếm mọi lỗi 502 của proxy API cụ thể trong một khoảng thời gian cụ thể (nếu vấn đề đã xảy ra trong quá khứ) hoặc với bất kỳ yêu cầu nào vẫn không thành công với 502.

Nếu có lỗi 502 nào, hãy kiểm tra xem lỗi đó có phải do mục tiêu đang gửi Unexpected EOF. Nếu giá trị của X-Apigee.fault-source và X- Apigee.fault-code khớp với các giá trị trong bảng dưới đây, lỗi 502 là do mục tiêu đóng đột ngột kết nối:

Tiêu đề phản hồi	Giá trị
X-Apigee.fault-source	`target`
Mã X-Apigee.fault	`messaging.adaptors.http.flow.UnexpectedEOFAtTarget`

Dưới đây là mục mẫu cho thấy lỗi 502 do máy chủ mục tiêu gây ra:

Ngoài ra, hãy ghi lại mã nhận dạng thư của các lỗi 502 để điều tra thêm.

Nguyên nhân: Máy chủ mục tiêu được định cấu hình không chính xác

Máy chủ đích không được định cấu hình đúng cách để hỗ trợ kết nối TLS/SSL.

Chẩn đoán

Sử dụng Giám sát API, Công cụ theo dõi, hoặc Nhật ký truy cập NGINX để xác định mã nhận dạng thư, mã lỗi và nguồn lỗi của lỗi 502.
Bật tính năng theo dõi trong giao diện người dùng cho API bị ảnh hưởng.
Nếu dấu vết cho yêu cầu API không thành công hiển thị như sau:
1. Lỗi 502 Bad Gateway sẽ xuất hiện ngay khi yêu cầu luồng mục tiêu bắt đầu.
2. error.class hiển thị messaging.adaptors.http.UnexpectedEOF.
  Vậy thì rất có thể vấn đề này là do máy chủ mục tiêu không chính xác gây ra .

Lấy định nghĩa máy chủ mục tiêu bằng lệnh gọi API Quản lý Edge:

Nếu bạn là người dùng Cloud Public, hãy sử dụng API này:

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

Nếu bạn là người dùng Đám mây riêng tư, hãy sử dụng API sau:

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

Định nghĩa TargetServer bị lỗi của mẫu:

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

Định nghĩa TargetServer được minh hoạ là ví dụ cho một trong các cấu hình sai được giải thích như sau:

Giả sử máy chủ mục tiêu mocktarget.apigee.net đã được định cấu hình để chấp nhận kết nối bảo mật (HTTPS) trên cổng 443. Tuy nhiên, nếu bạn nhìn vào định nghĩa máy chủ mục tiêu, không có thuộc tính/gắn cờ nào khác cho biết rằng máy chủ đó đang dành cho kết nối an toàn. Việc này khiến Edge xử lý các yêu cầu API chuyển đến máy chủ mục tiêu cụ thể dưới dạng yêu cầu HTTP (không bảo mật). Vì vậy, Edge sẽ không bắt đầu quá trình Bắt tay SSL với máy chủ mục tiêu này.

Vì máy chủ đích được định cấu hình để chỉ chấp nhận các yêu cầu HTTPS (SSL) trên 443, nên máy chủ sẽ từ chối yêu cầu của Edge hoặc đóng kết nối. Do đó, bạn sẽ nhận được UnexpectedEOFAtTarget lỗi trên Trình xử lý thư. Bộ xử lý tin nhắn sẽ gửi 502 Bad Gateway để phản hồi ứng dụng.

Độ phân giải

Luôn đảm bảo rằng máy chủ đích được định cấu hình đúng theo yêu cầu của bạn.

Đối với ví dụ minh hoạ ở trên, nếu bạn muốn yêu cầu một đích bảo mật (HTTPS/SSL) máy chủ, bạn cần thêm các thuộc tính SSLInfo có bộ cờ enabled đến true. Mặc dù bạn được phép thêm các thuộc tính SSLInfo cho máy chủ mục tiêu trong mục tiêu bản thân định nghĩa điểm cuối, bạn nên thêm thuộc tính SSLInfo làm mục tiêu máy chủ định nghĩa để tránh mọi nhầm lẫn.

Nếu dịch vụ phụ trợ yêu cầu giao tiếp SSL một chiều, thì:

Bạn cần bật TLS/SSL trong định nghĩa TargetServer bằng cách thêm SSLInfo các thuộc tính mà cờ enabled được đặt thành true như minh hoạ dưới đây:

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

Nếu bạn muốn xác thực chứng chỉ của máy chủ mục tiêu trong Edge, thì chúng tôi cũng cần bao gồm kho tin cậy (chứa chứng chỉ của máy chủ mục tiêu) như minh hoạ dưới đây:

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

Nếu dịch vụ phụ trợ yêu cầu giao tiếp SSL hai chiều, thì:

Bạn cần có các thuộc tính SSLInfo với ClientAuthEnabled, Keystore, KeyAlias và Cờ Truststore được thiết lập phù hợp, như minh hoạ dưới đây:

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

Tài liệu tham khảo

Cân bằng tải trên các máy chủ phụ trợ

Nguyên nhân: EOFException từ máy chủ phụ trợ

Máy chủ phụ trợ có thể gửi EOF (Kết thúc tệp) đột ngột.

Chẩn đoán

Sử dụng Giám sát API, Công cụ theo dõi, hoặc Nhật ký truy cập NGINX để xác định mã nhận dạng thư, mã lỗi và nguồn lỗi của lỗi 502.
Kiểm tra nhật ký Trình xử lý thư (/opt/apigee/var/log/edge-message-processor/logs/system.log) và tìm kiếm xem liệu bạn có eof unexpected cho API cụ thể hoặc nếu bạn có messageid duy nhất cho API yêu cầu, sau đó bạn có thể tìm kiếm nó.
Dấu vết ngăn xếp ngoại lệ mẫu từ Nhật ký Trình xử lý thư
```
"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]"
```
Trong ví dụ trên, bạn có thể thấy đã xảy ra lỗi java.io.EOFException: eof unexpected khi Trình xử lý thư đang cố đọc phản hồi từ máy chủ phụ trợ. Ngoại lệ này cho biết phần cuối của tệp (EOF) hoặc phần cuối của luồng đã được truy cập bất ngờ.

Tức là Trình xử lý thư đã gửi yêu cầu API đến máy chủ phụ trợ và đang chờ hoặc đọc câu trả lời. Tuy nhiên, máy chủ phụ trợ đã chấm dứt kết nối đột ngột trước khi Bộ xử lý thư nhận được phản hồi hoặc có thể đọc toàn bộ phản hồi.
Kiểm tra nhật ký máy chủ phụ trợ của bạn và xem có lỗi hoặc thông tin nào có thể đã khiến máy chủ phụ trợ chấm dứt kết nối đột ngột. Nếu bạn tìm thấy bất kỳ lỗi/thông tin, sau đó chuyển đến phần Giải pháp rồi khắc phục vấn đề một cách thích hợp trong máy chủ phụ trợ.
Nếu bạn không tìm thấy lỗi hoặc thông tin nào trong máy chủ phụ trợ, hãy thu thập kết quả tcpdump trên Bộ xử lý thông báo:
1. Nếu máy chủ lưu trữ phụ trợ của bạn có một địa chỉ IP duy nhất, hãy sử dụng lệnh sau:
```
tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME
```
2. Nếu máy chủ lưu trữ phụ trợ của bạn có nhiều địa chỉ IP, hãy sử dụng lệnh sau:
```
tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME
```
  Lưu ý: Nếu bạn đang chạy lệnh này trên Thông báo Bộ xử lý, sử dụng địa chỉ IP/tên máy chủ của máy chủ phụ trợ. Bạn cũng có thể thực hiện tcpdump trên máy chủ phụ trợ. Nếu bạn đang chạy lệnh trên máy chủ phụ trợ, hãy sử dụng địa chỉ IP của Trình xử lý thư trong lệnh tcpdump ở trên.
  
  Thông thường, lỗi này xảy ra do máy chủ phụ trợ phản hồi lại bằng [FIN,ACK] ngay khi Trình xử lý thư gửi yêu cầu đến máy chủ phụ trợ.
Hãy xem xét ví dụ sau đây về tcpdump.

Mẫu tcpdump được chụp khi 502 Bad Gateway Error (UnexpectedEOFAtTarget) đã xảy ra
Từ dữ liệu đầu ra TCPDump, bạn sẽ thấy trình tự các sự kiện sau đây:
1. Trong gói 985, Trình xử lý thư gửi yêu cầu API đến máy chủ phụ trợ.
2. Trong gói 986, máy chủ phụ trợ ngay lập tức phản hồi bằng [FIN,ACK].
3. Trong gói 987, Trình xử lý thư phản hồi bằng [FIN,ACK] với phần phụ trợ máy chủ.
4. Cuối cùng, các kết nối sẽ được đóng lại bằng [ACK] và [RST] ở cả hai phía.
5. Vì máy chủ phụ trợ gửi [FIN,ACK] nên bạn sẽ nhận được ngoại lệ java.io.EOFException: eof unexpected trường hợp ngoại lệ đối với Thông báo Bộ xử lý.
Điều này có thể xảy ra nếu có sự cố về mạng ở máy chủ phụ trợ. Kết nối mạng để điều tra thêm về vấn đề này.

Độ phân giải

Khắc phục vấn đề trên máy chủ phụ trợ một cách thích hợp.

Nếu sự cố vẫn tiếp diễn và bạn cần hỗ trợ khắc phục sự cố 502 Bad Gateway Error hoặc bạn nghi ngờ rằng đó là một vấn đề trong Edge, hãy liên hệ với Bộ phận hỗ trợ Apigee Edge.

Nguyên nhân: Thời gian chờ duy trì hoạt động không được định cấu hình đúng

Trước khi bạn chẩn đoán xem liệu đây có phải là nguyên nhân gây ra lỗi 502 hay không, vui lòng đọc hết những khái niệm sau.

Kết nối liên tục trong Apigee

Theo mặc định, Apigee (và tuân theo tiêu chuẩn HTTP/1.1) sử dụng các kết nối liên tục khi giao tiếp với máy chủ phụ trợ mục tiêu. Kết nối bền vững có thể giúp tăng hiệu suất bằng cách cho phép sử dụng lại kết nối TCP/SSL đã thiết lập (nếu có) giúp giảm chi phí độ trễ. Khoảng thời gian cần duy trì kết nối sẽ được kiểm soát thông qua thuộc tính giữ cho thời gian chờ hoạt động (keepalive.timeout.millis).

Cả máy chủ phụ trợ và Trình xử lý thông báo Apigee đều sử dụng thời gian chờ duy trì hoạt động để duy trì các kết nối mở với nhau. Khi không nhận được dữ liệu nào trong thời gian chờ duy trì hoạt động thì máy chủ phụ trợ hoặc Trình xử lý thư có thể đóng kết nối với máy chủ phụ trợ còn lại.

Theo mặc định, các proxy API được triển khai cho Trình xử lý tin nhắn trong Apigee sẽ đặt thời gian chờ duy trì hoạt động thành 60s trừ phi bị ghi đè. Sau khi không nhận được dữ liệu của 60s, Apigee sẽ đóng kết nối với máy chủ phụ trợ. Máy chủ phụ trợ cũng sẽ duy trì thời gian chờ hoạt động, và khi gói này hết hạn, máy chủ phụ trợ sẽ đóng kết nối với Trình xử lý thông báo.

Ngụ ý việc cấu hình thời gian chờ duy trì hoạt động không chính xác

Nếu Apigee hoặc máy chủ phụ trợ được định cấu hình với thời gian chờ duy trì hoạt động không chính xác, thì dẫn đến một tình huống tương tranh khiến máy chủ phụ trợ gửi một End Of File (FIN) ngoài dự kiến để phản hồi yêu cầu về tài nguyên.

Ví dụ: nếu thời gian chờ duy trì hoạt động được định cấu hình trong Proxy API hoặc Thông báo Bộ xử lý có giá trị lớn hơn hoặc bằng thời gian chờ của máy chủ phụ trợ cấp trên, thì tình huống tương tranh sau đây có thể xảy ra. Tức là nếu Trình xử lý thư không nhận được cho đến khi gần đến ngưỡng của máy chủ phụ trợ duy trì thời gian chờ, sau đó yêu cầu truy cập và được gửi tới máy chủ phụ trợ bằng kết nối hiện có. Điều này có thể dẫn đến 502 Bad Gateway do lỗi EOF ngoài dự kiến, như giải thích dưới đây:

Giả sử thời gian chờ duy trì hoạt động được đặt trên cả Bộ xử lý thông báo và máy chủ phụ trợ là 60 giây và không có nội dung mới yêu cầu đó được đưa ra cho đến 59 giây sau khi yêu cầu trước đó được phân phát bởi Trình xử lý tin nhắn.
Bộ xử lý tin nhắn sẽ tiếp tục và xử lý yêu cầu đến ở giây thứ 59 sử dụng kết nối hiện có (vì thời gian chờ duy trì hoạt động chưa hết) và gửi đến máy chủ phụ trợ.
Tuy nhiên, trước khi yêu cầu đến máy chủ phụ trợ, thời gian chờ duy trì hoạt động đã vượt quá ngưỡng trên máy chủ phụ trợ.
Yêu cầu của Trình xử lý thông báo về tài nguyên đang diễn ra, nhưng máy chủ phụ trợ cố gắng đóng kết nối bằng cách gửi một gói FIN đến Thư Bộ xử lý.
Trong khi Bộ xử lý thư đang chờ nhận dữ liệu thì thay vào đó, Trình xử lý thư sẽ nhận dữ liệu FIN không mong muốn và kết nối bị chấm dứt.
Điều này dẫn đến một Unexpected EOF và sau đó một 502 là Trình xử lý thư trả về cho máy khách.

Trong trường hợp này, chúng tôi nhận thấy lỗi 502 xảy ra do thời gian chờ giữ nguyên trạng thái hoạt động tương tự là 60 giây đã được định cấu hình trên cả Trình xử lý thông báo và máy chủ phụ trợ. Tương tự, sự cố này cũng có thể xảy ra nếu một giá trị cao hơn được định cấu hình để duy trì thời gian chờ trên Thông báo Bộ xử lý hơn là trên máy chủ phụ trợ.

Chẩn đoán

Nếu bạn là người dùng Cloud Public:
1. Sử dụng công cụ Giám sát hoặc Theo dõi API (như giải thích trong Các bước chẩn đoán thông thường) và xác minh rằng bạn đáp ứng cả hai bước sau cài đặt:
  - Mã lỗi: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
  - Nguồn lỗi: target
2. Vui lòng truy cập phần Sử dụng tcpdump để tìm hiểu thêm.
Nếu bạn là người dùng Đám mây riêng tư:
1. Dùng Công cụ theo dõi hoặc Nhật ký truy cập NGINX để xác định mã nhận dạng thư, mã lỗi và nguồn lỗi của lỗi 502.
2. Tìm kiếm mã nhận dạng thư trong nhật ký Trình xử lý thư
  (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Bạn sẽ thấy java.io.EOFEXception: eof unexpected như sau:
```
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. Lỗi java.io.EOFException: eof unexpected cho biết rằng Trình xử lý thư đã nhận được EOF trong khi vẫn đang chờ đọc một phản hồi từ máy chủ phụ trợ.
5. Thuộc tính useCount=7 trong thông báo lỗi ở trên cho biết rằng Trình xử lý thư đã sử dụng lại kết nối này khoảng bảy lần và thuộc tính bytesWritten=159 cho biết rằng Trình xử lý thư đã gửi yêu cầu tải trọng 159 byte đến máy chủ phụ trợ. Tuy nhiên, tài khoản này nhận được 0 byte khi EOF không mong muốn xảy ra.
6. Điều này cho thấy Trình xử lý thư đã sử dụng lại cùng một kết nối nhiều lần, và trong lần này, ứng dụng đã gửi dữ liệu nhưng ngay sau đó lại nhận được một EOF trước khi nhận được bất kỳ dữ liệu nào. Điều này có nghĩa là có nhiều khả năng chương trình phụ trợ thời gian chờ duy trì hoạt động của máy chủ ngắn hơn hoặc bằng thời gian chờ được đặt trong proxy API.
  
  Bạn có thể điều tra thêm với sự trợ giúp của tcpdump như giải thích bên dưới.

Sử dụng tcpdump

Ghi lại một tcpdump trên máy chủ phụ trợ bằng lệnh sau:
```
tcpdump -i any -s 0 host MP_IP_Address -w File_Name
```
Phân tích tcpdump đã thu thập:
Dưới đây là kết quả tcpdump mẫu:

Trong tcpdump mẫu ở trên, bạn có thể thấy những nội dung sau:
1. Trong gói 5992,, máy chủ phụ trợ đã nhận được một yêu cầu GET.
2. Trong gói 6064, gói này sẽ phản hồi bằng 200 OK.
3. Trong gói 6084, máy chủ phụ trợ đã nhận được một yêu cầu GET khác.
4. Trong gói 6154, gói này phản hồi bằng 200 OK.
5. Trong gói 6228, máy chủ phụ trợ đã nhận được yêu cầu GET thứ ba.
6. Lần này, máy chủ phụ trợ trả về một FIN, ACK cho Trình xử lý thư (gói 6285) bắt đầu đóng kết nối.
Cùng một kết nối đã được sử dụng lại thành công hai lần trong ví dụ này, nhưng ở yêu cầu thứ ba, máy chủ phụ trợ bắt đầu đóng kết nối, trong khi Trình xử lý thông báo đang chờ dữ liệu từ máy chủ phụ trợ. Điều này cho thấy rằng máy chủ phụ trợ luôn thời gian chờ tiếp tục có thể ngắn hơn hoặc bằng giá trị được thiết lập trong proxy API. Để xác thực Việc này, hãy xem bài viết So sánh thời gian chờ liên tục trên Apigee và máy chủ phụ trợ.

So sánh thời gian chờ duy trì hoạt động trên Apigee và máy chủ phụ trợ

Theo mặc định, Apigee sử dụng giá trị 60 giây cho thuộc tính thời gian chờ duy trì hoạt động.
Tuy nhiên, có thể bạn đã ghi đè giá trị mặc định trong Proxy API. Bạn có thể xác minh điều này bằng cách kiểm tra định nghĩa TargetEndpoint cụ thể trong không có Proxy API gây ra 502 lỗi.

Cấu hình TargetEndpoint mẫu:
```
<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <URL>https://mocktarget.apigee.net/json</URL>
    <Properties>
      <Property name="keepalive.timeout.millis">30000</Property>
    </Properties>
  </HTTPTargetConnection>
</TargetEndpoint>
```
Trong ví dụ trên, thuộc tính thời gian chờ giữ hoạt động bị ghi đè bằng giá trị 30 giây (30000 mili giây).
Tiếp theo, hãy kiểm tra thuộc tính duy trì thời gian chờ được định cấu hình trên máy chủ phụ trợ. Giả sử máy chủ phụ trợ của bạn được định cấu hình bằng giá trị 25 seconds.
Nếu bạn xác định được giá trị của thuộc tính thời gian chờ duy trì hoạt động trên Apigee là cao hơn so với giá trị của thuộc tính thời gian chờ duy trì hoạt động trên máy chủ phụ trợ như nêu trên ví dụ, thì đó là nguyên nhân gây ra lỗi 502.

Độ phân giải

Đảm bảo rằng thuộc tính thời gian chờ duy trì hoạt động luôn thấp hơn trên Apigee (trong Proxy API và Bộ xử lý thư) so với cấu hình trên máy chủ phụ trợ.

Xác định giá trị được thiết lập cho thời gian chờ duy trì hoạt động trên máy chủ phụ trợ.
Định cấu hình giá trị thích hợp cho thuộc tính thời gian chờ duy trì hoạt động trong Proxy API hoặc Trình xử lý thông báo, sao cho thuộc tính thời gian chờ duy trì hoạt động thấp hơn giá trị được đặt trên máy chủ phụ trợ bằng cách làm theo các bước được mô tả trong Định cấu hình duy trì thời gian chờ trên Bộ xử lý thư.

Nếu sự cố vẫn tiếp diễn, hãy chuyển đến Phải thu thập thông tin chẩn đoán.

Phương pháp hay nhất

Bạn nên đảm bảo các thành phần hạ nguồn luôn có thời gian chờ duy trì hoạt động ngắn hơn ngưỡng so với được định cấu hình trên các máy chủ lưu trữ ngược dòng (upstream) để tránh các loại tình huống tương tranh này và 502 lỗi. Mỗi bước đi xuống phải thấp hơn mỗi bước nhảy ngược. Trong Apigee Edge, bạn nên áp dụng các nguyên tắc sau:

Thời gian chờ duy trì hoạt động của ứng dụng phải nhỏ hơn thời gian chờ duy trì hoạt động của Bộ định tuyến cạnh.
Thời gian chờ duy trì hoạt động của Bộ định tuyến cạnh phải nhỏ hơn thời gian chờ duy trì hoạt động của Trình xử lý thông báo.
Thời gian chờ duy trì hoạt động của Trình xử lý thư phải nhỏ hơn thời gian chờ duy trì hoạt động của máy chủ mục tiêu.
Nếu bạn có bất kỳ bước nhảy nào khác ở phía trước hoặc phía sau Apigee, thì bạn nên áp dụng cùng quy tắc đó. Bạn phải luôn giao trách nhiệm cho khách hàng hạ nguồn trong việc đóng kết nối với luồng ngược.

Phải thu thập thông tin chẩn đoán

Nếu sự cố vẫn tiếp diễn ngay cả sau khi đã làm theo các hướng dẫn trên, hãy thu thập những thông tin sau thông tin chẩn đoán rồi liên hệ với Bộ phận hỗ trợ Apigee Edge.

Nếu bạn là người dùng Cloud Public, hãy cung cấp những thông tin sau:

Tên tổ chức
Tên môi trường
Tên proxy API
Hoàn tất lệnh curl để tái hiện lỗi 502
Tệp theo dõi chứa các yêu cầu có lỗi 502 Bad Gateway - Unexpected EOF
Nếu lỗi 502 hiện không xảy ra, hãy cung cấp khoảng thời gian thông tin múi giờ khi xảy ra 502 lỗi trong quá khứ.

Nếu bạn là người dùng Đám mây riêng tư, hãy cung cấp các thông tin sau:

Đã nhận thấy thông báo lỗi hoàn chỉnh đối với các yêu cầu không thực hiện được
Tổ chức, tên môi trường và tên proxy API mà bạn đang quan sát 502 lỗi
Gói Proxy API
Tệp theo dõi chứa các yêu cầu có lỗi 502 Bad Gateway - Unexpected EOF
Nhật ký truy cập NGINX
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
Nhật ký Trình xử lý thư
/opt/apigee/var/log/edge-message-processor/logs/system.log
Khoảng thời gian kèm theo thông tin múi giờ khi xảy ra lỗi 502
Tcpdumps được thu thập trên Bộ xử lý thư hay máy chủ phụ trợ hoặc cả hai khi xảy ra lỗi đã xảy ra