Google sử dụng công nghệ AI để dịch nội dung sang ngôn ngữ bạn ưu tiên. Bản dịch bằng AI có thể có lỗi.

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.
Truy cập vào tài liệu Apigee X. thông tin

Dấu hiệu

Ứng dụng khách 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 các 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ự phải thực hiện yêu cầu.

Thông báo lỗi

Ứng dụng khách nhận được mã phản hồi sau:

HTTP/1.1 502 Bad Gateway

Ngoài ra, bạn có thể 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 thường gặp gây ra lỗi 502 Bad Gateway Error là lỗi Unexpected EOF. Lỗi này có thể xảy ra do những lý do sau:

Nguyên nhân	Thông tin chi tiết	Số bước được tính cho
Định cấu hình máy chủ đích không chính xác	Máy chủ đích không được định cấu hình đúng cách để hỗ trợ các kết nối TLS/SSL.	Người dùng Edge Public Cloud và Private Cloud
EOFException từ Máy chủ phụ trợ	Máy chủ phụ trợ có thể đột ngột gửi EOF.	Chỉ dành cho người dùng Edge Private Cloud
Định cấu hình thời gian chờ duy trì hoạt động không chính xác	Thời gian chờ duy trì kết nối đượ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 Public Cloud và Private Cloud

Các bước chẩn đoán thường gặp

Để chẩn đoán lỗi, bạn có thể sử dụng một trong các phương thức 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 phần Điều tra 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 bạn chọn đúng khoảng thời gian khi xảy ra lỗi 502.
Nhấp vào ô trong ma trận khi bạn thấy số lượng lỗi 502 lớn.
Ở bên phải, hãy nhấp vào Xem nhật ký cho các lỗi 502. Các lỗi này sẽ có dạng như sau:

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

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

Điều này cho biết lỗi 502 là do đích đến gây ra do EOF không mong muốn.

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

Công cụ theo dõi

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

Bật phiên 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ực hiện được và 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 vị trí 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 phân tích được ghi lại) trong dấu vết.

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

