Hi everyone,
I’m running NextPVR (version 7.0.0.241105) in a Docker container behind a Caddy (version v2.9.1) reverse proxy for SSL termination. Everything works fine initially, but I’m encountering a persistent issue related to session handling. Specifically, I’m seeing the following errors in the NextPVR logs:
The problem occurs when using the Web Player in Chrome.
The Problem
It appears that Caddy is changing the source port for requests during a session, which causes NextPVR to treat them as different sessions and reject them.
Question
I’m looking for advice on the following:
• Has anyone encountered similar issues when running NextPVR behind a reverse proxy like Caddy?
• Is there a way to configure NextPVR to ignore the source port when validating sessions?
• What’s the recommended way to configure Caddy to prevent this issue with session handling?
• Are there any tips or workarounds to ensure stable session management in this setup?
Any suggestions would be greatly appreciated.
Environment Details
• NextPVR Version: 7.0.0.241105
• Caddy Version: v2.9.1
• Architecture: x64
• Browser: Chrome
• Docker Setup:
Caddy Configuration
Docker Compose Configuration
I’m running NextPVR (version 7.0.0.241105) in a Docker container behind a Caddy (version v2.9.1) reverse proxy for SSL termination. Everything works fine initially, but I’m encountering a persistent issue related to session handling. Specifically, I’m seeing the following errors in the NextPVR logs:
Code:
2025-01-10 17:00:32.152 [DEBUG][67] Got request [100.64.0.5:61473]: /services/service (channel.list)
2025-01-10 17:00:32.152 [DEBUG][67] parameters:
2025-01-10 17:00:32.152 [DEBUG][60] Got request [100.64.0.5:61473]: /services/service (channel.groups)
2025-01-10 17:00:32.152 [DEBUG][63] Got request [100.64.0.5:61473]: /services/service (recording.list)
2025-01-10 17:00:32.152 [DEBUG][67] method: channel.list
2025-01-10 17:00:32.152 [DEBUG][67] format: json
2025-01-10 17:00:32.152 [DEBUG][67] sid: a948900b-f1d6-4b77-811e-92481b154fb7
2025-01-10 17:00:32.152 [DEBUG][67] client_ip: 100.64.0.5:61473
2025-01-10 17:00:32.152 [DEBUG][67] client_local: false
2025-01-10 17:00:32.152 [DEBUG][67] user_agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
Code:
2025-01-10 17:00:32.152 [DEBUG][67] host_callback: ...
2025-01-10 17:00:32.152 [ERROR][67] Rejecting sid. Different IP address. (100.64.0.5:61473 vs 100.64.0.5:61411)
2025-01-10 17:00:32.152 [DEBUG][63] parameters:
2025-01-10 17:00:32.152 [DEBUG][67] {"stat":"Failed","code":8,"msg":"Invalid Session."}
The problem occurs when using the Web Player in Chrome.
The Problem
It appears that Caddy is changing the source port for requests during a session, which causes NextPVR to treat them as different sessions and reject them.
Question
I’m looking for advice on the following:
• Has anyone encountered similar issues when running NextPVR behind a reverse proxy like Caddy?
• Is there a way to configure NextPVR to ignore the source port when validating sessions?
• What’s the recommended way to configure Caddy to prevent this issue with session handling?
• Are there any tips or workarounds to ensure stable session management in this setup?
Any suggestions would be greatly appreciated.
Environment Details
• NextPVR Version: 7.0.0.241105
• Caddy Version: v2.9.1
• Architecture: x64
• Browser: Chrome
• Docker Setup:
- Caddy and NextPVR are running in separate containers.
- Docker Compose is being used for orchestration.
Caddy Configuration
Code:
@nextPvrHost {
host mtv.fnc.tld.de
}
reverse_proxy @nextPvrHost mtv:8866 {
header_up Host {http.request.host}
header_up X-Real-IP {http.request.remote}
}
Docker Compose Configuration
Code:
networks:
default:
enable_ipv6: true
services:
nextpvr:
image: nextpvr/nextpvr_amd64:latest
container_name: mtv
volumes:
- /home/user/container/data/nextpvr/config:/config
- /home/user/container/data/nextpvr/videos:/recordings
- /home/user/container/data/nextpvr/videos:/buffer
expose:
- "8866" # Exposes port 8866 for access within the Docker network
restart: unless-stopped
group_add:
- "993" # Change this to match your "render" host group id and remove this comment
devices:
- /dev/dri/renderD128:/dev/dri/renderD128