CCcam Server Load Balancing: Setup & Config Guide

Running multiple CCcam servers sounds simple until you realize the hard part: distributing thousands of client connections evenly across them without losing stability. CCcam server load balancing is the practice of splitting incoming connections across multiple backend servers to prevent any single instance from becoming a bottleneck. It's not a feature built into CCcam itself—it has to be added at the proxy or client level.

If you're scaling beyond a single server, this guide covers the real architectures, configuration files, and troubleshooting steps you'll actually need. We'll skip the marketing talk and focus on what works, what breaks, and why.

What Is CCcam Load Balancing and Why It Matters

CCcam doesn't have native multi-server clustering. Each CCcam instance runs independently. CCcam server load balancing is the layer you build on top to distribute traffic—either at the proxy level (nginx, HAProxy sitting in front of multiple CCcam instances) or at the client level (clients configured with multiple server addresses and picking one).

A single CCcam server typically handles 500–1500 concurrent connections, depending on CPU cores, RAM, card count, and ECM complexity. Hit that ceiling and new clients either get rejected or queue up, creating unplayable channels or timeouts.

Here's what people get wrong: load balancing doesn't make channels faster. It prevents saturation. Speed is determined by the slowest card in your stack and network latency. But load balancing does three things well: it keeps one user from consuming all available connections, it lets you serve more simultaneous clients, and it provides failover—if one server crashes, traffic routes to the others.

Difference Between Local Balancing and Distributed Load Balancing

Local balancing is client-side: each user adds multiple CCcam servers to their client config and the client picks one (usually the first available). No centralized orchestration. It's crude—all clients hit the first server until it fails, then they cascade to the second.

Distributed balancing uses a proxy (nginx, HAProxy, or a custom gateway) that sits between clients and all backend CCcam instances. Every incoming connection hits the proxy first, which routes it to a backend based on load, health status, or sticky rules. This gives visibility and control.

When Single-Server CCcam Becomes a Bottleneck

Watch for these signs: CPU hitting 90%+ under normal load, connection timeout errors in client logs, ECM response times degrading during peak hours, or users reporting channels freezing when others stream.

At that point, adding more CPU won't help—you've hit the connection ceiling. You need to spread load across multiple servers.

Impact on Card Sharing Stability and Client Connection Quality

Unbalanced load causes cascading failures. One slow client hammering a single card can block ECM requests for everyone else on that card. Distribute load and you compartmentalize the problem—other clients stay unaffected.

Stability improves because a single server going down only impacts a fraction of users, not everyone. Planned maintenance becomes feasible: gracefully drain one server, restart it, bring it back online while others serve traffic.

Common Misconceptions About Load Balancing in CCcam Environments

Myth 1: More servers always means faster speeds. Wrong. If each server has weak cards or high latency to the card source, adding servers just spreads the slow problem wider.

Myth 2: Load balancing is automatic. It's not. You have to configure it—either in client configs or via a proxy.

Myth 3: DNS round-robin works great for CCcam. It doesn't. DNS caches at the client level for minutes or hours, so all connections from one user still hit the same server. Round-robin only helps if different users resolve at different times.

Myth 4: A balancer can fix a broken card setup. If your cards can't handle the throughput, balancing just spreads the failure across more servers.

Load Balancing Architectures for CCcam

There are five practical ways to architect CCcam server load balancing. Most setups use one of the first three.

Reverse Proxy Approach (Nginx, HAProxy, Varnish)

A reverse proxy sits on port 12000 (or any public port) and listens for incoming client connections. It forwards each connection to a backend CCcam instance (running on port 12001, 12002, etc., either on the same box or different servers). The client only knows about the proxy's IP and port.

