- Release Notes and Announcements
- Product Introduction
- Comparison of Anti-DDoS Solutions
- Purchase Guide
- Getting Started
- Operation Guide
- Practical Tutorial
- Remote Protection Scheme with Anti-DDoS Pro
- Using Anti-DDoS Pro Together with WFA
- Suggestions on Stress Tests
- Solutions to Real Server IP Exposure
- Creating an Anti-DDoS EIP
- Configuration Directions and Notes on CC Protection Policies
- Syncing Forwarding Rules to New Anti-DDoS Advanced Instances
- Smart Scheduling of CTCC/CUCC/CMCC Traffic
- Troubleshooting
- API Documentation
- History
- Introduction
- API Category
- Making API Requests
- Anti-DDoS Advanced Instance APIs
- Resource List APIs
- Protection Configuration APIs
- CreateBlackWhiteIpList
- CreateCcBlackWhiteIpList
- CreateCcGeoIPBlockConfig
- CreateDDoSAI
- CreateDDoSGeoIPBlockConfig
- CreateDDoSSpeedLimitConfig
- CreatePacketFilterConfig
- CreateProtocolBlockConfig
- CreateWaterPrintConfig
- CreateWaterPrintKey
- DeleteCcBlackWhiteIpList
- DeleteCcGeoIPBlockConfig
- DeleteDDoSGeoIPBlockConfig
- DeleteDDoSSpeedLimitConfig
- DeletePacketFilterConfig
- DeleteWaterPrintConfig
- DeleteWaterPrintKey
- DescribeCcBlackWhiteIpList
- DescribeCcGeoIPBlockConfigList
- DescribeListBlackWhiteIpList
- DescribeListDDoSAI
- DescribeListDDoSGeoIPBlockConfig
- DescribeListDDoSSpeedLimitConfig
- DescribeListPacketFilterConfig
- DescribeListProtocolBlockConfig
- DescribeListWaterPrintConfig
- ModifyCcBlackWhiteIpList
- ModifyDDoSGeoIPBlockConfig
- ModifyDDoSSpeedLimitConfig
- ModifyPacketFilterConfig
- SwitchWaterPrintConfig
- Other APIs
- Alarm Notification APIs
- Connection Configuration APIs
- Intelligent Scheduling APIs
- Black hole unblocking APIs
- Statistical Report APIs
- Data Types
- Error Codes
- FAQs
- Service Level Agreement
- Product Policy
- Glossary
- Release Notes and Announcements
- Product Introduction
- Comparison of Anti-DDoS Solutions
- Purchase Guide
- Getting Started
- Operation Guide
- Practical Tutorial
- Remote Protection Scheme with Anti-DDoS Pro
- Using Anti-DDoS Pro Together with WFA
- Suggestions on Stress Tests
- Solutions to Real Server IP Exposure
- Creating an Anti-DDoS EIP
- Configuration Directions and Notes on CC Protection Policies
- Syncing Forwarding Rules to New Anti-DDoS Advanced Instances
- Smart Scheduling of CTCC/CUCC/CMCC Traffic
- Troubleshooting
- API Documentation
- History
- Introduction
- API Category
- Making API Requests
- Anti-DDoS Advanced Instance APIs
- Resource List APIs
- Protection Configuration APIs
- CreateBlackWhiteIpList
- CreateCcBlackWhiteIpList
- CreateCcGeoIPBlockConfig
- CreateDDoSAI
- CreateDDoSGeoIPBlockConfig
- CreateDDoSSpeedLimitConfig
- CreatePacketFilterConfig
- CreateProtocolBlockConfig
- CreateWaterPrintConfig
- CreateWaterPrintKey
- DeleteCcBlackWhiteIpList
- DeleteCcGeoIPBlockConfig
- DeleteDDoSGeoIPBlockConfig
- DeleteDDoSSpeedLimitConfig
- DeletePacketFilterConfig
- DeleteWaterPrintConfig
- DeleteWaterPrintKey
- DescribeCcBlackWhiteIpList
- DescribeCcGeoIPBlockConfigList
- DescribeListBlackWhiteIpList
- DescribeListDDoSAI
- DescribeListDDoSGeoIPBlockConfig
- DescribeListDDoSSpeedLimitConfig
- DescribeListPacketFilterConfig
- DescribeListProtocolBlockConfig
- DescribeListWaterPrintConfig
- ModifyCcBlackWhiteIpList
- ModifyDDoSGeoIPBlockConfig
- ModifyDDoSSpeedLimitConfig
- ModifyPacketFilterConfig
- SwitchWaterPrintConfig
- Other APIs
- Alarm Notification APIs
- Connection Configuration APIs
- Intelligent Scheduling APIs
- Black hole unblocking APIs
- Statistical Report APIs
- Data Types
- Error Codes
- FAQs
- Service Level Agreement
- Product Policy
- Glossary
Use cases
Anti-DDoS Advanced health checks identify the running status of backend servers, where abnormal servers will be isolated to reduce the impact on overall business availability.
Layer-4 health check
The Anti-DDoS Advanced layer-4 health check mechanism is as follows: The Anti-DDoS cluster nodes initiate an access request to the server port specified. If the port can be accessed normally, the backend server is running properly; otherwise, the backend server is not running normally.
Under TCP protocol, the mechanism checks if the port can be connected, while under UDP protocol, it determines whether the port is reachable with the
ping command.Layer-7 health check
The Anti-DDoS Advanced layer-7 health check mechanism is as follows: The Anti-DDoS cluster nodes initiate an HTTP request to the backend server and determine whether the backend server works properly according to the HTTP response status code.
HTTP response status codes can be user-defined. Assume that HTTP response status codes include http_1xx, http_2xx, http_3xx, http_4xx, and http_5xx. You can select http_1xx and http_2xx to indicate that the service is normal, then the unselected codes http_3xx, http_4xx, and http_5xx represent that the service is not working properly.
Note:
If only one real server IP is configured in a single forwarding rule, the health check feature cannot be enabled. This feature is used when multiple real server IPs are configured.
Directions
Layer-4 health check configuration
1. Log in to the new Anti-DDoS console, click Business Access on the left sidebar, and then click the Access via port tab.
2. On the Access via port tab, select an Anti-DDoS Advanced instance and rules and then click Edit in the Health check column.
3. On the Edit Health Check dialog box, click Display advanced options, configure the required fields, and then click OK.
Note:
By default, layer-4 health check is enabled. We recommend you use the default values when you configure this feature.
Under TCP protocol, the mechanism checks if the port can be connected, while under UDP protocol, it determines whether the port is reachable with the
ping command.
Layer-7 health check configuration
1. Log in to the new Anti-DDoS console, click Business Access on the left sidebar, and then click the Access via domain name tab.
2. On the Access via domain name tab, select an Anti-DDoS Advanced instance and rules and then click Configure in the Health check column.
3. On the Edit Health Check dialog box, click Display advanced options, configure the required fields, and then click OK.
Note:
By default, layer-7 health check is disabled.
Configuration item description
Layer-4 health check
Configuration item | Description |
Response timeout | Maximum response timeout for a health check. If the backend server does not respond properly within the specified time, the health check will be considered as failed. |
Check interval | Interval between two health checks |
Unhealthy threshold | When the health check status is "succeeded", but the health check status "failed** is received for n times (n is the entered number) in a row, the backend server will be considered unhealthy, and "abnormal" will be displayed in the console. |
Healthy threshold | When the health check status is "failed", but the health check status "succeeded" is received for n times (n is the entered number) in a row, the backend server will be considered healthy, and nothing will be displayed in the console. |
Layer-7 health check
Configuration item | Description |
Check interval | Interval between two health checks. Default: 15 seconds. |
Unhealthy threshold | When the health check status is "succeeded", but the health check status "failed** is received for n times (n is the entered number) in a row, the backend server will be considered unhealthy, and "abnormal" will be displayed in the console. |
Healthy threshold | When the health check status is "failed", but the health check status "succeeded" is received for n times (n is the entered number) in a row, the backend server will be considered healthy, and nothing will be displayed in the console. |
HTTP request method and check path URL | The HEAD method is used by default, and the server returns only the header of the response packet. If the GET method is used, the server returns the complete response packet. The corresponding backend server needs to support HEAD and GET. If the page used for health check is not the default homepage of the application server, you need to specify a specific check path. If the host field parameter is specified in the HTTP HEAD request, you need to specify the check path, that is, the URI of the page file used for the health check. |
HTTP status code detection | It determines whether the HTTP status code is healthy. By default, http_1xx, http_2xx, http_3xx, and http_4xx are selected. If you use the default settings and the returned HTTP status code is not the default value, the server will be considered unhealthy. You can modify the settings for this configuration item. |
Yes
No
Was this page helpful?