How this works: This page must be hosted on benlawllc.com and served through Fastly. When loaded, the VCL runs at the edge before the page is delivered. This diagnostic reads the X-CHEQ-* headers from its own response and inspects cookies set by the CHEQ JS tag — giving you a live view of the full integration.
Request flow
→
Fastly edge
VCL intercepts
→
CHEQ API
Pre-page validate
→
→
→
→
Next request
Post-page validates
Stage 1 — Pre-page load validation (every request)
VCL checks
?
VCL is running
X-CHEQ-Action must appear in Fastly's response. If missing, snippets are not deployed or cheq_config dictionary is empty.
Checking...
?
Traffic decision
Expect allow for legitimate traffic. block or captcha means enforcement is active.
Waiting...
?
Mode: monitoring vs blocking
In monitoring mode all traffic passes. Switch to blocking only after confirming no false positives.
Waiting...
↻ Re-run diagnostic
Clear log
Raw CHEQ + Fastly headers
X-CHEQ-Action —
X-CHEQ-Verdict —
X-CHEQ-Threat-Code —
X-CHEQ-Validation —
X-CHEQ-Request-ID —
X-Cache —
X-Served-By (POP) —
Age —
Stage 2 — Post-page load validation (requires CHEQ JS tag)
CHEQ cookies in this browser
?
cq_request_id
Set by CHEQ JS on page load. Required for post-page validation. If missing, the JS tag is not loaded.
Checking...
?
_cheq_rti
CHEQ session ID — set alongside cq_request_id by the JS tag.
Checking...
?
cq_session_token
Set by VCL after a CAPTCHA is solved. HMAC-signed and IP-bound. Bypasses API calls for captcha_session_ttl seconds.
Checking...
?
cheq_block / cheq_captcha
Short-lived (60s) cookies set by VCL on block/captcha decisions. Used by real-time JS to redirect same-page.
Checking...
Validate endpoints
?
/__validate.js responds
VCL intercepts this path and returns JS. Empty response = valid. JS redirect = blocked. Must return 200.
Not tested yet
?
/__sec_block renders
VCL synthetic 403 block page. Confirms cheq_error.vcl snippet is deployed and working.
Not tested yet
Test /__validate.js
Open /__sec_block
/__sec_block opens in a new tab — shows the VCL synthetic block page if cheq_error.vcl is deployed.
Stage 3 — Fastly cache behavior
Cache state — CHEQ only bypasses cache for its own API sub-requests, not page requests
X-Cache —
X-Cache-Hits —
Cache-Control —
Age —
Surrogate-Key —
Vary —
What to expect:
CHEQ uses return(pass) only for its API calls — not your pages.
Page requests should HIT/MISS normally.
If every request is PASS, check your Cache-Control headers from origin.
Terminal verification (bypasses browser CORS — most reliable)
cURL commands for benlawllc.com
1. Check if VCL is running
curl -sI https://benlawllc.com/ \
| grep -i "x-cheq\|x-cache\|x-served"
2. With Fastly-Debug header
curl -sI https://benlawllc.com/ \
-H "Fastly-Debug: 1" \
| grep -i "x-cheq\|fastly-debug"
3. Simulate post-page (with cookie)
curl -sI https://benlawllc.com/ \
-H "Cookie: cq_request_id=test-abc-123"
4. Expected healthy response headers
X-CHEQ-Action: allow ← VCL running
X-CHEQ-Verdict: benign ← legit traffic
X-CHEQ-Validation: pre ← pre-page ran
X-Cache: MISS ← first visit
X-Served-By: cache-... ← Fastly POP
Diagnostic log & threat reference
Live log
Starting diagnostics...