Rate Limiting
최신 업데이트：2026-03-25 16:14:35
Configuring Rate Limiting Rules
Reading time: About 7 minutes
Prerequisites: None
What Rate Limiting Is Used For
Rate Limiting sets a cap on the number of requests from the same source within a given time period. It helps protect against:
- Brute force attacks: High-frequency attempts to guess account passwords
- API abuse: Malicious programs calling APIs in bulk
- Content scraping: Large volumes of page content pulled in a short time
- Flash sale / scalping bots: Automated scripts grabbing inventory
Navigation path: Security Settings > Policies > [Target Hostname] > Rate Limiting
Creating a Rate Limiting Rule
Steps
- Go to Security Settings > Policies, and click the target hostname.
- Click the Rate Limiting tab in the top navigation, then click Add Rule.
- Fill in the configuration fields as described below, then click Save.
Core Configuration Fields
| Configuration Item | Description | Example |
|---|---|---|
| Match Conditions | Which requests to count. Filter by IP/IP range, path, request headers, etc. | IP/IP range equals 1.1.1.0/24 |
| Count On | Fixed to Request — counting is performed at the request stage | Request |
| Statistical Dimensions | The basis for counting requests. Up to two dimensions can be selected. | Client IP / Cookie / URL / User-Agent / Request Header |
| Trigger Condition | Counting window and threshold. Format: start processing on the Y-th request within X seconds | Start processing on the 10th request within 60 seconds |
| Action | What to do when the threshold is exceeded | Block |
| Action Duration | How long the action is enforced after being triggered (10–604800 seconds) | 300 seconds (5 minutes) |
| Effective Period | When the rule is active | All Time / Excluded Time / Selected Time |
Rule schedule options:
| Option | Description | Typical Use Case |
|---|---|---|
| All Time | The rule is always active | Regular protection rules |
| Excluded Time | The rule is paused during the specified time window (active the rest of the time) | Temporarily relax limits during flash sales, then auto-restore after the event ends |
| Selected Time | The rule is only active during the specified time window | Apply stricter limits only during off-peak hours |
Recommended Configuration Examples
Login endpoint — brute force protection:
- Statistical Dimension: Client IP
- Match Condition: Path =
/login, Method = POST - Trigger Condition: Start processing on the 10th request within 60 seconds
- Action: Block
- Action Duration: 300 seconds
API endpoint — abuse prevention (general):
- Statistical Dimension: Client IP
- Match Condition: Path starts with
/api/ - Trigger Condition: Start processing on the 100th request within 60 seconds
- Action: Block
- Action Duration: 60 seconds
Site-wide — high-frequency scraper protection:
- Statistical Dimension: Client IP
- Match Condition: Request Method = GET
- Trigger Condition: Start processing on the 500th request within 60 seconds
- Action: JavaScript Verification
- Action Duration: 120 seconds
How to Determine a Reasonable Threshold
Before setting a threshold, establish your normal traffic baseline through Analysis & Logs > Web Security Trends:
- Select a business peak period (e.g., 12:00–14:00)
- Review the maximum request frequency distribution from a single IP
- Set the threshold to 1.5–2 times the 99th percentile value of normal user behavior
Rule of thumb: A threshold set too low will block legitimate users; set too high, it will fail to provide protection. It is recommended to set the action to Log initially and run for 1–3 days to observe hits, then switch to Block.
Considerations During Flash Sales
Flash sales and limited-time promotions generate legitimate traffic spikes. You will need to:
- Estimate the peak QPS from historical sales events in advance
- Temporarily increase the rate limit threshold, or create relaxed rules for specific paths involved in the event
- Restore the original rules after the event ends