Overview

Organizations deploying GAJWAF across multiple nodes must ensure that application security policies, browser verification and security enforcement remain consistent regardless of which node processes a request.

Incorrect cluster configuration can result in repeated browser challenges, inconsistent security enforcement, intermittent application errors and unreliable session behavior.

The GAJWAF Multi-Node Cluster Setup & Verification Playbook provides a structured, five-step procedure for configuring and validating multi-node GAJWAF deployments.

The guiding principle is simple: One Secret. Every Node.

The playbook emphasizes the importance of configuring a common cluster secret across all participating nodes, maintaining consistent application configurations and selecting the correct high-availability architecture for the deployment environment.

Understanding Multi-Node GAJWAF Deployments

GAJWAF can be deployed using multiple nodes behind a load balancer or in a high-availability configuration.

For these deployments to function correctly, participating nodes must recognize browser verification passes and maintain consistent application security behavior.

A common cluster secret enables nodes to derive compatible signing keys, allowing browser verification passes issued by one node to be recognized by another.

Without this configuration, users may be repeatedly challenged when their requests are routed between different nodes.

What You'll Learn

The playbook covers five essential stages of multi-node deployment.

Step 1: Confirm the Deployment Topology

Identify the architecture used for the GAJWAF deployment.

The guide distinguishes between:

  • Single-Node Deployment: A standalone GAJWAF instance that does not require multi-node cluster configuration.
  • Multiple Nodes Behind a Load Balancer: Two or more GAJWAF instances receiving traffic through a common load balancer.
  • High-Availability Pair: Active and standby nodes configured for service continuity.

The deployment topology determines which clustering and high-availability settings are required.

Step 2: Configure a Common Cluster Secret

Learn how to configure the same cluster secret on every participating GAJWAF node.

Configuration Location: Settings → High-Availability Clustering

The guide explains two important settings:

  • Cluster Secret (cluster.secret): A long, randomly generated secret that must be identical across all cluster nodes.
  • Node Name (cluster.node): A unique identifier assigned to each node.

The cluster secret must be securely stored and preserved for future node replacement or recovery.

Important: Different cluster secrets can cause browser verification passes issued by one node to be rejected by another.

Step 3: Synchronize Application Configurations

Ensure that every GAJWAF node contains the same protected application configurations.

The playbook explains how to use configuration Export/Import or deployment automation to maintain consistency across nodes.

Administrators should verify that:

  • All protected applications are configured on every participating node.
  • Application configurations are consistent.
  • Sites are enabled on every required node.
  • Configuration changes are propagated across the deployment.

Inconsistent site configurations may cause intermittent application failures, including HTTP 421 errors, depending on which node receives a request.

Step 4: Select the Appropriate High-Availability Model

Different deployment environments require different approaches to high availability.

On-Premises Deployments

For supported Layer-2 network environments, GAJWAF provides a floating Virtual IP (VIP) high-availability model.

AWS and Azure Deployments

Cloud deployments should use the appropriate cloud load-balancing infrastructure to distribute traffic across GAJWAF nodes.

The playbook explains why on-premises floating VIP mechanisms should not be assumed to work in AWS or Azure networking environments.

In both cases, the participating GAJWAF nodes must use the same cluster secret.

Step 5: Verify Cluster Consistency

After completing the configuration, administrators should validate that the nodes behave consistently.

The playbook recommends:

  1. Opening the protected website in a fresh browser session.
  2. Completing the browser verification challenge.
  3. Sending subsequent requests through different GAJWAF nodes.
  4. Confirming that users are not repeatedly challenged.
  5. Applying a controlled test IP ban and verifying its behavior across all participating nodes.

If repeated browser challenges occur, administrators can enable Bot Check debug logging and review the results with GajShield Technical Support.

Successful validation confirms that browser verification passes are accepted across nodes and that the configured ban behavior is consistent.

Why This Playbook Matters

Multi-node deployments can improve application availability and support distributed traffic processing, but they also introduce additional configuration requirements.

Following this playbook helps organizations:

  • Configure GAJWAF across multiple nodes.
  • Prevent repeated browser verification challenges.
  • Maintain consistent application security policies.
  • Reduce intermittent failures caused by configuration mismatches.
  • Select an appropriate high-availability model for cloud or on-premises deployments.
  • Verify shared browser verification behavior.
  • Validate security enforcement across participating nodes.
  • Maintain documented cluster configuration records.

Cluster Verification and Documentation

The playbook includes a cluster-record template to help administrators document:

  • Node names and addresses.
  • Confirmation that the shared cluster secret is configured.
  • Application configuration synchronization status.
  • Browser verification pass sharing.
  • High-availability deployment model.
  • Secure storage location of the cluster secret.
  • Date of the latest configuration synchronization.
  • Browser re-challenge and IP ban test results.
  • Verification details and date.

Security Note: The actual cluster secret should never be recorded in the cluster checklist. Only its configuration status and secure storage location should be documented.

Maintaining this record can simplify troubleshooting, node replacement and future configuration reviews.

Download the Playbook

Document: GAJWAF Playbook – Multi-Node Cluster Setup & Verification
Document Version: 1.0
Document Type: Deployment and High-Availability Operations Playbook
Publication: October 2026
Pages: 6
Intended Audience: GAJWAF Administrators

Attachment: GAJWAF_Playbook_Multi_Node_Cluster.pdf

Download the attached PDF for detailed clustering procedures, configuration parameters, high-availability deployment guidance, validation tests and the cluster-record template.

Related Documentation

For additional guidance, refer to:

Technical Support

For assistance with GAJWAF clustering, high availability, load balancing or session verification issues, contact GajShield Technical Support or your authorized GajShield partner.

Website: https://www.gajshield.com

GAJWAF: Different Applications. Different Protection. Shared Risk Intelligence.