导航|地址|刷新
Load shedding

Skip to contentDocumentation Index
Fetch the complete documentation index at: https://developers.cloudflare.com/load-balancing/llms.txt
Use this file to discover all available pages before exploring further.

Docs Directory API SDKs Changelog

Search

Log in

Load Balancing

/

Overview

Get started

Overview

Enable

Quickstart

Learning path ↗

Concepts

Load Balancing components

Traffic steering

Overview

Global traffic steering

Overview

Standard

Geo

Dynamic

Proximity

Least Outstanding Requests

Local traffic steering

Overview

Random

Hash

Least Outstanding Requests

How endpoints and pools become unhealthy

Proxy status

Session affinity

Adaptive routing

Load balancers

Overview

Manage load balancers

DNS records

Common configurations

Pools

Overview

Manage pools

Use Pages as an origin for Load Balancing

Monitors

Overview

Manage monitors

Monitor Groups

Private Network Load Balancing

Overview

Set up Private Network Load Balancing for Public traffic to Tunnel

Set up Private Network Load Balancing with Cloudflare WAN

Set up Private Network Load Balancing with Client-to-Tunnel

Additional configuration

Overview

Cloudflare Tunnel (published applications)

Spectrum

Perform planned maintenance

Load shedding

DNS persistence

Load Balancing with the China Network

Override HTTP Host headers

CNAME flattening for endpoints

Custom load balancing rules

Overview

Create custom rules

Expressions

Actions

Supported fields and operators

Integrate with PagerDuty

Additional DNS records

Reference

Migration guides

Migrate to new GraphQL nodes

Health monitor notifications

Analytics

Regions API

Limitations

Reference architecture ↗

Troubleshooting

Common error codes

FAQs

API reference ↗API

Changelog

Agent resources

Agent setup ↗

Cloudflare Skills ↗

Code Mode MCP Server ↗

Domain-specific MCP Servers ↗MCP

Load Balancing llms.txt ↗

Load Balancing llms-full.txt ↗

Cloudflare Docs llms.txt ↗

Cloudflare Docs llms-full.txt ↗

Home

/Load Balancing

/Additional configuration

/Load shedding

Load shedding

Last updated May 5, 2026|Copy as Markdown|View as Markdown|Agent setup

OverviewStep 1 — Identify at-risk endpointsStep 2 — Shed default traffic from a pool Configure via dashboard Configure via APIStep 3 — Monitor trafficStep 4 — Shed additional traffic (optional)Step 5 — Disable load sheddingAdditional notes Shedding policies Fallback pools Pools in multiple load balancers

Use load shedding to prevent an at-risk endpoint from becoming unhealthy and starting the failover process.

Once you configure load shedding on a pool, that pool will begin diverting traffic to other pools according to your load shedding settings and the load balancer's steering policy.

Step 1 — Identify at-risk endpoints

Using your internal metrics, identify endpoints at risk of reaching their failure threshold.

If your endpoint is seeing increased traffic but is not yet at risk of failure, start with Step 2.

If your endpoint is about to fail, start with Step 4.

Step 2 — Shed default traffic from a pool

Once you have identified an at-risk endpoint, shed a small amount of Default traffic from that endpoint's pool. This traffic is not affiliated with existing Session affinity sessions.

Configure load shedding via the dashboard or the API.

Configure via dashboard

To enable load shedding for a specific pool via the dashboard:

Go to Load Balancing.

Select the Pools tab.

On a pool, select Edit.

Open the Configure Load Shedding dropdown.

For Default traffic, select a Policy and a Shed %:

Policy options

When shedding Default traffic, you have two Policy options:

Random: Randomly sheds the percentage of requests specified in the Shed %. Distributes traffic more accurately, but may cause requests from the same IP to hit different endpoints.

IP hash: Sheds the percentage of IP address hash space specified in the Shed %. Ensures requests from the same IP will hit the same endpoint, but may shed a significantly higher or lower percentage of requests.

For more guidance on choosing a policy, refer to Shedding policies.

Shed %

When choosing a Shed %, start with a small percentage and increase gradually. Particularly if you choose the IP hash shedding policy, you might shed more traffic than expected.

Configure via API

To enable load shedding for a specific pool via the API, update the values for the pool's load_shedding object.