Tiêu đề phản hồi	Giá trị
X-Apigee.fault-source	`target`
X-Apigee.fault-code	`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 gây ra mã 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 đề xảy ra không liên tục và bạn không thể ghi lại 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 mọi lỗi 502 cho một 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 cho mọi yêu cầu vẫn gặp lỗi 502.

Nếu có lỗi 502, hãy kiểm tra xem lỗi có phải do đích đến gửi Unexpected EOF hay không. Nếu các giá trị của X-Apigee.fault-source và X-Apigee.fault-code khớp với các giá trị xuất hiện trong bảng bên dưới, thì lỗi 502 là do đích đến bất ngờ đóng kết nối:

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

Dưới đây là một mục nhập mẫu cho thấy lỗi 502 do máy chủ đích gây ra:

Ngoài ra, hãy ghi lại mã thông báo cho các lỗi 502 để điều tra thêm.

Nguyên nhân: Máy chủ đích đượ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ợ các kết nối TLS/SSL.

Chẩn đoán

Sử dụng Tính nă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ã thông báo, mã lỗi và nguồn lỗi cho lỗi 502.
Bật dấu vết 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 cho thấy những thông tin sau:
1. Lỗi 502 Bad Gateway 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.
  Sau đó, rất có thể vấn đề này là do cấu hình máy chủ đích không chính xác.

Lấy định nghĩa máy chủ đích bằng lệnh gọi API quản lý Edge:

Nếu bạn là người dùng Đám mây công khai, 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 này:

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

Ví dụ về định nghĩa TargetServer bị lỗi:

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

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

Giả sử máy chủ đích mocktarget.apigee.net được định cấu hình để chấp nhận các kết nối bảo mật (HTTPS) trên cổng 443. Tuy nhiên, nếu bạn xem định nghĩa máy chủ đích, thì không có thuộc tính/cờ nào khác cho biết rằng máy chủ đó dành cho các kết nối an toàn. Điều này khiến Edge coi các yêu cầu API gửi đến máy chủ đích cụ thể là yêu cầu HTTP (không an toàn). Vì vậy, Edge sẽ không bắt đầu quy trình Bắt tay SSL với máy chủ đích 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ủ này sẽ từ chối yêu cầu từ Edge hoặc đóng kết nối. Do đó, bạn sẽ gặp lỗi UnexpectedEOFAtTarget trên Trình xử lý thông báo. Message Processor sẽ gửi 502 Bad Gateway làm phản hồi cho ứng dụng.

Độ phân giải

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

Đối với ví dụ minh hoạ ở trên, nếu muốn đưa ra yêu cầu cho một máy chủ đích an toàn (HTTPS/SSL), bạn cần thêm các thuộc tính SSLInfo với cờ enabled được đặt thành true. Mặc dù bạn được phép thêm các thuộc tính SSLInfo cho một máy chủ đích trong chính định nghĩa điểm cuối đích, nhưng bạn nên thêm các thuộc tính SSLInfo trong định nghĩa máy chủ đích để tránh 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 các thuộc tính SSLInfo trong đó 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ủ đích trong Edge, thì chúng ta cũng cần đưa truststore (chứa chứng chỉ của máy chủ đích) vào 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 phải có các thuộc tính SSLInfo với các cờ ClientAuthEnabled, Keystore, KeyAlias và Truststore được đặt một cách thích 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 (End of File) đột ngột.

Chẩn đoán

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

Tức là Message Processor đã gửi yêu cầu API đến máy chủ phụ trợ và đang chờ hoặc đọc phản hồi. Tuy nhiên, máy chủ phụ trợ đã đột ngột chấm dứt kết nối trước khi Message Processor nhận được phản hồi hoặc có thể đọc phản hồi hoàn chỉnh.
Kiểm tra nhật ký máy chủ phụ trợ và xem có lỗi hoặc thông tin nào có thể khiến máy chủ phụ trợ đột ngột chấm dứt kết nối hay không. Nếu bạn tìm thấy bất kỳ lỗi/thông tin nào, hãy chuyển đến phần Giải pháp và khắc phục vấn đề một cách thích hợp trong máy chủ phụ trợ của bạn.
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 đầu ra 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 Trình xử lý tin nhắn, hãy 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ý tin nhắn 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 Message Processor gửi yêu cầu đến máy chủ phụ trợ.
Hãy xem xét ví dụ về tcpdump sau đây.

Mẫu tcpdump được lấy khi 502 Bad Gateway Error (UnexpectedEOFAtTarget) xảy ra
Trong kết quả TCPDump, bạn nhận thấy chuỗi sự kiện sau:
1. Trong gói 985, Message Processor sẽ gửi yêu cầu API đến máy chủ phụ trợ.
2. Trong gói 986, máy chủ phụ trợ sẽ phản hồi ngay bằng [FIN,ACK].
3. Trong gói 987, Trình xử lý thông báo sẽ phản hồi bằng [FIN,ACK] cho máy chủ phụ trợ.
4. Cuối cùng, các kết nối sẽ đóng lại bằng [ACK] và [RST] từ 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ên Trình xử lý thông báo.
Điều này có thể xảy ra nếu có sự cố mạng ở máy chủ phụ trợ. Hãy liên hệ với nhóm vận hành mạng của bạn để đ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 vấn đề vẫn tiếp diễn và bạn cần được hỗ trợ khắc phục sự cố 502 Bad Gateway Error hoặc bạn nghi ngờ đó là vấn đề trong Edge, hãy liên hệ với Nhóm hỗ trợ Apigee Edge.

Nguyên nhân: Đã định cấu hình thời gian chờ duy trì hoạt động không chính xác

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

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

Theo mặc định (và theo tiêu chuẩn HTTP/1.1), Apigee 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. Các kết nối liên tục có thể tăng hiệu suất bằng cách cho phép sử dụng lại kết nối TCP và (nếu có) TLS/SSL đã được thiết lập, giúp giảm độ trễ. Thời lượng cần duy trì kết nối được kiểm soát thông qua một thuộc tính thời gian chờ duy trì 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 để giữ các kết nối mở với nhau. Khi không nhận được dữ liệu nào trong khoảng thời gian chờ duy trì kết nối, máy chủ phụ trợ hoặc Trình xử lý thông báo có thể đóng kết nối với bên kia.

Theo mặc định, các API Proxy được triển khai cho một Message Processor trong Apigee sẽ có thời gian chờ duy trì kết nối được đặt thành 60s, trừ phi bị ghi đè. Khi không nhận được dữ liệu cho 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ờ duy trì hoạt động và khi hết thời gian này, máy chủ phụ trợ sẽ đóng kết nối với Trình xử lý thông báo.

Hậu quả của việc định 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ì điều này sẽ dẫn đến tình huống tương tranh khiến máy chủ phụ trợ gửi một End Of File (FIN) không mong muốn để phản hồi yêu cầu về một tài nguyên.

Ví dụ: nếu thời gian chờ duy trì hoạt động được định cấu hình trong API Proxy hoặc Message Processor với giá trị lớn hơn hoặc bằng thời gian chờ của máy chủ phụ trợ ở thượng nguồ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ông báo không nhận được dữ liệu nào cho đến khi gần đến ngưỡng thời gian chờ duy trì hoạt động của máy chủ phụ trợ, thì một yêu cầu sẽ được gửi đến máy chủ phụ trợ bằng cách sử dụng kết nối hiện có. Điều này có thể dẫn đến 502 Bad Gateway do lỗi EOF không mong muốn như giải thích dưới đây:

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

Trong trường hợp này, chúng tôi nhận thấy lỗi 502 xảy ra vì cùng một giá trị thời gian chờ duy trì kết nối là 60 giây được định cấu hình trên cả Trình xử lý thông báo và máy chủ phụ trợ. Tương tự, vấn đề này cũng có thể xảy ra nếu bạn định cấu hình giá trị cao hơn cho thời gian chờ duy trì hoạt động trên Trình xử lý thông báo so với trên máy chủ phụ trợ.

Chẩn đoán

Nếu bạn là người dùng Đám mây công khai:
1. Sử dụng công cụ Giám sát API hoặc công cụ Theo dõi (như được giải thích trong phần Các bước chẩn đoán thường gặp) và xác minh rằng bạn có cả hai chế độ cài đặt sau:
  - Mã lỗi: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
  - Nguồn lỗi: target
2. Hãy xem phần Sử dụng tcpdump để điều tra thêm.
Nếu bạn là người dùng Đám mây riêng:
1. Sử dụng Công cụ theo dõi hoặc Nhật ký truy cập NGINX để xác định mã thông báo, mã lỗi và nguồn lỗi cho lỗi 502.
2. Tì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ư minh hoạ bên dưới:
```
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 Trình xử lý thông báo đã nhận được EOF trong khi vẫn đang chờ đọc 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 Trình xử lý thông báo đã sử dụng lại kết nối này khoảng 7 lần và thuộc tính bytesWritten=159 cho biết Trình xử lý thông báo đã gửi tải trọng yêu cầu có 159 byte đến máy chủ phụ trợ. Tuy nhiên, nó đã nhận được 0 byte khi EOF không mong muốn xảy ra.
6. Điều này cho thấy Message Processor đã sử dụng lại cùng một kết nối nhiều lần và trong trường hợp này, nó đã gửi dữ liệu nhưng ngay sau đó 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ó khả năng cao là thời gian chờ duy trì hoạt động của máy chủ phụ trợ sẽ 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 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 đã ghi lại:
Sau đây là ví dụ về đầu ra của tcpdump:

