🚥 Rate Limit & Access Control

After Deployment and initialization of CDN Domain On EdgeHit , users can perform Access Control and CDN Caching Rule under the Access Control section. Below are available option under the section.

Info

All these settings can only be applied to CDN Domain. But these setting can be mapped to more than 1 CDN Domains.

📏 Cache Rules

A CDN cache rule defines what content should be cached, how long it should be cached, and under what conditions. It helps improve performance by reducing origin server load and speeding up content delivery to users.

Cache Rule can be applied to multiple user CDN Domain. User can define Cache Rule Based on Target as Below:

Type	Description
File	Caches individual files (e.g., `/style.css`, `/image.png`)
Full Path	Caches requests that match the exact full URL path, including query strings
Directory	Caches all content under a specific directory path (e.g., `/assets/`)
Home	Caches only the homepage (i.e., `/` or index route of the domain)
Full Site	Caches all resources across the entire site, regardless of path
Regex	Uses regular expressions to define custom caching patterns for URLs

Each Type defines a specific pattern for caching, and its corresponding Rule field must be filled accordingly. Hover over the Rule input box for guidance tailored to the selected type.

By default, a global-default rule is applied to all CDN domain that does not have a custom defined cache rule. The default Cache Rule is as follow:

🔥 Hotlinks

Hotlink protection prevents unauthorized websites or users from embedding your CDN-hosted assets (such as images, videos, or scripts) by validating the Referer header in incoming HTTP requests. You can configure this protection per domain with flexible whitelist or blacklist rules.

When a user makes a request to a CDN-served asset, the CDN edge node checks the request’s Referer header before forwarding it to the origin.
Based on the selected Type (Whitelist or Blacklist), the rule determines whether to:
- Allow access (pass the request through)
- Block access (return a 403 Forbidden or redirect)
The optional Redirect URL lets you forward denied requests to a custom page.
The Empty Referer Access setting controls behavior for requests without any Referer header, often from:
- Direct URL access (e.g., pasted in browser)
- Certain browsers or privacy tools
- Mobile apps

Field	Description
Name	A unique name for identifying the hotlink rule.
select_cdn_domains	The list of CDN domains this rule applies to.
Type	Determines rule behavior: • `Whitelist` — Only allow listed referers • `Blacklist` — Block listed referers
Rule	List of referer patterns to match (e.g., `example.com`, `*.competitor.com`).
Redirect URL	(Optional) Where to redirect users when their request is blocked.
Empty Referer Access	Allow or block requests with no `Referer` header. Default is disabled (blocked).
Description	A free-text field for internal notes or documentation.

Whitelist Example

Allow only requests from your own domains, block everything else:

Type: Whitelist
Rule:
```
example.com  
blog.example.com
```
Redirect URL: https://example.com/no-hotlinking.html
Empty Referer Access: Disabled (blocked)

Blacklist Example

Block known bad referers, allow all others:

Type: Blacklist
Rule:
```
badsite.com  
*.leechers.net
```
Redirect URL: https://example.com/warning.html
Empty Referer Access: Enabled

Tip

Use wildcards (e.g., *.domain.com) for flexible matching.
Consider enabling empty referer access if your assets are intended to be shared via direct links (e.g., email, mobile apps).
Redirecting instead of blocking provides a better user experience and prevents blank or broken embeds.

🧱 Firewall Rules

firewall rules use an ACL-style evaluation (Access Control List) where each rule is checked in descending priority order. The system stops evaluating further rules once a match is found, and the corresponding action is executed.

You can define multiple match condition using AND , OR operators in one rule but only one action is allowed per rule

The following Field can be used as Matching Conditions

Field	Description	Example Value
Country	Match based on GeoIP country code or name	`MY`, `US`, `CN`
IP Address	Match a specific IP or CIDR range	`192.168.1.1`, `10.0.0.0/16`
ASN	Match based on Autonomous System Number	`13335` (Cloudflare)
URI Path	Match request path only	`/login`, `/home/about`
Full URL	Match the complete requested URL	`https://example.com/docs`
HTTP Method	Match request methods like GET, POST	`GET`, `POST`
Header Value	Match request headers like `User-Agent`, `Referer`	`User-Agent: curl/7.68.0`
Cookie	Match specific cookies or values	`sessionid=abc123`
Query String	Match key-value pairs in query string	`token=xyz`
TLS Version	Match based on TLS protocol version	`TLSv1.2`, `TLSv1.3`
User Agent	Match browser or bot signature	`Mozilla`, `curl`

Once a rule matches, one of the following actions is triggered:

Action	Description
Allow	Permits the request to proceed normally.
Block	Rejects the request with a 403 or equivalent denial.
JS Challenge (Auto)	Automatically serves a JavaScript-based validation challenge.
JS Challenge (When mouse movement detected)	Triggers JS validation only when bot-like behavior is suspected.
302 Redirect (Auto)	Redirects the user to another URL automatically.
Slide (Interactive Challenge)	Shows a slide-to-verify CAPTCHA to the user.
Captcha (Interactive Challenge)	Displays a CAPTCHA challenge for human verification.

Tip

You can define multiple rule with different Priority level similiar to how firewall security rule works in physical firewall devices

🚦Rate Limit Rules

