Skip to main content
SafeSquid can attach diagnostic information to HTTP messages as X-SafeSquid-* and module-specific headers. Modules push entries onto the connection dheader list; when headers are sent, SafeSquid may insert a fixed identity block plus every marked dheader entry. This is the supported way to see which profiles, categories, and filters applied to a request.

​
Enable or disable

In System configuration, set Send Debugging Headers To:
  • Send Debugging Headers To (dheaders) — System configuration, global field.
  • NONE — Do not send debugging headers (production default).
  • CLIENT — Add debugging headers on responses to the browser.
  • SERVER — Add debugging headers on requests to the origin or upstream proxy.
  • BOTH — Send to client and server.
Enable CLIENT or BOTH only on a test profile or management network. These headers can reveal usernames, groups, and policy decisions.
The headers reflect the state of the connection at the point they are attached — the identity, categorisation, and policy results already resolved earlier in the pipeline for this same request.

​
Always included (when enabled)

  • X-Powered-By — product name
  • X-SafeSquid-Client-ID — clientid.request (match Detailed logs)
  • X-SafeSquid-User — username
  • X-SafeSquid-User-Groups — groups from Access restrictions
  • X-SafeSquid-Profiles — Access Profiles tags
  • X-SafeSquid-Categories / X-SafeSquid-Ref-Categories
  • X-SafeSquid-Request-Types, X-SafeSquid-Response-Types
  • X-SafeSquid-Application-Signatures
  • X-SafeSquid-Time-Profiles

​
Module and policy headers

Each module header appears only when that module actually ran and had something to report — which of them appear on a given request depends entirely on which filters the request passed through. During processing, modules append named headers to dheader. Common examples:
  • X-SafeSquid-Instance, X-SafeSquid-Subscription, X-Registered-Domain
  • X-SafeSquid-Access-Policy — Access Profiles reason
  • X-SafeSquid-Template — block or info template name
  • X-Cookie-Filter, X-Text-Analyzer, X-DNSBL-Filter
  • X-Clam-AV, X-Virus-Scan, X-DLP-Check, X-Image-Filter
  • X-Elevated-Privacy, X-URL-Cat, X-REF-Cat
Use browser developer tools (Network → response headers) or a capture. Correlate X-SafeSquid-Client-ID with Detailed logs client_id / request_id.

​
Bypass

To skip filters for a role, use the Access restrictions Bypass field. Keep Allow bypassing when you want temporary Access Profiles DENY bypass (cookie). Debug headers only report — they never change policy on their own. Turning them on alongside a Bypass configuration is a good way to confirm the bypass is genuinely taking effect: the relevant module’s header is simply absent from a request that was correctly skipped.

​
Examples

​
Diagnose an unexpected block without opening a report

  • Configuration: Set Send Debugging Headers To to CLIENT, temporarily, on a test or management network only. Reproduce the blocked request from the affected client’s own browser.
  • Result: the browser’s developer tools show the response headers, including X-SafeSquid-Profiles, X-SafeSquid-Categories, X-SafeSquid-User-Groups, and X-SafeSquid-Template — together these usually identify exactly which Access Profile and which category decided the block, without needing to search Detailed logs at all.

​
How to verify

  1. Set Send Debugging Headers To to CLIENT on a test profile or management network.
  2. Reproduce the request in question and inspect the response headers in the browser’s developer tools (or a packet capture).
  3. Note X-SafeSquid-Client-ID and cross-check it against Reports → Detailed logs to confirm both views describe the same transaction.
  4. Once diagnosis is complete, set Send Debugging Headers To back to NONE — leaving it enabled outside a controlled test exposes policy and identity information on every single response.

​
See also