Describe the bug

Port scanning during network discovery overwhelms service listen queues on target hosts, causing web interfaces to become unresponsive while other services (DNS, SSH) continue working normally.

To Reproduce

Steps to reproduce the behavior:

1. Deploy Scanopy v0.13.3 with default settings using official docker-compose.yml
2. Configure network scan for /24 subnet with ~75 devices including service hosts
3. Start discovery
4. SSH to target host (e.g., Pi-hole) and run: ss -tln | grep :80
5. Observe listen queue overflow: tcp LISTEN 201 200 0.0.0.0:80
6. Attempt to access web interface at http://target-ip/ - connection hangs/times out

Expected behavior

Port scanning should be throttled to avoid overwhelming target services. Web interfaces should remain responsive during discovery, or at minimum, documentation should warn about this behavior.

Screenshots

Terminal output showing listen queue overflow:
ss -tln | grep :80
tcp LISTEN 201 200 0.0.0.0:80 0.0.0.0:*
Environment:

• Scanopy server & daemon version: v0.13.3
• Host: LXC containers on Proxmox VE
• Scanner: LXC running Debian 13 (Trixie) - Target: LXC running Pi-hole (Debian-based)
• OS: Both Debian-based (Docker host: Debian 13 Trixie, Target: Debian with Pi-hole)
• Browser: N/A (affects all browsers, issue is at TCP layer)
• Network: /24 home lab (~75 active devices)

Additional context

Impact on affected target (Pi-hole):

• Web interface (port 80/443) becomes completely unresponsive
• Web interface does not recover automatically - service restart required
• New HTTP/HTTPS connections permanently refused while listen queue remains full
• SSH (port 22) continues working normally
• Backup Pi-hole took over DNS and DHCP when primary became unresponsive

Troubleshooting difficulties:

• No error logs on target host (silent queue overflow)
• DNS/DHCP keep working via failover, masking the severity of the issue
• Service appears "up" via SSH, confusing diagnosis
• Port 53 still listening but not receiving traffic

Root cause:
Rapid TCP SYN packets for port detection fill target service accept queues faster than services can process them. Particularly affects services with small listen backlogs (Pi-hole FTL: backlog 200, common in embedded/IoT devices).

Network topology note:
Both scanner and target are LXC containers on the same Proxmox VE host, communicating via Proxmox bridge. This eliminates physical network latency, making the listen queue overflow issue more severe as packets arrive even faster than they would across physical network infrastructure. Issue would likely also occur (but potentially less severe) when scanning across physical network segments.

Workarounds that work:

Option 1 - Rate limiting on target hosts:

iptables -I INPUT -p tcp -s  --dport 80 -m state --state NEW -m recent --set --name SCANNER
iptables -I INPUT -p tcp -s  --dport 80 -m state --state NEW -m recent --update --seconds 1 --hitcount 5 --name SCANNER -j DROP

Option 2 - Reduce concurrent scans in docker-compose.yml:

SCANOPY_CONCURRENT_SCANS: 50
SCANOPY_ARP_RATE_PPS: 10

Suggestions:

1. Add warning in troubleshooting docs about service overload
2. Add "gentle scan" preset for small networks/IoT devices
3. More conservative defaults for first run
4. Adaptive scanning that throttles when services are slow
5. Setup wizard asking about network size

Similar to documented DAI/switch rate limiting but at application layer.

Logs from daemon:
2026-01-09T07:01:34.678918Z INFO daemon: Scanopy Daemon v0.13.3
2026-01-09T07:01:34.680074Z INFO scanopy::daemon::utils::base: Detected local IP address
No errors in daemon logs - issue is silent on scanning side.

Before submitting

[x] I have reviewed The docs