请选择
Edge Acceleration
  • Site Acceleration
    • Overview
    • Access Control
      • Token Authentication
    • File Optimization
      • Smart Compression
    • Network Optimization
      • HTTP/2
      • HTTP/3(QUIC)
        • Overview
        • Enable HTTP/3
        • QUIC SDK
          • SDK Overview
          • SDK Download and Integration
          • Sample Code
            • Android
            • iOS
          • API Documentation
            • Android
            • iOS
      • IPv6 Access
      • Maximum Upload Size
      • WebSocket
      • Client IP Geolocation Header
      • Client IP Geographical Location
      • gRPC
    • URL Rewrite
      • Access URL Redirection
      • Origin-Pull URL Rewrite
    • Modifying Header
      • Modifying HTTP Response Headers
      • Modifying HTTP Request Headers
    • Custom Error Page
    • Request and Response Actions
      • Processing order
      • Default HTTP Headers of Origin-Pull Requests
      • Default HTTP Response Headers
  • Smart Acceleration
  • L4 Proxy
    • Overview
    • Creating an L4 Proxy Instance
    • Modifying an L4 Proxy Instance
    • Disabling or Deleting an L4 Proxy Instance
    • Batch Configuring Forwarding Rules
    • Obtaining Real Client IPs
      • Obtaining Real TCP Client IPs via TOA
      • Obtaining Real Client IPs Through Protocol V1/V2
        • Overview
        • Method 1: Obtaining Real Client IPs Through Nginx
        • Method 2: Parsing Real Client IPs on Application Server
        • Format of Real Client IPs Obtained Through Proxy Protocol V1/V2
      • Transmitting Client Real IP via SPP Protocol
  • Edge DNS
    • Hosting DNS Records
      • Modifying DNS Servers
      • Configuring DNS Records
      • Advanced DNS Configuration
    • Domain Connection
      • Adding A Domain Name for Acceleration
      • Ownership Verification
      • Modifying CNAME Records
    • Domain alias
      • Overview
      • Configuration Guide
      • Batch Connecting SaaS Domain Names
      • Configuring Alias Domain Names for Disaster Recovery
    • Traffic Scheduling
      • Traffic Scheduling Management
    • Origin Configuration
      • Load Balancing
        • Overview
        • Quickly Create Load Balancers
        • Health Check Policies
        • Viewing the Health Status of Origin Server
        • Related References
          • Load Balancing-Related Concepts
          • Introduction to Request Retry Strategy
      • Origin Group Configuration
      • Origin-pull configuration
        • Configuring Origin-Pull HTTPS
        • Host Header Rewrite
        • Controlling Origin-pull Requests
        • Redirect Following During Origin-Pull
        • HTTP/2 Origin-Pull
        • Range GETs
      • Related References
        • ld Version Origin Group Compatible Related Issues
        • VOD Origin Server Details
      • Collect EdgeOne origin-pull node IP
  • Edge Cache
    • Overview
    • EdgeOne Cache Rules
      • Content Cache Rules
      • Cache Key Introduction
      • Vary Feature
    • Cache Configuration
      • Custom Cache Key
      • Node Cache TTL
      • Status Code Cache TTL
      • Browser Cache TTL
      • Offline Caching
      • Cache Prefresh
    • Clear and Preheat Cach
      • Cache Purge
      • URL Pre-Warming
    • How to improve the Cache Hit Rate of EdgeOne
  • Rules Engine
    • Overview
    • Supported Matching Types and Actions
    • Rule Management
    • variables
  • Image Processing

Health Check Policies

This document introduces the probe methods and their principles within health checks, the origin health determination criteria and the calculation methods.
Note:
EdgeOne Load Balancing feature is in beta testing. If you want to use it, you can Contact Us.

Principle of Health Checks

After configuring health check policies, EdgeOne's probe nodes in different regions will send probe requests to your origin and determine the health status of the origin based on the response results. Health check policies consist of probe methods and origin health determination criteria. The probe method determines the type of probe request, while the origin health determination criteria determine how the response results are processed.


Probe Method