Example request
Requestbashcurl --request PATCH \"https://api.cloudflare.com/client/v4/accounts/{account_id}/load_balancers/pools/{pool_id}" \--header "Authorization: Bearer <API_TOKEN>" \--header "Content-Type: application/json" \--data-binary '{ "load_shedding": { "default_percent": 20, "default_policy": "random", "session_percent": 0, "session_policy": "hash" }}'
For more guidance on choosing a shedding policy, see Shedding policies.

Step 3 — Monitor traffic

Once you have started shedding default traffic, evaluate the effects by reviewing the Overview metrics in Load Balancing analytics. Based on these numbers and your internal metrics, you will know whether you need to divert additional traffic from the pool.

If you see increased traffic to a pool, you may need to shed additional traffic. Pools shed a percentage of total traffic, so any increase in total traffic will also increase the traffic reaching your pool.

Step 4 — Shed additional traffic (optional)

If you need to shed additional pool traffic:

Follow the steps outlined in Step 2.
In the dashboard, increase the Shed % for Default traffic and/or Session affinity traffic.

For the API, increase the value for default_percent and/or session_percent.

Since shedding Session Affinity traffic will disrupt existing sessions and may degrade the customer experience, only enable this option if your pool is in imminent danger of becoming unhealthy or your pool has a high percentage of traffic related to existing sessions. For more guidance, see Shedding policies.

Step 5 — Disable load shedding

Once an endpoint is no longer at risk, remove load shedding from the pool.

To remove load shedding in the dashboard, perform the same steps as Configure load shedding via the dashboard but set the Shed % to 0 for both Default traffic and Session affinity traffic.

To remove load shedding via the API, perform the same steps as Configure load shedding via the API but set the load_shedding object to null.

Additional notes

Shedding policies

For Default traffic, you have two choices for shedding policy.

A Random policy:

Randomly sheds the percentage of requests specified in the Shed %.

Distributes traffic more accurately because it sheds at the request level.

May cause requests from the same IP to hit different endpoints, potentially leading to cache misses, inconsistent latency, or session disruption for DNS-only load balancers.

An IP hash policy:

Sheds the percentage of IP address hash space specified in the Shed %.

Ensures requests from the same IP will hit the same endpoint, which will increase cache hits, provide consistent latency, and preserve sessions.

Can over- or under-shed requests, since hashing does not guarantee a perfectly even IP distribution and individual IPs may be responsible for different percentages of your requests.

Choose a Random policy when you want a more accurate distribution of raw requests and an IP hash policy when you want to prevent a single IP from flapping between different endpoints.

For Session Affinity traffic, you can only use an IP hash policy since these requests relate to existing sessions. Only increase the Shed % if you are comfortable disrupting existing sessions.

Fallback pools

If all pools within a load balancer have Load shedding enabled, some traffic will go to the fallback pool. To prevent any traffic from reaching the fallback pool, ensure at least one pool within the load balancer does not have load shedding enabled.

Pools in multiple load balancers

If you enable load shedding on a pool, it will shed the same percentage of traffic across all your load balancers. If you need an endpoint to shed different percentages of traffic for different load balancers, put that endpoint in multiple pools.

PreviousPerform planned maintenanceNextDNS persistence

Was this helpful?

YesNo

Edit pageReport issue

On this page

Overview

Step 1 — Identify at-risk endpoints

Step 2 — Shed default traffic from a pool

Configure via dashboard

Configure via API

Step 3 — Monitor traffic

Step 4 — Shed additional traffic (optional)

Step 5 — Disable load shedding

Additional notes

Shedding policies

Fallback pools

Pools in multiple load balancers

Edit pageReport issue

Getting started
PlansContact salesPartnersFind a partnerStartupsUnder attack?Domain name search

Company
AboutCareersInvestorsPressPress kitGlobal network

Public interest
Project GalileoAthenian ProjectCloudflare for CampaignsProject FairshotImpact/ESG

Compliance
Compliance resourcesTrust HubData ProtectionResponsible AITransparency reportReport abuse

Resources
App innovation reportCloudflare RadarCase studiesStatusSupportEventsBlog

Developers
DocumentationLearning centerCommunity

Solutions
SSE and SASE platformCloudflare AI CloudAI SecurityFrontend Development PlatformMulti-Tenant Platform DevelopmentWeb Security Platform

Start BuildingLog In

© 2026 Cloudflare, Inc.

Privacy policy|Report security issues|Terms of use|Trademark
|
Your privacy choices

Docs

------
导航页打开网址