Privoxy is restarted every self-heal interval when WEBPROXY_BIND_ADDRESS=0.0.0.0 on a multi-network container #3032

Is there a pinned issue for this?

• I have read the pinned issues and could not find my issue

Is there an existing or similar issue/discussion for this?

• I have searched the existing issues
• I have searched the existing discussions

Is there any comment in the documentation for this?

• I have read the documentation, especially the FAQ and Troubleshooting parts

Is this related to a provider?

• I have checked the provider repo for issues
• My issue is NOT related to a provider

Are you using the latest release?

• I am using the latest release

Have you tried using the dev branch latest?

• I have tried using dev branch

Docker run config used

services:
transmission-openvpn:
image: haugene/transmission-openvpn:latest # image label: 5.4.1
cap_add: [NET_ADMIN]
networks:
networka:
# static client-facing proxy address; clients use vpn-proxy:8118
aliases: [vpn-proxy]
networkb: {}
networkc: {}
volumes:
- /redacted/openvpn:/etc/openvpn/custom:ro
- /redacted/config:/config
# Contains: listen-address 0.0.0.0:8118
- /redacted/privoxy.conf:/etc/privoxy/config:ro
environment:
OPENVPN_PROVIDER: custom
OPENVPN_CONFIG: REDACTED
OPENVPN_USERNAME: REDACTED
OPENVPN_PASSWORD: REDACTED
LOCAL_NETWORK: 172.0.0.0/8
WEBPROXY_ENABLED: "true"
WEBPROXY_PORT: "8118"
WEBPROXY_BIND_ADDRESS: 0.0.0.0

Current Behavior

With WEBPROXY_ENABLED=true and Privoxy configured to listen on 0.0.0.0:8118, the bundled /etc/scripts/healthcheck.sh compares the literal listen-address value to the IPv4 address of eth0:

proxy_ip=$(grep -i "^listen-address" /etc/privoxy/config | awk -F ' ' '{print $2}' | awk -F ':' '{print $1}')
cont_ip=$(ip -j a show dev eth0 | jq -r .[].addr_info[].local)
if [[ ${proxy_ip} != ${cont_ip} ]]; then
  pkill privoxy || true
  /opt/privoxy/start.sh
fi

0.0.0.0 is a wildcard bind address, not the literal address of eth0, so the comparison is always unequal. selfheal.sh runs this check every SELFHEAL_INTERVAL (60 seconds by default). Consequently it kills and restarts an otherwise healthy Privoxy on every cycle.

On a multi-network container, binding Privoxy to eth0 is not a workaround: proxy clients may reach a different attached network, and Docker may assign a different network to eth0 after a recreate. In my setup that restart drops long-lived HTTP CONNECT tunnels, causing all IRC clients using the proxy to disconnect and reconnect together every roughly 60–75 seconds. Short HTTP requests tend to retry and can make the proxy look healthy.

The healthcheck output itself normally does not appear in docker logs, since selfheal.sh invokes it with stdout redirected to /dev/null.

Expected Behavior

0.0.0.0 should be accepted as a valid wildcard WEBPROXY_BIND_ADDRESS and a running Privoxy should not be restarted merely because that bind value differs from eth0.

More generally, the healthcheck should not assume that eth0 is the desired or client-facing interface in a multi-network container. It should still restart Privoxy when its process is actually absent.

How have you tried to solve the problem?

1. Confirmed that Privoxy was configured with listen-address 0.0.0.0:8118.
2. Confirmed the container had multiple interfaces and that eth0 was not a stable proxy-client interface across recreates.
3. Traced the 60-second cadence to the upstream selfheal.sh invocation of healthcheck.sh and its unconditional restart on an address mismatch.
4. Verified that direct connections survived while proxied long-lived connections dropped in lockstep.
5. As a local workaround, I first bind-mounted a minimal copy of healthcheck.sh. I then changed that local override to exactly match the proposed upstream fix: restart Privoxy when its process is absent, but do not restart a running Privoxy when its bind address is 0.0.0.0. The container stayed healthy, Privoxy remained on the same PID, and the IRC connections stayed stable across multiple scheduled self-heal cycles.

Log output

Relevant configuration and observed interface state (addresses redacted):

$ grep -i '^listen-address' /etc/privoxy/config
listen-address  0.0.0.0:8118

$ ip -j a show dev eth0 ...
172.x.x.x

# proxy clients use the separate media-network address/alias
vpn-proxy:8118 -> 172.x.x.x:8118

The current upstream code is the decisive diagnostic output: when the two values above differ, it calls pkill privoxy followed by /opt/privoxy/start.sh. See the source link below. The periodic diagnostic is otherwise hidden from container logs by selfheal.sh's /dev/null redirect.

HW/SW Environment

- OS: Ubuntu 22.04.5 LTS, kernel 5.15.0-186-generic
- Docker Engine: 29.5.2
- Docker Compose: v5.1.4
- Image: `haugene/transmission-openvpn:latest`, image label `5.4.1` (`4f22965b245df2d73c8a113e1d64955abf9fc0f3`)

Anything else?

This appears to be the interaction left open by two earlier upstream changes:

• PR #2494 introduced the address-mismatch restart and states that multiple listening addresses/interfaces were out of scope.
• PR #2812 added WEBPROXY_BIND_ADDRESS, but only updated Privoxy startup/configuration, not the healthcheck comparison.
• Current healthcheck source and Privoxy startup source.

Suggested implementation: treat 0.0.0.0 as a valid wildcard, or replace the address equality test with a process/listening-socket health check that does not hard-code eth0.