Understand DDoS protection

You inspect customer-visible HTTP protection settings and collect evidence about challenges or rejected requests.

Note: Balancer is in beta. Endpoints, fields and behavior may change before general availability, and the feature must be enabled on your account before use. Contact your NetActuate account manager to request access.

Prerequisites

• Balancer access and a key in the BALANCER_API_KEY environment variable with permission for these operations.
• The API host shown in the Balancer portal. Replace <your-api-host> in every example with that host.
• A shell, curl and Python 3 for examples that build JSON from environment variables.
• An HTTP group, a controlled test path and access to the client that experiences the issue.

Resource identifiers come from your API responses. Set each variable when its value is available, before the first step that uses it.

Environment variable	Value
GROUP_ID	Returned resource identifier, or your selected scope identifier.
HTTP_LB_ID	Returned resource identifier, or your selected scope identifier.

For an identifier, enter the value returned for your resource and export it:

read -r -p 'GROUP_ID: ' GROUP_ID
export GROUP_ID

Steps

1. Read the current HTTP protection settings.

   curl --silent --show-error --include \
     --request GET \
     --url "https://<your-api-host>/http-loadbalancers/$HTTP_LB_ID/groups/$GROUP_ID" \
     --header "x-api-key: $BALANCER_API_KEY"

   API reference: Get HTTP group

   Expected: HTTP 200. The following shows the response fields to check; additional data depends on your saved resources. Resource identifiers are illustrative.

   {
     "code": 200,
     "result": "success",
     "data": {
       "groupId": 1
     }
   }

2. For a controlled test, set the documented challenge aggressiveness field.

   curl --silent --show-error --include \
     --request PATCH \
     --url "https://<your-api-host>/http-loadbalancers/$HTTP_LB_ID/groups/$GROUP_ID" \
     --header "x-api-key: $BALANCER_API_KEY" \
     --header "Content-Type: application/json" \
     --data-binary '{"challengeAggressiveness":1}'

   API reference: Update an HTTP group configuration

   Expected: HTTP 200. The following shows the response fields to check; additional data depends on your saved resources. Resource identifiers are illustrative.

   {
     "code": 200,
     "result": "success",
     "data": {
       "groupId": 1
     }
   }

3. Read back the setting before testing.

   curl --silent --show-error --include \
     --request GET \
     --url "https://<your-api-host>/http-loadbalancers/$HTTP_LB_ID/groups/$GROUP_ID" \
     --header "x-api-key: $BALANCER_API_KEY"

   API reference: Get HTTP group

   Expected: HTTP 200. The following shows the response fields to check; additional data depends on your saved resources. Resource identifiers are illustrative.

   {
     "code": 200,
     "result": "success",
     "data": {
       "groupId": 1
     }
   }

Verify

Use a browser to observe whether the request presents a challenge and whether the client completes it. Compare the HTTP status and request identifier with a normal application request. Collect UTC time, status and challenge outcome before contacting support. Bots and other non-browser clients may not complete browser challenges.

Use your configured site domain in this traffic check:

curl --silent --show-error --include "https://example.com/"

Expected: the site behavior described above. The application response body and status depend on your origin and selected policies.

An API mutation saves desired configuration first. Readback and a live traffic check answer different questions. No fixed propagation time is established.

Customer-visible HTTP mechanisms include browser challenges, request budgets and bot-related signals. TODO(verify): Network filtering controls, attack thresholds, capacity guarantees and plan entitlements are not established by the available evidence. Do not infer them from an HTTP challenge response.

Troubleshooting

Symptom	Cause	Fix
A browser sees a challenge	HTTP protection changes the request flow	Record challenge outcome and check the effective group and route settings.
A source allow does not avoid the challenge	Under-attack handling can run before source allow evaluation	Ask support which mechanism generated the response.
Client reports 429	A request budget rejected it	Inspect rate-limit attribution.
Client reports 403	A source block may reject it	Check the selected source policy.
There is no HTTP response	DNS, TLS, packet delivery or origin failure may be involved	Test each layer and collect UTC time and request evidence.

Limits and defaults

Setting	Limit or default
Challenge aggressiveness	Group default 0; 0 to 5; 0 is off
Route challenge aggressiveness	Null or omission inherits the group setting
Propagation	No fixed end-to-end apply time is established

API status codes

Status	Meaning
200	Request succeeds; inspect returned data.
400	Invalid arguments or configuration.
401	Authentication or authorization denied.
404	Resource or parent is unavailable.
409	Resource state conflicts with the operation.
412	Inspect the returned error details.
500	The request encounters a server error.

Related API operations

• GET /http-loadbalancers/{httpLbId}/groups/{groupId}
• PATCH /http-loadbalancers/{httpLbId}/groups/{groupId}

API reference

• Get HTTP group

• Update an HTTP group configuration

• Groups and Routes

Need Help?

Contact your account manager or use the Balancer portal.