Showing results for 
Search instead for 
Did you mean: 
Jeffrey Richmond
Cisco Employee
Cisco Employee


The Web Proxy feature is the main feature of the WSA that allows the appliance to filter HTTP traffic. While the Web Proxy can be enabled with minimal configuration, it is important to know how each of the settings can be configured and how they affect the operation of the Web Proxy.



The Web Proxy feature is the only feature that is required to be enabled in order to use the WSA to filter HTTP traffic. Due to the importance of the Web Proxy, it is vital that this feature is configured correctly. In this guide, I will cover how to configure the Web Proxy.



1)    To enable the Web Proxy, access the WSA GUI and go to Security Services > Web Proxy.


Web Proxy Disabled.png




2)    Click on Enable, which will enable the Web Proxy and show an overview of the Web Proxy Settings.


Web Proxy Page.png




3)    At this point, the Web Proxy is functional. To further configure the Web Proxy, click on Edit Settings…, which will bring you to the Edit Web Proxy Settings page.


Edit Web proxy Settings Page.png 




4)    (Optional) Configure the remaining settings for the Web Proxy.

  • HTTP Ports to Proxy

       The ports listed here will determine what ports the WSA is listening on for HTTP traffic. The WSA will use the ports 3128 and 80 by default as the Web Proxy ports.


*Important* When using only one interface for the WSA, do not configure a port here that is in use elsewhere on the proxy. If using a different interface for data traffic than management traffic, it is possible to configure a port here that is used for a management service, but it is not recommended.


  • Caching

       Uncheck the box here to disable caching of HTTP content (enabled by default).


  • Proxy Mode

        This setting determines proxy mode of the WSA. It is recommended to keep the WSA in Transparent Mode as it can handle both transparent and explicit requests in this mode.


  • IP Spoofing

       This setting determines if IP Spoofing will be used. IP Spoofing will change the source IP address that is used when the WSA connects to the OCS from the WSA IP address to the Client IP address that made the request. This setting will require additional configuration not covered in this guide for WCCP if used with transparent requests. For Explicit requests, there must be a return route in place on the appropriate network device to send packets back to the WSA.


  • Persistent Connection Timeout

       A persistent connection is a socket that is kept open even after the HTTP request and HTTP response have been completed. Persistent connections must be negotiated when using HTTP/1.0. For HTTP/1.1, persistent connections are used by default without any additional headers. This setting determines how long the WSA should keep the socket open after traffic has stopped being sent. This setting is configured for 300 seconds for Client and Server side by default.


  • In-Use Connection Timeout

       This setting determines how long the WSA should keep a socket open when the transaction is still in progress and the Client or Server are waiting for a HTTP request or response. This setting is configured for 300 seconds by default for both Client and Server side connections.


  • Simultaneous Persistent Connections

       This setting determines the maximum number of persistent connections the WSA will maintain with servers (OCS) at any one time. This setting is configured for 2000 connections by default.


  • Generate Headers

       This setting determines what headers the WSA should include when sending HTTP requests or HTTP responses.


X-Forwarded-For – This HTTP header includes the IP address of the client making the request. This header is typically used when the WSA is sending traffic to some upstream device that can identify the IP address of the client instead of the IP address of the WSA. This header is disabled by default.

Request Side VIA – This HTTP header is sent when the WSA makes a HTTP request to the OCS and includes information about the WSA. By default, this information includes the following: HTTP version, hostname, port, product name, and version.

Response Side VIA – This HTTP header is sent when the WSA sends a HTTP response to a client that sent a HTTP request through the proxy. By default, this information includes the following: HTTP version, hostname, port, product name, and version.


  • Use Received Headers

       This setting when enabled allows the WSA to use the X-Forwarded-For headers it receives from a downstream device to identify the source IP address of a client instead of the IP address of the device that sent the request. Once enabled, you must enter the IP address of the trusted downstream device that is sending the HTTP requests with the X-Forwarded-For headers.


5)    Submit and Commit the changes!


Now that the Web Proxy is configured, the WSA is able to filter HTTP traffic.


Thank you Jeffrey for your very helpful post.

I just want to understand,why should we disable the HTTP caching and what is the effect of keeping it on or off?

Jeffrey Richmond
Cisco Employee
Cisco Employee

Hello Jay3,



Thanks for your comment!


The statement about disabling the HTTP cache was just to state what would happen if the box was unchecked, not necessarily a recommendation to disable HTTP caching.


Having said that, if you were to disable HTTP caching, that would prevent the WSA from caching any HTTP responses it receives to be served to other users requesting the same resource. This could lead to an increase in bandwidth for HTTP as the WSA will fetch the content from web servers with every request from end users. The benefit of having caching disabled would be that every HTTP request that a client makes would receive a HTTP response from the web server (via the WSA) that is up to date and specific to that client's HTTP request and HTTP headers.


In most scenarios, the benefits of caching HTTP content (less bandwidth used/lower latency) outweighs any potential drawbacks that could occur with caching (stale/incorrect response). There shouldn't be a need to disable HTTP caching unless there is a specific defect occurring directly related to HTTP caching and disabling it is a workaround -or- if there is some other specific issue that is occurring with HTTP caching that affects end users enough that disabling caching would help more than keeping it enabled.


Hopefully that helps to answer your question.



Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers
Quick Links