Trong mẫu tcpdump ở trên, bạn có thể thấy những thông tin sau:
1. Trong gói 5992,, máy chủ phụ trợ đã nhận được yêu cầu GET.
2. Trong gói 6064, nó 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, thiết bị sẽ 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 thứ ba GET.
6. Lần này, máy chủ phụ trợ trả về một FIN, ACK cho Trình xử lý thông báo (gói 6285) để bắt đầu đóng kết nối.
Trong ví dụ này, cùng một kết nối đã được sử dụng lại thành công hai lần, 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 thời gian chờ duy trì kết nối của máy chủ phụ trợ có khả năng ngắn hơn hoặc bằng giá trị được đặt trong proxy API. Để xác thực điều này, hãy xem phần So sánh thời gian chờ duy trì hoạt động trên Apigee và máy chủ phụ trợ.

So sánh thời gian chờ duy trì kết nối 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ì kết nối.
Tuy nhiên, có thể bạn đã ghi đè giá trị mặc định trong API Proxy. 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 Proxy API không thành công đang gây ra lỗi 502.

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ờ duy trì kết nối được ghi đè bằng giá trị 30 giây (30000 mili giây).
Tiếp theo, hãy kiểm tra thuộc tính thời gian chờ duy trì hoạt động đượ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 với giá trị 25 seconds.
Nếu bạn xác định rằng giá trị của thuộc tính thời gian chờ duy trì kết nối trên Apigee cao hơn giá trị của thuộc tính thời gian chờ duy trì kết nối trên máy chủ phụ trợ như trong ví dụ trên, 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 thành phần API Proxy và Message Processor) so với trên máy chủ phụ trợ.

