Trace Squid 7 Authentication with debug_options Section 29
Use a bounded section-29 debug session to follow the challenge, client response, authentication helper and access-policy decision.
Squid's first 407 can be the start of authentication. To find where an attempt stops, follow one request sequence through the client, authentication machinery and access decision.
For a Squid 7 diagnostic session, section 29 contains authentication debug messages. A temporary configuration can keep the general warning level while increasing that section:
debug_options ALL,1 29,5Record the previous debug setting, apply the diagnostic configuration and reproduce a small, identifiable attempt. Read the debug output at the configured cache_log destination alongside the access log.
| Evidence to seek | Question it answers |
|---|---|
| The offered Proxy-Authenticate scheme | What did this proxy ask the client to use? |
| The client's authentication response | Did the client continue the offered exchange? |
| The authentication mechanism or helper result | Was an account accepted, rejected or blocked by a processing failure? |
| Squid's access-policy decision | What happened to the request after that authentication state? |
Some schemes require multiple challenge rounds. Repeated 407 entries alone do not establish that the browser ignored the prompt or that the supplied password was wrong.
For helper failures, inspect the configured helper and its scheme-specific result protocol. A process that cannot start is a different fault from a running helper rejecting an account. If authentication was accepted but Squid still denied the request, follow the matching access rules.
Restore the original debug level once the sequence is understood. Full level-9 output can be very large; authentication diagnostics also need restricted handling because account details and other sensitive state may appear.