Load balancing PaperCut Print Servers
Updated on November 7, 2025
•
Published on March 7, 2023
Benefits of load balancing PaperCut Print Servers
Using a Loadbalancer.org appliance to load balance PaperCut delivers the following benefits:
- Scalability
- High Availability (HA)
- Multi-site failover
- Support for Microsoft Print servers
In v20.0 of PaperCut NG and MF, PaperCut introduced a new Application Server Failover feature, which supports using a Network Load Balancer to provide resiliency. Automatic Application Server failover allows for two (or more) PaperCut Application Servers to be positioned behind a Network Load Balancer in an active/passive configuration.
PaperCut MF and NG v20.0 include in-app technology to ensure only a single healthy instance is active and communicating with the external database. At the same time, the Network Load Balancer is used to direct all incoming traffic to the active server and redirect this should a failover happen. If an outage does occur, it’s then a process of resolving this before manually restarting the server or PaperCut Application Server service before it can re-enter the rotation as a passive server.
About PaperCut
PaperCut is a leading print management solutions provider. Its powerful management solution, PaperCut MF, enables users to reduce their print spend and paper waste, increase security, and enhance document workflows. With the free Mobility Print add-on, available for NG and MF, managing bring-your-own-device (BYOD) printing has never been easier.
Mobility Print also serves as a great alternative to Google Cloud Print following its discontinuation at the end of 2020.
Why Loadbalancer.org for PaperCut?
Loadbalancer’s intuitive Enterprise Application Delivery Controller (ADC) is designed to save time and money with a clever, not complex, WebUI.
Easily configure, deploy, manage, and maintain our Enterprise load balancer, reducing complexity and the risk of human error. For a difference you can see in just minutes.
And with WAF and GSLB included straight out-of-the-box, there’s no hidden costs, so the prices you see on our website are fully transparent.
More on what’s possible with Loadbalancer.org.
How to load balance PaperCut
The load balancer can be deployed in 4 fundamental ways: Layer 4 DR mode, Layer 4 NAT mode, Layer 4 SNAT mode, and Layer 7 Reverse Proxy (Layer 7 SNAT) mode.
For PaperCut, Layer 4 DR mode is recommended. This mode offers the best possible performance since replies go directly from the Real Servers to the client, not via the load balancer. It is also transparent meaning that the client source IP address is maintained through to the load balanced servers.
If Layer 4 DR mode cannot be used due to Real Server or network topology reasons, then Layer 7 Reverse Proxy is recommended.
Virtual service (VIP) requirements
The VIPs required are slightly different depending on which load balancing method is used. This is due to two main reasons:
- Layer 7 Reverse Proxy is not transparent. This means that the source IP address of the client is lost and replaced by the load balancer’s own IP address. However, as mentioned here under Set up trusted proxy servers, some Papercut features require the client’s IP address to be available to function correctly. As an alternative, X-Forward-For headers can be used. HTTPS traffic on port 9192 must first be decrypted on the load balancer to allow the headers to be inserted.
- Layer 7 Reverse Proxy does not support UDP. This means that DNS printer discovery can only be implemented using TCP and mDNS which relies solely on UDP and therefore cannot be load balanced when using Layer 7 Reverse Proxy.
For load balancing print servers, the preferred and default load balancer configuration uses Layer 4 DR mode (Direct Routing, aka DSR / Direct Server Return). This is a very high performance solution that requires little change to your existing infrastructure. It is necessary to solve “the ARP problem” on the real print servers. This is a straightforward process, and is covered in our deployment guide below (see section 2 of the appendix ‘DR Mode Server Configuration’, page 33).
It is also possible to load balance a PaperCut secondary print server using Layer 7 Reverse Proxy. This mode might be preferable if making changes to the real print servers is not possible, although some Windows Registry keys need to be added.
Please note that load balanced connections using Layer 7 Reverse Proxy mode are not source IP transparent, which is not usually an issue when load balancing print servers but should still be considered.
VIPs when using Layer 4 DR mode
| Ref. | VIP Name | Mode | Port(s) | Persistence Mode | Health Check |
|---|---|---|---|---|---|
| VIP 1 | App_Servers_HTTP-HTTPS | Layer 4 DR mode | TCP 9191,9192 | None | HTTP (GET) |
| VIP 2 | App_Servers_OtherPorts | Layer 4 DR mode | TCP 9193 | None | Connect to Port |
| VIP 3 | Print_Servers | Layer 4 DR mode | TCP 445 | Source IP | Connect to Port |
| VIP 4 | Mobility_Print_Servers | Layer 4 DR mode | TCP 9163,TCP 9164 | Source IP | HTTP (GET) |
| VIP 5 | Mobility_Discovery_DNS | Layer 4 DR mode | TCP/UDP 53 | Source IP | Connect to Port |
| VIP 6 | Mobility_Discovery_mDNS | Layer 4 DR mode | UDP 5353 | Source IP | Connect to Port |
VIPs when using Layer 7 Reverse Proxy
| Ref. | VIP Name | Mode | Port(s) | Persistence Mode | Health Check |
|---|---|---|---|---|---|
| VIP 1 | App_Servers_HTTP-HTTPS | L7 Reverse Proxy (HTTP/HTTPS) | TCP 9191 (HTTP), TCP 9192 (HTTPS via HAProxy SSL termination) | None | HTTP (GET) |
| VIP 2 | App_Servers_OtherPorts | L7 Reverse Proxy (TCP) | TCP 9193 | None | Connect to Port |
| VIP 3 | Print_Servers | L7 Reverse Proxy (TCP) | TCP 445 | Source IP | Connect to Port |
| VIP 4 | Mobility_Print_Servers | L7 Reverse Proxy (TCP) | TCP 9163,TCP 9164 | Source IP | HTTP (GET) |
| VIP 5 | Mobility_Discovery_DNS | L7 Reverse Proxy (TCP) | TCP 53 | Source IP | Connect to Port |
Load balancing deployment concept
Using Layer 4 DR
Using Layer 7 Reverse Proxy
About Layer 4 DR mode load balancing
One-arm direct routing (DR) mode is a very high performance solution that requires little change to your existing infrastructure.
DR mode works by changing the destination MAC address of the incoming packet to match the selected Real Server on the fly which is very fast.
When the packet reaches the Real Server it expects the Real Server to own the Virtual Services IP address (VIP). This means that you need to ensure that the Real Server (and the load balanced application) respond to both the Real Server’s own IP address and the VIP.
The Real Servers should not respond to ARP requests for the VIP. Only the load balancer should do this. Configuring the Real Servers in this way is referred to as Solving the ARP problem.
On average, DR mode is 8 times quicker than NAT for HTTP, 50 times quicker for Terminal Services and much, much faster for streaming media or FTP.
The load balancer must have an Interface in the same subnet as the Real Servers to ensure Layer 2 connectivity required for DR mode to work.
The VIP can be brought up on the same subnet as the Real Servers, or on a different subnet provided that the load balancer has an interface in that subnet.
Port translation is not possible with DR mode, e.g. VIP:80 → RIP:8080 is not supported. DR mode is transparent, i.e. the Real Server will see the source IP address of the client.
About Layer 7 Reverse Proxy load balancing
Layer 7 Reverse Proxy uses a proxy (HAProxy) at the application layer. Inbound requests are terminated on the load balancer and HAProxy generates a new corresponding request to the chosen Real Server. As a result, Layer 7 is typically not as fast as the Layer 4 methods.
Layer 7 is typically chosen when enhanced options such as SSL termination, cookie based persistence, URL rewriting, header insertion/deletion etc. are required, or when the network topology prohibits the use of the Layer 4 methods.
Because Layer 7 Reverse Proxy is a full proxy, any server in the cluster can be on any accessible subnet, including across the Internet or WAN.
Layer 7 Reverse Proxy is not transparent by default i.e. the Real Servers will not see the source IP address of the client, they will see the load balancer’s own IP address by default, or any other local appliance IP address if preferred (e.g. the VIP address). This can be configured per Layer 7 VIP.
If required, the load balancer can be configured to provide the actual client IP address to the Real Servers in two ways:
- Either by inserting a header that contains the client’s source IP address, or
- By modifying the Source Address field of the IP packets and replacing the IP address of the load balancer with the IP address of the client.
Layer 7 Reverse Proxy mode can be deployed using either a one-arm or two-arm configuration. For two-arm deployments, eth0 is normally used for the internal network and eth1 is used for the external network, although this is not mandatory.
No mode-specific configuration changes to the load balanced Real Servers are required.
Port translation is possible with Layer 7 Reverse Proxy e.g. VIP:80 → RIP:8080 is supported. You should not use the same RIP:PORT combination for Layer 7 Reverse Proxy VIPs and Layer 4 SNAT mode VIPs because the required firewall rules conflict.
