Setup LSWS as cache reverse proxy

LSWS can be setup as reverse proxy since earlier version (2.0). It can integrate with built-in cache to provide cache reverse proxy. This setup extends the benefit of LSWS cache for backends that are not necessarily using a LSWS web server. It also provides the benefit of LSWS anti-ddos as well.

      Admin CP => Configuration => Server => External App        
         Type: Web Server
         Name: test-proxy
         Address: 10.1.2.3:80
         Max Connections: 150
         Initial Request Timeout (secs): 60
         Retry Timeout (secs): 0

Note:

• Max Connections is for 1 CPU core. IOW, for 2 CPU license (minimum requirement for Cache), the total Max Conn is 300 (150×2).

      Admin CP => Configuration => Virtual Hosts
         Basic
         =====
           Base
             Virtual Host Name: proxy-vhost
             Virtual Host Root: $SERVER_ROOT/proxy/
             Config File: $VH_ROOT/conf/vhconf.xml
           Connection
             Max Keep-Alive Requests: 1000
           Security
             Follow Symbolic Link: No
             Enable Scripts/ExtApps: No
             Restrained: Yes
           Leave default for the rest.

         General
         =======
           General
             Document Root: $VH_ROOT/html/

       Admin CP => Configuration => Virtual Hosts => Context
          Type: proxy
          URI: exp: /*
          Web Server: [Server Level]: test-proxy
          Leave default for the rest.

5a. Enable cache at Server Level

5b. Set up cache policy at vhost Level

Note:

1. Some of the configuration settings (vhost name, IP addresses, etc) shown in the screenshots are meant for illustration purposes only.
2. The set up has been tested and worked on a production server running varnish+nginx+tomcat+postgresql, being able to defend 20000 requests/sec HTTP ddos attacks (with LiteSpeed Advance Anti-DDoS setup).
3. Above setup can be easily extended to support proxy'ing multiple backends with each vhost (with its own web server type context) per each backend.
4. The setup mentioned above can easily be extended to support load balancing multiple backends by creating a loadbalancer context at vhost level based on a loadbalancer external app (server or vhost level) with proxy::backend* being its worker.