Xác định giá trị được đặt cho thời gian chờ duy trì hoạt động trên máy chủ phụ trợ.
Định cấu hình một giá trị thích hợp cho thuộc tính thời gian chờ duy trì kết nối trong API Proxy hoặc Message Processor, sao cho thuộc tính thời gian chờ duy trì kết nối thấp hơn giá trị được đặt trên máy chủ phụ trợ, bằng cách sử dụng các bước được mô tả trong phần Định cấu hình thời gian chờ duy trì kết nối trên Message Processor.

Nếu vấn đề vẫn tiếp diễn, hãy chuyển đến phần Phải thu thập thông tin chẩn đoán.

Phương pháp hay nhất

Bạn nên đặt ngưỡng thời gian chờ duy trì kết nối của các thành phần hạ lưu luôn thấp hơn ngưỡng được định cấu hình trên các máy chủ thượng nguồn để tránh những loại điều kiện xung đột và lỗi 502 này. Mỗi bước nhảy xuôi dòng phải thấp hơn mỗi bước nhảy ngược dòng. 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 máy khách phải nhỏ hơn thời gian chờ duy trì hoạt động của Bộ định tuyến biên.
Thời gian chờ duy trì hoạt động của Bộ định tuyến biên 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ông báo phải nhỏ hơn thời gian chờ duy trì hoạt động của máy chủ đích.
Nếu bạn có bất kỳ bước nhảy nào khác trước hoặc sau Apigee, bạn nên áp dụng cùng một quy tắc. Bạn luôn phải để cho ứng dụng khách hạ lưu chịu trách nhiệm đóng kết nối với thượng lưu.

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

Nếu vấn đề vẫn tiếp diễn ngay cả sau khi bạn làm theo hướng dẫn ở trên, hãy thu thập thông tin chẩn đoán sau đây rồi liên hệ với Nhóm hỗ trợ Apigee Edge.

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

Tên tổ chức
Tên môi trường
Tên API Proxy
Hoàn tất lệnh curl để tái tạo 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 hiện tại không xảy ra lỗi 502, hãy cung cấp khoảng thời gian kèm theo thông tin về múi giờ khi lỗi 502 xảy ra trong quá khứ.

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

Thông báo lỗi hoàn chỉnh được ghi nhận cho các yêu cầu không thành công
Tổ chức, tên Môi trường và tên Proxy API mà bạn đang quan sát thấy lỗi 502
Gói API Proxy
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ý Bộ xử lý tin nhắn
/opt/apigee/var/log/edge-message-processor/logs/system.log
Khoảng thời gian có thông tin về múi giờ khi xảy ra lỗi 502
Tcpdumps được thu thập trên Bộ xử lý thông báo hoặc máy chủ phụ trợ, hoặc cả hai khi xảy ra lỗi