When Docker containers restart, they can get new IPs on the bridge
network. HAProxy caches DNS at config load time, so stale IPs cause
503s until config is regenerated.
Added a 'docker_dns' resolvers section pointing to Docker's embedded
DNS (127.0.0.11) with 10s hold time. Backend servers now use
'resolvers docker_dns init-addr last,libc,none' so HAProxy:
- Re-resolves container names every 10 seconds
- Falls back to last known IP if DNS is temporarily unavailable
- Starts even if a backend can't be resolved yet (init-addr none)
This eliminates 503s from container restarts, scaling, and recreation
without requiring a HAProxy config regeneration.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Support wildcard domains (*.domain.tld) in HAProxy config generation
with exact-match ACLs prioritized over wildcard ACLs. Add DNS-01
challenge endpoints that coordinate with certbot via auth/cleanup
hook scripts for wildcard SSL certificate issuance.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Changes:
- Detect SSE via Accept header (text/event-stream) or ?action=stream parameter
- Disable http-server-close to allow long-lived SSE connections
- Enable http-no-delay for immediate event delivery
- Set 1-hour timeouts for SSE support (also fine for normal requests)
- Force Connection: keep-alive for detected SSE requests
Benefits:
- SSE now works automatically without special backend configuration
- Fixes transcription server display disconnection issues
- Normal HTTP requests still work perfectly
- No need for separate SSE-specific backends
Fixes: Server-Sent Events timing out through HAProxy
- Removed all 40X error tracking and rate limiting from HAProxy templates
- Preserved critical IP forwarding headers (X-CLIENT-IP, X-Real-IP, X-Forwarded-For)
- Kept stick table and IP blocking infrastructure for potential future use
- Rate limiting can now be implemented at container level with proper context
This change prevents legitimate developers from being rate-limited during
normal development activities while maintaining proper client IP forwarding
for container-level security and logging.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Remove invalid ACL combination syntax (can't use 'or' to combine ACLs)
- Use multiple http-response lines instead (each line is OR'd together)
- Each line checks specific scan pattern with 404 AND not legitimate assets
- Simplify logic to be HAProxy 3.0 compatible
This fixes the config parsing errors while maintaining the same
detection logic - only counting suspicious script/config 404s, not
missing assets.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Extends the tarpit protection and real IP handling to all backend templates,
ensuring consistent behavior across different backend configurations.
Changes to all backend templates:
- Pass real client IP via X-CLIENT-IP and X-Real-IP headers
- Use var(txn.real_ip) which contains the actual client IP (from proxy headers or direct)
- Add scan attempt detection (400/401/403/404 errors)
- Track suspicious paths (admin panels, config files, etc.)
- Increment error counters for tarpit decisions
Updated templates:
- hap_backend.tpl: Main backend template
- hap_backend_http_check.tpl: Backend with HTTP health checks
- hap_backend_basic.tpl: Minimal backend configuration
Benefits:
- Backend applications receive the real client IP, not proxy IPs
- All backend types now contribute to scan detection
- Consistent security across different backend configurations
- Works seamlessly with Cloudflare and other CDNs
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Corrected the tarpit logic flow to work as intended:
1. Backend tracks 400/401/403/404 error responses via http-response
2. Counter increments AFTER the backend responds with an error
3. Frontend checks counter on SUBSEQUENT requests
4. Tarpit/blocking only applies after error thresholds are reached:
- 5+ errors: Potential scanner (no action yet)
- 15+ errors: Likely scanner (tarpit if also burst traffic)
- 30+ errors: Confirmed scanner (always tarpit)
- 50+ errors: Aggressive scanner (block with 429)
This ensures:
- Normal traffic is never delayed
- First requests always go through normally
- Only clients that accumulate errors get progressively slowed/blocked
- The tarpit is a response to bad behavior, not a preemptive measure
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Implement progressive tarpit delays and threat detection to slow down
attackers scanning for exploits. Features include:
- Stick table to track attacks with 2-hour expiry
- Escalating tarpit delays based on threat level and repeat offenses
- Threat level detection (low/medium/high/critical) based on scan attempts
- Rate-based attack detection for burst/sustained/persistent attacks
- Automatic scan attempt tracking via HTTP error responses (400/401/403/404)
- Detection of suspicious paths (admin panels, config files, etc.)
- Trusted network bypass for local/monitoring systems
- Progressive escalation levels that increase tarpit duration
- Critical threat blocking with 429 status
The system uses HAProxy's built-in tarpit mechanism to delay responses
up to 60 seconds for persistent attackers, effectively slowing down
vulnerability scanners while maintaining service for legitimate users.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
