Network Type Category

What Is the Network Type Category Condition?

Network Type Category is a condition type that evaluates traffic according to the network type category to which the source IP address of the requesting client belongs. TR7 looks up the client's IP address in the embedded network type classification and determines which coarse category (data center, CDN, bot, anonymizer or end user) that IP belongs to.

In this way, the nature of the traffic source is understood: it can be distinguished whether the request comes from a real end user, from a cloud/hosting infrastructure, or from a network that hides identity.

Client IP 52.94.x.x → Network Type Category: Datacenter

With this condition, TR7 can recognize 5 different network type categories. For a finer distinction (for example, which cloud provider or a Tor exit node), the Network Type Group condition is used.

The Importance of the Network Type Category Condition

Knowing the nature of the traffic source provides a powerful means of distinction in security and traffic management.

With the Network Type Category condition:

• Data center/hosting IPs, from which automation and scraper traffic frequently comes, can be distinguished,
• Anonymous access that hides identity (in practice, Tor exit nodes) can be detected and restricted,
• Priority or different behavior can be applied to real end-user traffic,
• Verified search engine bots can be separated from normal users,
• Content, rate limit or access policies can be applied according to the nature of the source.

Network Type Category vs Network Type Group vs IP Intelligence Category:

Condition	What It Evaluates	Example
Network Type Category	The coarse network class of the IP	Datacenter, Anonymizer
Network Type Group	The fine network/provider group of the IP	Amazon AWS, Tor Exit Node
Blacklist IP Category	The IP reputation category	Spam, Botnet

TIP

Network Type Category looks not at the IP reputation (bad/good history) but at the network type of the IP (where it belongs). A data center IP may not be "bad"; the condition only indicates that it is an infrastructure connection, not an end-user connection.

The evaluated address is the effective source IP of the client: if a Trusted Proxy configuration is used on the vService, the check is performed on the real client IP behind the proxy. The classification data comes with the IP database updates; the End User (residential/mobile) classification is heuristic, based on network records. An IP that is not included in the classification data does not fall into any category: in this case, the condition is not met.

Supported vService Types

HTTP

L7 TCP

Network

The condition can be used at both the request (At Request) and response (At Response) stages; the network type is detected at the time of the request. The match is an exact match; each IP belongs to exactly one category.

How to Add?

A new Network Type Category Condition can be added through the TR7 web management interface by following the steps below:

1. The Configuration Menu is opened by clicking the TR7 logo at the bottom left.
2. The Load Balancer → Conditions → Add steps are followed.
3. Network type category is selected as Criteria.
4. The related configurations of the condition are made.
5. The condition is added by clicking the Add button.

Network Type Category Condition Add Form

Network Type Category Condition Add Form

INFO

Condition Name

An optional name can be entered for the condition to be created.

This field is especially important in the following scenarios:

• When many conditions are defined under the same vService,
• When conditions with similar criteria need to be distinguished,
• When it is necessary to quickly understand which business rule the condition represents.

When this field is left empty, TR7 analyzes the content of the related condition and creates an automatic, descriptive name in the Condition Description field. This generated description is used as the name in condition lists.

INFO

Criteria Required

The field that determines the type of the condition; Network type category is selected from the searchable dropdown list. This selection determines the fields displayed in the form. The criterion cannot be changed after the condition is saved: if a different criterion is needed, a new condition is defined. For all criteria in the list and their scopes, the criteria catalog on the Conditions page can be referred to.

INFO

Network Type Category Name Required

The network type categories to be matched are selected from this list. TR7 can recognize 5 different categories.

Available Network Type Categories:

Category	Description
Datacenter	IPs belonging to cloud and hosting providers (e.g. AWS, Azure, OVH).
CDN	IPs belonging to content delivery networks.
Verified Bot	Verified search engine and service bots (e.g. Googlebot).
Anonymizer (VPN / Proxy / Tor)	Networks that hide identity. In the current classification data, this category in practice covers Tor exit nodes; no separate group is defined for general VPN/proxy detection.
End User	Real end-user access (residential and mobile networks).

More than one category can be selected. It works with OR logic, and the condition is met when the client's IP belongs to any of the selected categories.

INFO

Condition Description

It is created automatically by TR7 in line with the entered criteria and values.

This description:

• which value the condition applies to,
• which criterion it works on,
• the quick understanding of the condition on listing screens

is produced dynamically by the system so as to provide these.

TIP

The detected category name can be used in actions with the Network type category smart variable (e.g. as the value of an HTTP header or a log field).

INFO

Form Buttons

Add

The condition adding process is completed by clicking the Add button.

Add & Repeat

With the Add & Repeat button, the condition adding process is completed, and another new condition can be added with different configurations without leaving the related window.

Condition Added

Operational Usage Recommendations

• The End User Should Be Distinguished. The End User category should be used to detect real user traffic; the remaining traffic originates from infrastructure, bot, anonymous or unclassified sources (IPs not included in the data do not fall into any category).
• Anonymous Access Should Be Limited. On sensitive pages, redirecting the Anonymizer category to CAPTCHA verification instead of blocking it reduces risk without excluding legitimate VPN users.
• Data Center Traffic Should Be Monitored. Scraper and automation traffic mostly comes from data center IPs; rate limiting or marking should be the starting point before direct blocking.
• Details Should Be Added with Group. If a specific provider (e.g. only AWS) needs to be targeted, the Network Type Group condition should be preferred.

Common Usage Scenarios in Live Environments

The examples below show how the related condition is applied in the most frequently encountered use cases in real systems. These scenarios are based on practices that are widely preferred in live environments and rest on experience gained in the field.

Scenario 1: Limiting Data Center-Originated Scraper Traffic

Purpose: Content collection software (scrapers) and automation bots mostly come from cloud/hosting IPs. To separate this traffic from real users and apply rate limiting or verification.

Configuration: Network Type Category → Datacenter

Action Recommendations:

• ✅ Advanced Captcha → Data center-originated requests are redirected to CAPTCHA verification, and automation is filtered out.
• ✅ Bandwidth Limitation → Scrapers are slowed down by applying a rate limit to these sources.

Scenario 2: Redirecting Anonymous (VPN/Proxy/Tor) Access to Verification

Purpose: To reduce the fraud risk by subjecting traffic coming from networks that hide identity to additional verification on sensitive pages such as login and payment.

Configuration: Network type category name → Anonymizer (VPN / Proxy / Tor)

Action Recommendations:

• ✅ Advanced Captcha → Users coming from anonymous sources are verified with CAPTCHA (together with the Path condition: /login).
• ✅ Block → On critical management paths, anonymous access is blocked entirely with 403 Forbidden.

Scenario 3: Special Behavior for Verified Bots

Purpose: To prevent CAPTCHA/blocking from being applied to verified search engine bots (e.g. Googlebot) by separating them from real users, and to protect SEO access.

Configuration: Network Type Category → Verified Bot

Action Recommendations:

• ✅ Add HTTP Header → By adding the X-Verified-Bot: true header, the Backend Service marks the bot traffic.
• ✅ Conditional Silent Log → Noise is reduced by logging verified bot requests silently.

Scenario 4: Only End-User Access to the Management Panel

Purpose: To allow access to the management panel only from real end-user networks (residential/mobile), and to block automation attempts coming from data center and anonymous sources.

Configuration: Network type category name → Datacenter, Anonymizer (VPN / Proxy / Tor)

Action Recommendations:

• ✅ Block → Access to the /admin path from data center and anonymous sources is blocked with 403 Forbidden (together with the Path condition: /admin).
• ✅ Show Content → A security warning page is shown to blocked accesses.