1 of 1 people found this helpful
Go to REPORTING -> LOG FILE MANAGEMENT -> ACTIVATE LOG FILES and ascertain that the field "proxy/gateway (client)" is checked for HTTP Access Log and that "Web Requests (REQMOD)" is checked for HTTP Access Denied Log. Then, click on button "Customize HTTP Access Log" and ascertain that you have "auth_user" (with quotes) in your HTTP Access Log File Structure.
Let us know if it solves the problem.
Thanks for that. I made / confirmed the settings you mentioned. However,this does not seem to be the problem.
The other change I made yesterday was to use a Proxy.pac file and I think the problem is with the .pac file. It is causing the browsers to bypass the proxy. I changed it back to manually specifying the IP of the Proxy Server and started to see the access logs being populated again. Will need to work on the .pac file to resolve the issue I guess. Will update the post later.
To test your proxy.pac file result, use the Google testing tool PacTester.exe
PS: Be carefull with direct ip config to the proxy. Using a DNS entry with a low TTL allow you to rapidly move people to a secondary proxy. The failover section of the proxy.pac will «normally» do that also but, we had some issue where it wasn't working.
PS2: Make sure also that nobody except you for testing, use a direct entry instead of the proxy.pac file. Some of our « web deloppers » put a direct entry in a new Stress tool for some internal test sites and overflow the proxy with it... Those sites were normally excluded in the proxy.pac file... I start digging when I saw requests for those sites in the logs and our proxy going unresponsive at some point.