Rate limiting rules help prevent abuse (e.g., DDoS, scraping, brute force) by temporarily blocking or responding to requests that exceed a defined request rate. These rules use matching conditions similar to firewall rules and apply limits per client or behavioral pattern.

Rule Breakdown

1. Matching Conditions

Rate limit rules begin by defining what kind of requests should be evaluated. This is done using conditions similar to firewall rules. You can match incoming requests by various fields such as:

Source IP address
Country (GeoIP)
URI path
HTTP method
Header values (e.g., User-Agent)
Cookie values

These conditions can be combined using AND / OR logic to form complex filters. Only requests that match all configured conditions are subject to rate limiting.

Example Condition:

ip.src eq "x.x.x.x" and http.request.uri.path eq "/login"

2. Define Characteristics to be Recognized

To control how requests are grouped for counting, you can specify a grouping field (or “characteristic”). Common examples include:

IP address
ASN (Autonomous System Number)
Country
Cookie
Header (e.g., API token)

This determines how the rule separates clients or traffic sources. For example, grouping by IP will count requests individually per user IP.

3. Rate Threshold

The core of the rate limit rule is the threshold, which defines how much traffic is allowed before action is taken.

Number of requests: How many requests are allowed…
Per time period: …within how many seconds.

If the threshold is exceeded by any client (based on the grouping characteristic), the configured action is triggered.

4. Action

Once the threshold is exceeded, a Block response is triggered. The Type can be customized with various response types:

Response Type	Description
Default response	Standard block (e.g., 403 Forbidden)
Custom HTML	Return a custom HTML page
Custom Text	Plain text block message
Custom JSON	API-style response with JSON body
Custom XML	Structured XML response
Redirect to URL	Sends 302 redirect to another page
No Response	Drops the connection silently (no reply)

A duration field is configured to control how long the blocking will last before the suspected client can access the CDN domain again.

🔨 Custom Header

Note

Custom Header is added for Response Header towards client that send Request to EdgeHit instances

if you are looking for setting to add custom header for request from EdgeHit to Origin Server, view the section Custom Proxy Header

The Custom Header feature allows you to define HTTP response headers that the CDN edge node will automatically insert into responses sent to clients. This lets you add metadata, debugging info, or control behavior (like caching or security) without needing to modify your origin server.

Purpose

Add diagnostic or debug headers (e.g., X-Edge-Node, X-Cache-Status)
Set custom security or CORS policies
Inject static values like X-App-Version, X-Service-Env
Inform clients or downstream services with custom flags

Behavior

These headers are injected at the CDN edge layer, not by your origin server.
They are added to every response for the matching domain.
Does not affect request headers or how the request is routed.

Example

For the domain cdn.example.com, you add the following headers:

Key	Value
`X-Env`	`Production`
`X-Powered-By`	`CDN-Edge`

Result:

Every response from cdn.example.com to client by Edge Node will include:

X-Env: Production
X-Powered-By: CDN-Edge

🔧 Custom Proxy Header

Note

Custom Proxy Header is added for Request Header towards origin that is send by EdgeHit instances

If you are looking for settings to add custom header for reponse from EdgeHit to Client, view the section Custom Header

The Proxy Header feature allows you to define custom HTTP headers that the CDN edge node will include in origin requests. These headers are added only when the CDN communicates with your origin server, not to the client responses.

This is useful for identification, authentication, environment control, and origin behavior customization.

Purpose

Identify requests coming from CDN (e.g., X-Forwarded-For, X-CDN-Node)
Pass API keys or tokens to the origin
Indicate environment or routing logic (e.g., X-App-Version: staging)
Add custom headers for origin-side logging or filtering

Behavior

The header is injected into the request from the CDN edge to the origin server.
It is not visible to the client, unlike response headers.
If the same header is already present, the CDN may override it based on configuration.

Info

If you were to Add the host value as Domain Name of CDN Domain for shared hosting scenario, you can also perform this action by defining Custom origin server host header in the CDN Domain Settings.

Both Setting will result in host HTTP header set when sending request from EdgeHit to origin server, and is useful to identify virtual host in many serverless hosting scenario

📦 Cache Prefetch

Note

Use Full URL with HTTP(s) protocol field when using Cache Prefetch

Cache Prefetch allows you to proactively load specific content into CDN edge nodes before it is requested by users. This ensures that users experience faster access to important assets by reducing the initial latency that comes from fetching content from the origin.

Cache Prefetch Can be performed under the CDN > Cache Prefetch > Add section.

Use Case

Use this feature when:

Launching new content that you expect to receive high traffic
Preventing cold-cache issues during high-demand events
Reducing time-to-first-byte (TTFB) on anticipated URLs

Upon submission, the system validates the reachability of the URL and fetches the content to be cached.

🧹 Cache Purge

Note

Use Full URL with HTTP(s) protocol field when using Cache Purge

Cache Purge is used to remove specific content from CDN edge nodes, forcing a fresh fetch from the origin on the next request. This is useful when content has been updated or needs to be invalidated immediately across all cached locations.

Cache Purge Can be performed under the CDN > Cache Purge > Add section.

Use Case Use this feature when:

You publish changes to a file (e.g., updated CSS or JS)
You want to remove sensitive or outdated content
Cache TTL has not yet expired but you need a real-time update