Currently, supports for ICMP Ping, HTTP/HTTPS, TCP, and UDP as the four methods of probe. For more details, see The Principle Introduction of Probe Methods. The following are the explanations for the corresponding configuration items:
Probe Method
Applicable Scenario
Configuration Item
Description
ICMP Ping
Only probes network connectivity, and host reachability.
Probe Frequency
Required, with optional intervals of every 30 seconds, every 60 seconds, every 3 minutes, every 5 minutes, or every 10 minutes.
HTTP/HTTPS
Applicable for applications that require content recognition in requests, such as web applications and app services.
Probe Frequency
Required, with optional intervals of every 30 seconds, every 60 seconds, every 3 minutes, every 5 minutes, or every 10 minutes.
URL
Required, the full URL for health checks, for example: www.example.com/test.
Probe Port
Required, defaulting to port 80. It is recommended not to modify this unless a specific port needs to be designated.
HTTP Method
Required, the HTTP method for health checks is by default HEAD, with options including GET or HEAD.
If the HEAD method is used, the server returns only HTTP header information, which can reduce backend overhead and enhance request efficiency. The corresponding origin service must support HEAD.
If the GET method is used, the origin service simply needs to support GET.
HTTP Status Code
Required, the origin is considered healthy when the status code matches the selected status codes. By default, this includes 2XX, with options to select: 1XX, 2XX, 3XX, 4XX, 5XX.
Follow Redirects
Disabled by default. When enabled, the probe node will initiate another probe based on the 301/302 redirect address responded by the origin. It Uses the status code of the final redirection response as the determination result for the health status. Up to 3 redirects are supported.
Custom Request Headers
Optional, custom request headers can be configured to be sent with the health check requests to the origin, with a maximum of 8 configurations allowed, for example: host: www.example.com.
TCP
Suitable for scenarios where high reliability and data accuracy are essential, but transmission speed is of lesser importance, such as file transfers and remote log-ins.
Probe Frequency
Required, with optional intervals of every 30 seconds, every 60 seconds, every 3 minutes, every 5 minutes, or every 10 minutes.
Probe Port
Required, defaulting to port 80. It is recommended not to modify this unless a specific port needs to be designated.
UDP
Suitable for scenarios where high transmission efficiency is crucial and a relatively lower level of accuracy is acceptable, such as instant messaging and online video streaming.
Probe Frequency
Required, with optional intervals of every 30 seconds, every 60 seconds, every 3 minutes, every 5 minutes, or every 10 minutes.
Probe Port
Required, defaulting to port 80. It is recommended not to modify this unless a specific port needs to be designated.
Probe Request
Required, customize the content of the health check request, with a limit of 500 characters.
Probe Response Result
Required, customize the content of the health check request, with a limit of 500 characters.

Origin Health Determination Criteria

Choose any of the probe policies: ICMP Ping, HTTP/HTTPS, TCP, and UDP. Click Show Advanced Configuration to configure origin health determination criteria. The following are the descriptions for each configuration item:

Configuration Item
Description
Timeout
The allowed timeout duration for a single health check request to the origin. If no response is received within this period, the origin is considered Unhealthy. The default is 5 seconds, with a configurable range of [1, 30] seconds.
Unhealthy Threshold
The number of consecutive probe failures required to determine an origin Unhealthy. Once this threshold is reached, the origin is considered Unhealthy. The default is 2 times, with a configurable range of [1, 5]. For example, if this value is set to 2, and an origin is initially Healthy, upon receiving two consecutive Unhealthy probe results, the origin will be considered Unhealthy.
Healthy Threshold
The number of consecutive successful probes required to restore an origin to a Healthy state, making it available again. The default is 3 times, with a configurable range of [1, 5]. For example, if this value is set to 3, and an origin is Unhealthy, after three consecutive Healthy probe results, the origin will be restored to a Healthy status.

More Information

Introduction to Principle of Probe Method

ICMP Ping
HTTP/HTTPS
TCP
UDP

The ICMP Ping health check mechanism is as follows:
1. EdgeOne probe node sends a Ping command to your origin.
2. If the Ping is successful, and within the backsource timeout period, the origin receives an ICMP reply, the service is considered normal, and the result of this check is considered healthy.
3. If the Ping fails, and within the backsource timeout period, the probe node does not receive an ICMP reply from the origin, the service is considered abnormal, and the result of this check is considered unhealthy.
Note:
ICMP Ping requires your origin to support Ping.

The HTTP/HTTPS health check mechanism is as follows:
1. EdgeOne probe node sends an HTTP request to your origin. It requires configuration of the corresponding URL and port, with the option to include a custom HOST header.
2. If, within the backsource timeout period, the EO probe node receives an HTTP status code from the origin that successfully matches the configured HTTP status codes, the result of this check is considered healthy.
3. If, within the backsource timeout period, the EO probe node does not receive a response from the origin or receives a status code that does not match the configured codes, the result of this check is considered unhealthy.

The TCP health check mechanism is as follows:
1. EdgeOne probe node sends a SYN connection request packet to a specific port (configurable) on your origin.
2. Upon receiving the SYN request packet, if the corresponding port on the origin is in a normal listening state, it will respond with a SYN+ACK packet.
3. If, within the backsource timeout period, the probe node receives a SYN+ACK response packet from the origin, it indicates that the service is running normally. The result of this check is considered healthy. The probe node then replies with an ACK packet to the origin and sends an RST reset packet to terminate the TCP connection.
4. If, within the backsource timeout period, the probe node does not receive a SYN+ACK response packet from the origin, it indicates that the service is running abnormally. The result of this check is considered unhealthy. The probe node sends an RST reset packet to the origin to terminate the TCP connection.

The UDP health check mechanism is as follows:
1. EdgeOne probe node sends a customized probe packet to a specific port (configurable) on your origin.
2. If, within the backsource timeout period, the probe node receives a customized response packet from the origin, it indicates that the service is running normally. The result of this check is considered healthy.
3. If, within the backsource timeout period, the probe node does not receive a customized response packet from the origin or receives a response packet that does not conform to the defined content, it indicates that the service is running abnormally. The result of this check is considered unhealthy.
Note:
Both the request content and response content are customized, and you need to configure the corresponding request-response content on your origin.

Probe Request Identification

Active probes do not carry special request identifiers. When you choose ICMP Ping or TCP probes, there are no related features. When you choose UDP probes, customized content can be configured to serve as identifiers. For HTTP/HTTPS probes, separate customized request headers can be configured to serve as identifiers.