Describe the bug
BUZZ_PAIR_RELAY_BIND_ADDR defaults to 127.0.0.1:5000 (crates/buzz-pair-relay/src/main.rs) and the Helm service uses port 5000 (deploy/charts/buzz/values.yaml, pairingRelay.service.port).
On macOS, ControlCenter's AirPlay Receiver listens on port 5000 by default. It wins the bind, so the pairing relay is unreachable and AirPlay answers instead, returning:
HTTP/2 403
content-length: 0
x-apple-processingtime: 0
x-apple-requestreceivedtimestamp: 2588051854
A 403 with an empty body reads as an authentication or authorisation failure, so the natural assumption is that pairing is being rejected. It took us a while to work out that the pairing relay was never in the request path at all. The give-away is the x-apple-* headers, which are easy to miss.
Steps to reproduce
On macOS with AirPlay Receiver enabled (the default):
- Run the pairing relay on its default port, e.g.
docker run -p 5000:5000 -e BUZZ_PAIR_RELAY_BIND_ADDR=0.0.0.0:5000 --entrypoint /usr/local/bin/buzz-pair-relay ghcr.io/block/buzz:latest
curl -i http://127.0.0.1:5000/
Result: HTTP 403 with x-apple-processingtime, from AirPlay rather than the pairing relay.
Expected from the pairing relay for a non-WebSocket request: 400, per http_service() in crates/buzz-pair-relay/src/lib.rs, which returns BAD_REQUEST for a non-upgrade request and SERVICE_UNAVAILABLE when full. It never returns 403, so a 403 is always something else answering.
Expected behavior
Either a default bind port that does not collide with a standard macOS service, or a note in the pairing relay docs and Helm values that port 5000 is unusable on macOS. We moved ours to 5300 and it worked immediately.
Version and platform
- Buzz version:
ghcr.io/block/buzz:latest (NIP-11 reports 0.2.1)
- OS: macOS 26.3, arm64, OrbStack
Logs / additional context
lsof -nP -iTCP:5000 -sTCP:LISTEN shows ControlCe holding the port. Anyone self-hosting on a Mac following the upstream defaults will hit this, and the 403 sends you looking at authentication rather than at port binding.
Describe the bug
BUZZ_PAIR_RELAY_BIND_ADDRdefaults to127.0.0.1:5000(crates/buzz-pair-relay/src/main.rs) and the Helm service uses port 5000 (deploy/charts/buzz/values.yaml,pairingRelay.service.port).On macOS, ControlCenter's AirPlay Receiver listens on port 5000 by default. It wins the bind, so the pairing relay is unreachable and AirPlay answers instead, returning:
A 403 with an empty body reads as an authentication or authorisation failure, so the natural assumption is that pairing is being rejected. It took us a while to work out that the pairing relay was never in the request path at all. The give-away is the
x-apple-*headers, which are easy to miss.Steps to reproduce
On macOS with AirPlay Receiver enabled (the default):
docker run -p 5000:5000 -e BUZZ_PAIR_RELAY_BIND_ADDR=0.0.0.0:5000 --entrypoint /usr/local/bin/buzz-pair-relay ghcr.io/block/buzz:latestcurl -i http://127.0.0.1:5000/Result: HTTP 403 with
x-apple-processingtime, from AirPlay rather than the pairing relay.Expected from the pairing relay for a non-WebSocket request: 400, per
http_service()incrates/buzz-pair-relay/src/lib.rs, which returnsBAD_REQUESTfor a non-upgrade request andSERVICE_UNAVAILABLEwhen full. It never returns 403, so a 403 is always something else answering.Expected behavior
Either a default bind port that does not collide with a standard macOS service, or a note in the pairing relay docs and Helm values that port 5000 is unusable on macOS. We moved ours to 5300 and it worked immediately.
Version and platform
ghcr.io/block/buzz:latest(NIP-11 reports 0.2.1)Logs / additional context
lsof -nP -iTCP:5000 -sTCP:LISTENshowsControlCeholding the port. Anyone self-hosting on a Mac following the upstream defaults will hit this, and the 403 sends you looking at authentication rather than at port binding.