smoxy

English

Deutsch

English

Deutsch

Appearance

Request Lifecycle ​

This page explains what happens to a request from the moment a visitor's browser resolves your hostname until the response is delivered — and in which order smoxy's features act on it. Use it as the mental model behind every other page: security decisions, rules, caching, and origin fetching all happen at a specific point in this sequence.

Visitor
  │
  1. DNS & TLS ─── CNAME resolves to smoxy · certificate served
  │
  2. Hostname → Zone ─── zone settings & CDN flag applied
  │
  3. IP Lists ─── zone allow/block first, then global allow/block
  │
  4. Access Rules ─── allow · block · challenge · skip
  │
  5. Scenarios & WAF ─── reputation · Under Attack Mode · WAF
  │
  6. Rewrite Rules ─── URL is rewritten before anything downstream sees it
  │
  7. Conditional Rules ─── per-request overrides · then Basic Auth
  │
  8. Cache ─── HIT served from the edge · MISS/BYPASS continue
  │
  9. Origin ─── default backend (origin or load balancer)
  │
  10. Response processing ─── optimization · SSI/ESI · custom headers · custom pages
  │
Visitor

1. DNS & TLS ​

A request reaches smoxy because the hostname's CNAME record points at smoxy. Until that record resolves to smoxy, nothing else on this page applies — the zone can be fully configured and certificates issued without any traffic being redirected.

At the edge, smoxy terminates TLS using the certificate that covers the hostname (see How SSL Works).

2. Hostname → Zone resolution ​

The Host header maps the request to a hostname, and the hostname to its zone. From this point on, all of the zone's configuration applies: proxy settings, security, rules, caching, and optimization. Two switches gate everything downstream:

  • The zone's Enabled/Disabled toggle (zone header) — a disabled zone does not process traffic with smoxy features.
  • The hostname's CDN flag — with CDN disabled, caching and optimization are skipped for this hostname, while proxy and security handling can still apply.

Redirects are resolved right after zone resolution — a redirect hostname answers here, before any security or content handling.

See Hostnames and What is a Zone?.

3. IP Lists ​

Security screening happens before content handling, so blocked traffic never touches the cache or your origin. The IP lists are evaluated customer-first — your zone's decision overrides the global one:

  1. Zone allowlist — a match flags the request s-allowlist and skips the zone blocklist, reputation, Under Attack Mode, and the WAF. It does not skip access rules or Basic Auth. Because allowlisted traffic is neither ingested nor scored by the managed scenarios, an allowlisted IP can never be blocked or challenged by a scenario.
  2. Zone blocklist — a block entry ends the request here (a challenge must be passed to continue). Because this runs before the rule stages, a zone blocklist entry cannot be overridden by an allow access rule — use the zone allowlist to exempt an IP.
  3. Global allowlist — smoxy's operator-managed trust list; a match bypasses everything below including access rules.
  4. Global blocklist — smoxy's operator-managed blocklist. Note the customer-first consequence: a zone allowlist entry overrides even a global block for that zone.

This matches what Threat Lookup displays as the decision source: zone → global blocklist → global reputation.

4. Access Rules ​

Access Rules run after the IP lists and before the scenario/WAF stage: they evaluate request properties (IP, country, path, user agent, …) and allow, block, challenge, or skip. The Skip action exempts the request from the WAF stage or from challenges; Stop Mode halts evaluation of further access rules after a match. Access rules apply even to zone-allowlisted traffic — they are your own policy layer on top of the trust lists.

5. Scenarios & WAF ​

Unless an allow (or a skip action) exempted the request, three checks follow in order:

  1. Reputation — decisions produced by the managed scenarios for this IP (block, challenge, or throttle). The scenario engine itself runs out-of-band on the traffic logs; the request path only enforces its stored verdicts — which is why Threat Lookup can show the full decision history.
  2. Under Attack Mode — when active for the zone, visitors must pass a challenge before continuing.
  3. WAF — the managed ruleset inspects the request and blocks matches (typically with a 403).

6. Rewrite Rules ​

Rewrite Rules transform the URL before anything downstream sees it. Everything after this stage — conditional rules, the cache key, and the origin request — operates on the rewritten URL. Rules match with =, ~, or ~* and can reuse capture groups in the target.

7. Conditional Rules ​

Conditional Rules are the last rule stage. All matching rules apply (in ascending position order, unless a matching rule sets Stop), and each can override zone settings for this single request — caching behavior, cache key composition, image optimization settings, basic auth, and more. See Execution & Ordering for the full pipeline semantics.

After the rule stages, Basic Auth is enforced (as configured on the zone or overridden per rule). It applies even to allowlisted traffic — an allow never bypasses Basic Auth.

8. Cache ​

With security passed and the final URL known, smoxy decides whether the response can come from the edge cache:

  1. Eligibility — the hostname has CDN enabled and the response Content-Type is cacheable (see Supported MIME Types). HTML requires the zone's Dynamic cache to be enabled.
  2. Cache key — built from the request URI and query string, optionally extended by hostname and cookie values (Cache).
  3. HIT — the key exists in the cache: the response is served from the edge, the origin is not contacted, and the response carries s-cache: HIT.
  4. MISS — not cached yet: the request continues to the origin and the response is stored according to the TTL and the origin's Cache-Control.
  5. BYPASS — smoxy deliberately skips the cache: the origin sent no-cache, private, or max-age=0 without a positive s-maxage (with Respect origin Cache-Control enabled), the request carried a valid http-bypass header, or the content type is ineligible. Remember: s-maxage takes precedence — max-age=0, s-maxage=3600 is cached (details).

Stale-cache options can serve expired content while the origin is unreachable or while a fresh copy is being fetched (Stale Cache).

9. Origin ​

On MISS or BYPASS, smoxy forwards the request to the zone's default backend — a single origin or a load balancer distributing across origins via Random or IP Hash (Backends). The request arrives at your origin with:

  • the configured Host header (or the origin's default),
  • your custom request headers (Proxy),
  • smoxy's GeoIP headers describing the visitor's location (GeoIP Headers).

10. Response processing ​

Before the response reaches the visitor (and the cache), smoxy applies:

  • Image optimization — AVIF/WebP conversion and JPEG quality targeting, per zone settings or conditional-rule overrides (Optimization).
  • HTML minification — if enabled (Optimization).
  • SSI / ESI processing — edge-side page assembly (Cache).
  • Custom response headers (Proxy).
  • Custom error pages — served in place of error responses (Custom Pages).
  • Debug headers — including s-cache, when enabled (Proxy).

To verify (edge team)

The exact order within response processing (e.g. minification before/after SSI/ESI assembly; whether optimized image variants are cached separately) is not yet documented.

Where to go next ​