FAQ
Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform

English

Türkçe

English

Türkçe

Appearance

Intermediate

Which stages does a request go through inside TR7 before it reaches the backend? ​

Short answer

A request arriving at an HTTP vService goes, in order, through the stages of reception and TLS termination, resolution of the real client IP (Trusted Proxies), SNI/Host Validation, the WAF scan, L7 DDoS & Threat Protection decisions, request actions in list order, WAF blocking and cache, HTTPS redirects, target selection (AGS, Conditional Backend Services, Default Backend Services) and Backend Service selection by algorithm and persistence. The response of the Backend Service also returns to the client by going through response actions, writing to the cache and compression. In L7 TCP, there are no HTTP-specific stages; the Network vService, on the other hand, distributes directly without terminating the connection.

How Does It Work? ​

Request path in an HTTP vService:

#StageWhat happens
1ReceptionThe request is received over the IP:port on which the vService listens. The connection count and per-second connection limits in the vService Limits profile (e.g. Max. Connections/s) are applied at this stage.
2TLS terminationIf it is HTTPS, the TLS session is decrypted on TR7; among the certificates in the Certificate field, the one matching the client's SNI is presented. If mTLS is on, the client certificate is validated here.
3Real client IPIf there is a CDN or proxy in front, the real IP of the client is resolved from the header with the Trusted Proxies profile. This is the first rule applied to the request; all subsequent stages (WAF, DDoS, IP reputation, conditions, logs) see this IP.
4SNI/Host ValidationIf it is on in the TLS Security Profile, the SNI in TLS is compared with the Host header of the request; if they do not match, the request is rejected with 421 Misdirected Request.
5WAF scanIf WAF is enabled, the request is scanned and a decision is made; the blocking response returns at stage 8.
6L7 DDoS & Threat ProtectionIf L7 DDoS & Threat Protection is enabled, first L7 DDoS, then IP Reputation, then Bot Protection are evaluated; only one of them applies a result to the request (blocking, CAPTCHA, quarantine…). Waiting Room also takes effect at this stage.
7Request actionsThe request actions in the Actions list of the vService run from top to bottom. If an action that ends the request, such as Block or Location redirection, runs, the request ends here.
8WAF blocking and cacheA request that the WAF finds malicious returns with the blocking response. If the request can be served from the cache with the Cache profile, the response is generated on TR7.
9HTTPS redirectsThe Redirect to HTTPS action and the HTTP → HTTPS protocol in the frontend are applied after the other request rules, regardless of their position in the Actions list.
10Target selectionIf AGS is enabled, a client without a session is first taken into the login flow. For other requests, the Conditional Backend Services (Content Switching) rules are evaluated from top to bottom, and the first match wins; if none matches, Default Backend Services is used.
11Backend Service selectionIn the selected target, a healthy Backend Service is selected according to the Algorithm and persistence setting. The connection is established with the SSL Service, SNAT and Proxy settings of the Backend Service.
12Response pathThe response goes through the response actions, HSTS in the TLS Security Profile, writing to the cache and compression, and returns to the client.

A few details directly affect the result:

  • The WAF sees the request in its original form. The WAF scan is done before the actions; the changes that the actions make to the request (e.g. an added header) do not change the request that the WAF sees.
  • A blocking action responds before the WAF. If an action blocks or redirects the request, the action's response returns instead of the WAF's blocking page.
  • A matching conditional target does not fall back to Default. When a Conditional Backend Services rule matches, the request goes to that rule's target; if all the Backend Services in that target are down, the request is not passed to Default Backend Services, and 503 returns. If a backup is needed, a Backup Service is added to the same target.
  • The health check runs outside the chain. Health checks run continuously, independently of traffic processing; at stage 11, only healthy Backend Services enter the selection.

Differences by vService Type ​

StageHTTPL7 TCPNetwork
TLS termination✓✓ (TCP + TLS)-
Trusted Proxies✓--
SNI/Host validation, WAF, AGS✓--
L7 DDoS & Threat Protection✓✓-
Actions✓ (request and response)✓ (TCP actions)-
Cache, compression✓--
Conditional Backend Services✓✓-
Algorithm and persistence✓✓✓ (L4 Persistence, SIP persistence)

The L7 TCP vService terminates the connection on TR7 but does not parse the request as HTTP. In this type, actions are applied before the L7 DDoS & Threat Protection decisions. The Network vService, on the other hand, does not terminate the connection and does not look at the content; it forwards the packet directly to a Backend Service according to the selected LB Mode and the algorithm.

Common Misconceptions ​

  • "The WAF also sees the header I added with an action." The WAF scans the request before the actions, in its original form.
  • "If I put the Redirect to HTTPS action at the top of the list, it runs before everything." HTTPS redirects are applied after the other request rules (actions, WAF and L7 DDoS decisions); if one of these rules ends the request, the redirect is not made.
  • "A response returned from the cache also goes to the Backend Service." A request served from the cache does not reach the Backend Service; the response is generated on TR7.
  • "If no Conditional Backend Services rule matches, the request is rejected." It goes to Default Backend Services; if that list is also empty, TR7 returns 503.

How it is done in the documentation

Related questions