> ## Documentation Index
> Fetch the complete documentation index at: https://docs.safesquid.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SafeSquid Proxy Cluster

> SafeSquid proxy cluster overview — scale-out architecture, policy replication, failover design, and operational considerations for enterprise deployments.

# SafeSquid Proxy Cluster

## Problem statement

A single SWG node creates two enterprise risks: it becomes a single point of failure, and it limits growth to the capacity of one server. For large enterprises and mission-critical environments, that is not enough. The organisation needs multiple enforcement points with consistent policy, shared evidence, and a failover design that does not create policy drift.

## Client scenario

Use the cluster model when any of these are true:

* a single-node outage would interrupt business-critical web access
* peak demand exceeds the practical capacity of one proxy instance
* multiple sites require common policy
* the rollout requires staged expansion without redesigning the enforcement model

## Key benefits

* Scale-out by adding nodes rather than replacing the deployment model
* Automatic policy replication across nodes
* Consistent user experience across clustered enforcement points
* Better resilience when load balancers, WCCP, or egress design are planned correctly

## Prerequisites

Before you build a cluster, define:

* the traffic-distribution method
* the health-check method
* the failure domain for each node
* the logging and reporting path for clustered traffic
* the policy-change process and rollback path

SafeSquid is documented as **WCCP aware**, so traffic-redirection design can be part of the architecture when the network requires it.

## Setup instructions

This page is the architecture overview, not the full build runbook. Use it to choose the design, then move to the implementation guide.

SafeSquid's cluster-ready architecture supports:

* seamless addition of nodes for scale-out
* automatic policy replication across cluster nodes
* common operational behavior across nodes
* integration with load-balancing and traffic-redirection designs

The practical design split is:

* **scale-up** by adding CPU, RAM, and storage to a single node until the single-instance boundary no longer fits
* **scale-out** by adding nodes when you need more aggregate capacity or lower availability risk

Internal product knowledge confirms no documented maximum cluster node count. Per-instance capacity remains bounded, but aggregate cluster capacity scales through additional nodes.

## Verification and validation

After clustering is implemented, validate all of the following:

* traffic is actually distributed to the intended nodes
* policy changes replicate to all nodes
* a node failure does not create an unmanaged bypass path
* reporting still captures events from every active node
* SSL interception and identity-aware policies behave consistently across nodes

Useful evidence includes:

* load balancer or WCCP distribution state
* node-specific access logs
* policy-change timestamps across nodes
* reporting data showing traffic from each clustered member

## Troubleshooting guide

**Symptom:** Users get inconsistent policy results across nodes.\
**Likely cause:** Policy replication drift or node-specific configuration deviation.\
**Isolation:** Compare the active policy state and timestamps on each node.\
**Remediation:** Re-run the synchronization workflow and verify the replication path.\
**Retest:** Repeat the same policy-triggering request through multiple nodes.

**Symptom:** Traffic fails over poorly during node loss.\
**Likely cause:** Load-balancer health checks or redirection logic do not remove the failed node quickly enough.\
**Isolation:** Check the health-check state and egress path behavior during a controlled failure test.\
**Remediation:** Tune the health checks and remove stale node references.\
**Retest:** Repeat a planned node failure and confirm uninterrupted enforcement.

**Symptom:** Cluster capacity still saturates under growth.\
**Likely cause:** The design scaled up one node instead of scaling out enough nodes, or distribution is uneven.\
**Isolation:** Compare per-node concurrency and traffic distribution.\
**Remediation:** Add nodes or rebalance traffic.\
**Retest:** Re-run the peak-load scenario and confirm even spread.

## Related controls / next steps

* [Proxy Clustering](/Proxy_Clustering) for the implementation runbook
* [Deployment Planning](/deployment/deployment_planning) for sizing and failover preparation
* [Reporting Service](/Reporting_Service) for clustered evidence collection
* [SafeSquid SWG Overview](/safesquid_swg/architecture/safesquid_swg) for the full component model


## Related topics

- [Proxy Service](/safesquid_swg/application_ecosystem/proxy_service.md)
- [Configuration Sync](/use_cases/customisation/configuration_sync.md)
- [Welcome to SafeSquid](/getting_started/welcome.md)
- [Proxy Chain](/use_cases/scaling_and_high_availability/proxy_chain.md)
- [Transparent Proxy](/use_cases/scaling_and_high_availability/transparent_proxy.md)