This is powerful because the proxy sees all traffic, enforces connection limits per backend, performs active health checks (probing backends every 10 seconds to see if they're alive), and can redistribute traffic if a backend is slow or dead.

The trade-off: the proxy itself becomes a single point of failure. If it crashes, all clients lose connectivity, even if all backends are fine. You'd need dual proxies with IP failover (keepalived) to fix that.

Client-Side Load Balancing (Multiple Server Addresses in cclient Config)

Each user's client lists multiple CCcam servers in its config. The client tries the first one. If that fails (timeout or refused connection), it tries the second.

Zero infrastructure needed—no proxy to manage. But traffic distribution is terrible. All clients hammer server 1 until server 1 fails. This approach scales to ~100 users but breaks down beyond that.

Some client versions support randomization (connecting to a random server from the list on startup), which spreads initial load better. But once connected, the client stays on that server until forced to fail over.

DNS Round-Robin Method and Its Limitations

Point clients to a DNS name that resolves to multiple IPs (e.g., cccam.example.com → 192.168.1.10, 192.168.1.11, 192.168.1.12). DNS returns all three IPs, and clients pick one.

In theory, load spreads evenly. In practice, DNS answers are cached. Your client might resolve once and reuse that cached IP for hours. Meanwhile, other clients resolve at different times and hit different IPs by chance. You end up with random distribution, not balanced.

TTL (time-to-live) tuning helps: set DNS TTL to 10–30 seconds so caches refresh frequently. But this increases DNS query load and doesn't guarantee distribution.

Skip this approach for CCcam. It's unreliable.

Dedicated CCcam Proxy/Gateway Solutions

Some admins write custom Python or bash scripts that act as a proxy layer. These can be more tailored to CCcam protocol specifics than generic proxies.

Example: a Python script listens on port 12000, accepts incoming client connections, reads the client's request, decides which backend to route to based on current load, proxies the request, and returns the response.

Benefit: you control the exact logic. Drawback: it's custom code—debugging, testing, and maintenance fall on you.

For most admins, nginx or HAProxy is simpler and battle-tested.

Hybrid Approaches Combining Proxy + Client Failover

Best practice for large setups: use a proxy as the primary entry point (clients point to proxy IP), but also configure clients with a fallback list of backend IPs (in case proxy itself fails).

Clients hit proxy → proxy distributes to backends. If proxy dies, clients can reconnect directly to a backend IP from their fallback list.

This adds complexity but eliminates the single point of failure problem.

Configuring Nginx/HAProxy as CCcam Load Balancer

Let's build a real CCcam server load balancing setup with nginx. We'll have three CCcam backends (ports 12001, 12002, 12003) and nginx as the public-facing proxy on port 12000.

Basic Nginx Upstream Configuration for CCcam Protocol

Open your nginx config (typically /etc/nginx/nginx.conf or a site config in /etc/nginx/sites-enabled/). Add this upstream block:

upstream cccam_backends { least_conn; server 192.168.1.10:12001 weight=1 max_fails=3 fail_timeout=30s; server 192.168.1.11:12002 weight=1 max_fails=3 fail_timeout=30s; server 192.168.1.12:12003 weight=1 max_fails=3 fail_timeout=30s;
}
server { listen 12000; proxy_pass cccam_backends; proxy_connect_timeout 10s; proxy_timeout 300s;
}

least_conn tells nginx to route new connections to the backend with the fewest active connections. This is better than simple round-robin for stateful protocols like CCcam.

max_fails=3 fail_timeout=30s means: if a backend fails 3 connection attempts in 30 seconds, mark it as down for 30 seconds and stop sending traffic to it.

proxy_timeout 300s is critical—CCcam connections are long-lived (users watch TV for hours). Don't let nginx kill connections after a few seconds. 300 seconds is reasonable; adjust based on your network latency.

Reload nginx: nginx -s reload. Check syntax first: nginx -t.

HAProxy Backend Pool Setup with Health Checks

HAProxy is more feature-rich for protocol-specific balancing. Here's a basic config (/etc/haproxy/haproxy.cfg):

global maxconn 10000 log /dev/log local0 chroot /var/lib/haproxy stats socket /run/haproxy/admin.sock mode 660 level admin stats timeout 30s daemon
defaults log global mode tcp maxconn 5000 timeout connect 10s timeout client 300s timeout server 300s
frontend cccam_in bind *:12000 default_backend cccam_servers
backend cccam_servers balance leastconn option tcp-check tcp-check connect port 12001 server backend1 192.168.1.10:12001 check inter 10s fall 3 rise 2 weight 1 maxconn 1000 server backend2 192.168.1.11:12002 check inter 10s fall 3 rise 2 weight 1 maxconn 1000 server backend3 192.168.1.12:12003 check inter 10s fall 3 rise 2 weight 1 maxconn 1000

balance leastconn uses the same strategy as nginx's least_conn.

check inter 10s fall 3 rise 2 means: probe each backend every 10 seconds. If 3 probes fail, mark it down. If 2 consecutive probes succeed, mark it back up. This detects failures in 20–30 seconds.

maxconn 1000 limits connections to each backend to 1000. If a backend hits that ceiling, HAProxy queues new connections until one closes. Adjust based on your CCcam server's capacity.

Reload: systemctl reload haproxy. Monitor in real-time: echo "show stat" | socat - /run/haproxy/admin.sock (if you configured the stats socket).

Connection Persistence and Session Stickiness Considerations

CCcam is stateful. When a client connects and authenticates, the CCcam server builds a session with that user's credentials and card assignments. If the connection moves to a different backend mid-session, the client loses that state and has to re-authenticate.

This is why sticky sessions matter. Once a client connects to backend 1, subsequent connections from that client should go to backend 1 (until backend 1 fails, then fail over to another).

In nginx, enable sticky sessions with ip_hash:

upstream cccam_backends { ip_hash; server 192.168.1.10:12001; server 192.168.1.11:12002; server 192.168.1.12:12003;
}

ip_hash uses the client's IP to determine which backend receives that client's connections. All connections from the same IP consistently hit the same backend.

In HAProxy, use source-based stickiness:

backend cccam_servers balance source server backend1 192.168.1.10:12001 check inter 10s fall 3 rise 2 server backend2 192.168.1.11:12002 check inter 10s fall 3 rise 2 server backend3 192.168.1.12:12003 check inter 10s fall 3 rise 2

balance source uses source IP as the hash key, same as nginx's ip_hash.

Trade-off: sticky sessions reduce true load balancing (one chatty client staying on one backend), but they're necessary for CCcam's stateful protocol. Accept this limitation.

Weight Distribution (Unequal Server Capacity Handling)

If backend 1 has 4 cards and backend 2 has 8 cards, don't give them equal weight. Set backend 2's weight higher to send it more traffic.

Nginx syntax:

upstream cccam_backends { ip_hash; server 192.168.1.10:12001 weight=1; server 192.168.1.11:12002 weight=2; server 192.168.1.12:12003 weight=1;
}

This tells nginx: for every 1 connection sent to backend 1, send 2 to backend 2, and 1 to backend 3. Combined traffic ratio is 1:2:1.

HAProxy syntax (in the server line):

server backend2 192.168.1.11:12002 check inter 10s fall 3 rise 2 weight 2 maxconn 2000

Note: also increased maxconn to 2000 for the heavier server.

How to calculate weights? Start with capacity ratios. If backend 2 has twice the CPU and twice the cards, try weight 2. Monitor for 24 hours. Check logs to see actual connection distribution. If backend 2 is still undersaturated, bump weight to 3. This is trial-and-error—there's no formula.

Timeout and Connection Limits Tuning

Timeouts are critical. CCcam clients may sit idle (watching TV, not pulling ECMs) for hours. Don't set idle timeouts below 30 minutes.

In nginx:

server { listen 12000; proxy_pass cccam_backends; proxy_connect_timeout 10s; proxy_send_timeout 300s; proxy_read_timeout 300s;
}

proxy_connect_timeout: how long to wait when opening a connection to a backend (10s is reasonable).

proxy_read_timeout and proxy_send_timeout: how long to wait for a backend to respond before considering the connection dead. 300s (5 minutes) prevents killing idle connections. Increase to 1800s (30 minutes) if you want more tolerance.

Connection limits (file descriptors): Linux limits open file descriptors per process to 1024 by default. Nginx needs 2 file descriptors per proxied connection (one to client, one to backend). At 500 clients, you're at ~1000 file descriptors—hitting the limit.

Increase the limit in nginx config:

worker_processes auto;
worker_rlimit_nofile 65536;

Check current limits: ulimit -n shows per-shell limit, cat /proc/sys/fs/file-max shows system-wide limit. Set permanently in /etc/security/limits.conf:

nginx soft nofile 65536
nginx hard nofile 65536

Reload: systemctl restart nginx.

Monitoring and Logging Load Balancer Traffic

Enable access logs in nginx to see traffic patterns:

access_log /var/log/nginx/cccam_access.log;
error_log /var/log/nginx/cccam_error.log warn;

Parse logs to see which backend is receiving traffic. Example: count connections per backend IP:

tail -f /var/log/nginx/cccam_access.log | awk '{print $3}' | sort | uniq -c

This shows how many log entries (connections/requests) hit each backend IP.

For HAProxy, logs go to syslog. Check them:

tail -f /var/log/syslog | grep haproxy

Monitor real-time stats with HAProxy's web UI (optional config) or command line:

echo "show stat" | socat - /run/haproxy/admin.sock | column -t -s,

This outputs backend status, active connections, bytes, and health check results.

Client-Side Load Balancing Configuration

If you're not deploying a proxy, you can still distribute load by configuring clients with multiple servers. It's cruder but requires no infrastructure.

Adding Multiple Server Entries to cclient.conf

The client config file (typically /etc/CCcam/cclient.conf on Linux boxes or config in the client app) lists CCcam servers. Standard format:

CServer = server.example.com 12000 username password
CServer = 192.168.1.10 12001 username1 password1
CServer = 192.168.1.11 12002 username2 password2
CServer = 192.168.1.12 12003 username3 password3

Each line is a server entry. The client reads them in order. On startup, it tries to connect to the first server. If that fails (timeout or refused connection), it tries the next.

Once connected to a server, the client sticks with it. Reconnection only happens on network failure or user restart.

Client-Side Failover Ordering and Priority

The order matters. Put your fastest/most reliable server first, so clients prefer it. Put backups last.

Some client versions don't honor the order—they randomly pick from the list on each restart. Check your client's documentation or source code.

If your client supports it, you can also specify priority or weight per server (syntax varies by client type).

Randomization vs. Sequential Server Selection

Sequential selection: try server 1, if it fails try server 2, etc. This is the default. All clients will land on server 1 until it dies, then cascade to server 2. Poor load distribution.

Randomization: on each client restart, pick a random server from the list. This spreads initial load better. But it's still not true balancing—once connected, the client stays on that server.

If your client supports it, enable randomization. It helps, but expect 80% of clients on your fastest server and 20% spread across others.

Impact on Card Sharing Performance Metrics

Unbalanced client-side distribution degrades performance under load. If 80 clients pile onto one server and 20 spread across two others, the heavily-loaded server becomes slow for everyone on it, while others are underutilized.

You'll see uneven ECM response times: some clients report 100ms latency, others report 1000ms, all because they're on different servers with different load levels.

This is why client-side balancing doesn't scale well beyond ~100 users.

Updating Multiple Servers Without Client Interruption

If you need to update cclient.conf (adding/removing servers), push the new config to all clients. Methods:

1. Direct file copy (if you control the client machines): scp cclient.conf user@clientip:/etc/CCcam/.

2. Configuration server: set up a simple HTTP server that serves the config. Clients periodically fetch it. Requires client support for external config URLs (not all CCcam clients support this).

3. Documentation: tell users to manually update their config files.

When updating, include both the old and new server entries for 24 hours, then drop the old ones. This prevents clients from losing connectivity during the transition.

Monitoring and Troubleshooting Load Balanced CCcam

A balanced setup only stays balanced if you monitor it and fix problems as they emerge.

Health Check Strategies (Ping, Connection Probes, ECM Timeout Monitoring)

Simple TCP check: proxy opens a connection to the backend's port and closes it. If the connection succeeds, backend is alive. This detects outright crashes but misses performance degradation (slow backend, ECM timeouts, hung processes).

Better approach: actively monitor ECM response times. Each CCcam backend logs ECM hits and response times. Parse those logs to calculate average latency per backend over a 5-minute window. If a backend's latency exceeds a threshold, mark it as degraded and reduce its weight or take it offline.

Even better: implement a custom health check script that connects to each backend, sends a test ECM request, measures response time, and reports status.

Example bash script (very basic):

#!/bin/bash
BACKENDS=("192.168.1.10:12001" "192.168.1.11:12002" "192.168.1.12:12003")
for backend in "${BACKENDS[@]}"; do host=$(echo $backend | cut -d: -f1) port=$(echo $backend | cut -d: -f2) timeout 3 bash -c "cat < /dev/null > /dev/tcp/$host/$port" 2>/dev/null if [ $? -eq 0 ]; then echo "$backend: UP" else echo "$backend: DOWN" fi
done

Run this every 10 seconds via cron or a daemon loop. Parse the output and adjust proxy config based on results.

Identifying Overloaded Backend Servers in Logs

Each CCcam server logs its activity. Check the main log (often /etc/CCcam/cccam.log or journalctl for systemd services):

tail -f /etc/CCcam/cccam.log | grep ECM

Look for patterns: ECM response time increasing, error messages about card timeouts or reader disconnects, or connection limits being hit.

Count active connections on a backend (from the backend server itself):

netstat -an | grep :12001 | grep ESTABLISHED | wc -l

Replace 12001 with the backend's port. This shows concurrent connections. If it's consistently at your maxconn limit (e.g., 1000), the backend is saturated.

More detailed socket info:

ss -tnp | grep :12001

Lists all connections on port 12001 with process info. Look for connections in CLOSE_WAIT state (connections stuck, not closing properly—a sign of hung CCcam processes).

Uneven Connection Distribution Causes and Fixes

If your proxy shows 90% of connections on one backend and 10% on others, causes include:

1. Weight misconfiguration: check proxy config and verify weights match your intended ratio. Typo example: weight=0 accidentally disables a backend.

2. Sticky sessions broken: if using source IP hashing but clients all come from the same IP (NAT, corporate firewall), all traffic lands on one backend. Fix: switch to round-robin or least-conn (but then client session state will scatter—trade-off).

3. One backend is much faster: if backend 1 is on newer hardware and backend 2 is older, clients naturally prefer backend 1 (lower latency, faster responses). Reduce weight on backend 1 to force some load to backend 2, or upgrade backend 2.

4. Health checks think one backend is down: check proxy logs to see if any backends are marked as down due to failed health probes. Even one probe failure can trigger mark-down. Fix: loosen health check thresholds (increase fail_timeout or rise/fall parameters).

5. Client-side config not updated: if you changed weights in the proxy but clients still have hardcoded server list, client-side failover overrides proxy balancing. Fix: update client configs.

Detecting Connection Leaks and Hung Sessions

A connection leak is when connections are opened but never properly closed. They sit in CLOSE_WAIT or TIME_WAIT state, consuming system resources.

Watch for: backend server's connection count steadily increasing without decreasing, even when load is stable. After 1 week, it grows from 100 to 500 connections (no user growth). That's a leak.

Diagnosis:

ss -tnp | grep :12001 | grep CLOSE_WAIT | wc -l

Count CLOSE_WAIT connections. If this grows over time, there's a leak (CCcam process is not closing sockets properly, or client drops connection without proper close handshake).

Temporary fix: restart the backend. Permanent fix: investigate CCcam logs for errors or patches for connection handling bugs. Contact the CCcam provider or check community forums for known issues.

Hung sessions: connections that are open but stuck (client sent data, backend never responds). From the backend's view, these are ESTABLISHED connections consuming a slot but making no progress.

Monitor for ECM timeout errors in logs. If they're frequent, it suggests backends are hanging on card reads. Increase timeouts in proxy config or add a connection idle timeout (close connections that send no data for X minutes).

Metrics to Track: Response Times, ECM Success Rate, Connection Count per Server

Key metrics:

ECM Response Time: time from client request to backend response. Parse CCcam logs: each ECM entry logs a timestamp and response time. Calculate average per 5-minute window per backend. Alert if average exceeds 500ms.

Connection Count: run netstat -an | grep :port | grep ESTABLISHED | wc -l every minute and graph it. Watch for steady growth (leak) or spike to maxconn (saturation).

ECM Success Rate: percentage of ECM requests that returned a valid response (vs. timeout or error). Parse logs: count "ECM found" vs. "ECM timeout" messages. Target >95%. <95% means cards are slow or network latency is high.

Backend Availability: percentage of time each backend was marked as up (not down due to health check failures). Graph this over days/weeks. If a backend drops to 50% availability, investigate why health checks are failing.

Tool suggestion: use Prometheus (free, open-source) to scrape metrics from a simple Python/bash exporter script you write. Visualize with Grafana. Or use a simpler approach: bash script that logs metrics to CSV, then graph with gnuplot.

Tools for Real-Time Load Monitoring (netstat, ss, Custom Scripts)

netstat -an | grep :port shows all connections on a port. Add filters:

netstat -an | grep ESTABLISHED | grep :12001 | wc -l # count established on port 12001
netstat -an | grep CLOSE_WAIT | grep :12001 | wc -l # count stuck connections

ss -tnp | grep :port | sort -k4 -rn shows connections sorted by state, useful for finding which IPs are connected.

lsof -i :port lists open files (including sockets) on a port with process info: lsof -i :12001 | tail -5 shows the last 5 connections.

Build a monitoring script in bash/Python that runs every 60 seconds and logs metrics to a file or sends them to a monitoring service. Example shell loop:

while true; do echo "$(date): $(netstat -an | grep :12001 | grep ESTABLISHED | wc -l) connections" sleep 60
done > /var/log/cccam_monitor.log

Then graph or alert based on thresholds.

Weight-Based Distribution for Heterogeneous Servers

Real setups don't have identical servers. You might have one newer 4-core box and one older 2-core box. Or one with 8 cards, one with 4.

Why Servers Have Different Capacity (CPU, Card Count, Network)

Hardware ages. You add servers incrementally, buying what's available. Network connectivity differs (one server is 10Mbps away from the card source, another is 100ms away). Card assignments are uneven (one server gets fast cards, another gets slow ones).

Equal weight (1:1) will saturate the weaker server while underusing the stronger one.

Setting Weights in Nginx and HAProxy

Nginx (in upstream block):

upstream cccam_backends { ip_hash; server 192.168.1.10:12001 weight=1; # older 2-core server 192.168.1.11:12002 weight=2; # newer 4-core
}

HAProxy (in server line, backend section):

backend cccam_servers balance leastconn server backend1 192.168.1.10:12001 weight=1 maxconn 500 server backend2 192.168.1.11:12002 weight=2 maxconn 1000

Note: also adjust maxconn proportionally. If weight is 2x, maxconn should be 2x.

Calculating Optimal Weight Ratios

Start with capacity estimation:

CPU: count cores. 4 cores = roughly 2x throughput of 2 cores. Weight ratio = 2:1.

Cards: count card count. 8 cards = 2x cards of 4 cards (if cards are similar speed). Weight ratio = 2:1.

Combine: if server B has 2x cores and 2x cards vs. server A, weight ratio = 2:1.

Network latency: if server A is on a 10ms LAN and server B is on a 100ms WAN, server A can process ECMs faster. Reduce server B's weight slightly (e.g., 1.5:1 instead of 2:1).

Formula-ish:

weight_B / weight_A = (cores_B / cores_A) * (cards_B / cards_A) * (latency_A / latency_B)

Then adjust empirically.

Adjusting Weights Based on Real-World Performance

Deploy with estimated weights. Monitor for 24 hours. Check proxy logs to see actual connection distribution:

tail -100000 /var/log/nginx/cccam_access.log | awk '{print $3}' | sort | uniq -c

If distribution is 1000 connections on server A and 3000 on server B, but you set weight 1:2, the proxy is working correctly. Check if server B is handling it (CPU, ECM latency still good). If yes, weights are right. If server B is struggling, reduce its weight to 1.5.

If distribution is 2000 on A and 1000 on B with weight 1:2, the weights aren't being honored—check proxy config or restart proxy to reload config.

Monitor ECM response times per backend. If both backends have identical latency despite unequal load, weights might be too equal (increase spread). If one backend's latency is much higher despite lower load, it might have slower cards or network—reduce its weight.

Common Mistakes: Equal Weight for Unequal Hardware

The biggest mistake: deploying a new 16-core server alongside an old 8-core one and setting both to weight=1. The old server gets hammered while the new one is 50% idle.

Another: ignoring latency. A server close to the card source (5ms) should get more weight than one far away (50ms), even if both have the same cores/cards.

Third: not re-adjusting weights when hardware changes. You upgrade server A from 4 cores to 8 cores but forget to update its weight from 1 to 2. It's now underutilized.

Failover and Redundancy Patterns

Load balancing isn't just about distribution—it's about surviving server failures.

Active-Passive vs. Active-Active Failover Modes

Active-Passive: one server is primary (handles all traffic), others are backup (idle). If primary fails, traffic switches to a backup. Simple, but you're paying for hardware that sits unused.

Typical setup: server A (active) and server B (passive). All clients/proxy route to A. Monitor server A. If it dies, admin manually or automatically (via script) redirects traffic to B. Clients reconnect, experience brief interruption, resume on B.

Active-Active: all servers are online and serving traffic simultaneously. No idle backup. If any server dies, remaining servers handle the lost traffic. More efficient resource use.

Trade-off: CCcam is stateful (session tied to server), so true active-active requires either session replication (complex) or sticky sessions (client always returns to same server, so failover loses state).

Most deployments use active-active with sticky sessions and graceful failover: clients accept brief reconnection if their server fails.

Health Check Intervals and Failure Detection Time

Proxy health checks run every N seconds (e.g., 10s). If a check fails, it's marked as one failure. After M consecutive failures (e.g., 3), the backend is marked down and removed from rotation. Minimum detection time = check interval * M = 10s * 3 = 30 seconds.

Fast detection: set check interval to 5s and fail threshold to 2. Detection time = 10s. Clients experience 10s downtime before failover.

Trade-off: frequent checks increase load on backends and false positives (temp network hiccup marks backend as down incorrectly).

Conservative: interval 30s, threshold 3. Detection time = 90s. More tolerant of network blips, but user experiences 90s downtime during real failure.

Recommendation: start at 10s interval, 3 failures. Monitor for false positives. If few false positives, reduce to 5s interval, 2 failures.

Graceful Server Shutdown Without Dropping Clients

If you need to restart a backend, don't just kill it. Drain it gracefully:

1. Set its weight to 0 in the proxy. This stops new connections from going to it, but existing ones stay.

2. Wait for existing connections to close (watch connection count drop via netstat). Typically 5–30 minutes depending on user behavior.

3. Once connection count reaches 0, stop the CCcam process.

4. Do maintenance (update, restart, etc.).

5. Start CCcam. Restore weight to normal value.

Nginx: edit config, set weight to 0, reload: nginx -s reload. Monitor: watch -n 1 'netstat -an | grep :12001 | grep ESTABLISHED | wc -l'. Once 0, restart CCcam.

HAProxy: use command line admin socket: echo "set server cccam_servers/backend1 weight 0" | socat - /run/haproxy/admin.sock. Then proceed as above. No reload needed.

Reconnection Behavior After Server Recovery

When a downed backend comes back online:

If clients were forcefully disconnected from it, they'll reconnect to the proxy/load balancer (not the specific backend). The load balancer will route them based on current balancing rules. They'll probably end up on a different backend (unless sticky sessions are enabled and the old backend is their sticky target).

If clients were on the backend when it went down, they'll experience a connection drop and have to reconnect. Better behavior: use graceful drain (weight to 0) so clients finish naturally and reconnect, rather than abrupt kill.

Health check recovery: once a backend is brought back online and the first health check passes, proxy marks it as "up" and adds it back to rotation. Second and subsequent checks must also pass (based on the "rise" parameter, e.g., rise=2 means 2 consecutive passes). After rise passes, it's fully active.

Backup Server Configuration and Testing

For high-availability setups, also configure a backup proxy. If your primary proxy (nginx) dies, all client connections are lost even though backends are fine.

Dual proxy setup with keepalived (virtual IP failover):

Two nginx instances (nginx-primary and nginx-backup) on different servers share a virtual IP (e.g., 192.168.1.200). Clients connect to the virtual IP. Keepalived monitors the primary nginx process. If it dies, keepalived fails over the virtual IP to the backup nginx. Clients automatically redirect to backup (within a few seconds).

Setup (rough outline):

1. Install keepalived on both servers: apt-get install keepalived.

2. Configure /etc/keepalived/keepalived.conf on the primary to monitor nginx and advertise the virtual IP.

3. Configure the backup similarly, with lower priority.

4. Both run identical nginx configs.

5. Start keepalived on both. The primary takes the virtual IP. If primary nginx crashes, keepalived detects it and shifts IP to backup.

Testing: kill the primary nginx while monitoring the virtual IP (ping -c 1000 192.168.1.200 and watch for brief gap). When nginx dies, keepalived will move the IP to backup within ~3 seconds. Clients see a brief ping loss, then reconnect to the backup.

This adds complexity but eliminates the proxy as a single point of failure.

FAQ