Field Report: wxpRelay (app) on macOS — When a Developer Tool Can’t Bind to a Port
Machine: MacBook Pro 14” (M1 Pro)
System: macOS Sonoma 14.4
Environment: running inside my usual OrchardKit dev sandbox
What I wanted to do was simple. Spin up wxpRelay (app) — from the slug it’s clearly some kind of lightweight relay/proxy utility — and forward local traffic from port 8080 to a test service running on another machine in my lab.
Install went smoothly. No Gatekeeper drama, no “damaged” warnings. It launched fine. Clean interface. Minimalist, as most dev tools are.
I configured it to listen on localhost:8080 and forward to a remote endpoint.
Clicked Start.
Immediate error:
“Failed to bind to port.”
No extra explanation. Just that.
First Thought: Port Conflict
Classic mistake number one — assume something else is already using the port.
So I ran:
lsof -i :8080
Nothing. Completely free.
Just in case, I switched to port 9090.
Same error.
That’s when I knew it wasn’t a simple conflict.
Second Thought: Firewall
Maybe macOS firewall was interfering. I checked System Settings → Network → Firewall. It was enabled but set to allow signed apps automatically.
For completeness, I temporarily disabled it.
No change.
Apple’s overview of how macOS firewall behaves is here:
https://support.apple.com/en-us/HT201642
But this didn’t feel like firewall-level blocking. The failure was instant — no timeout, no partial attempt.
Third Attempt: Privileged Ports
I tried port 80 just to see what would happen.
Same error.
That was interesting. Binding to port 80 requires elevated privileges, but 8080 and 9090 absolutely do not. Yet the error was identical.
That pushed me toward something deeper — likely macOS privacy or network entitlements.
Since Ventura and now Sonoma, macOS is stricter about how apps request network and developer-level privileges, especially if they’re distributed outside the Mac App Store.
I checked quarantine status:
xattr -l /Applications/wxpRelay.app
Sure enough: com.apple.quarantine.
Now, quarantine usually affects launch behavior via Gatekeeper, documented here:
https://support.apple.com/en-us/HT202491
But in some cases — especially for network-facing utilities — it can interfere with runtime permission prompts.
So I removed it:
xattr -dr com.apple.quarantine /Applications/wxpRelay.app
Relaunched.
Still couldn’t bind.
The Real Issue
I opened Console and filtered by the app’s process.
That’s where I saw it:
Sandbox: deny(1) network-bind
There it was. The tool was sandboxed and didn’t have permission to bind to a listening socket.
That’s not a firewall issue. That’s an entitlement issue.
Apple’s documentation on app sandboxing explains how network server permissions must be explicitly granted in the app’s entitlements:
https://developer.apple.com/documentation/security/app_sandbox
The binary didn’t request com.apple.security.network.server. Sonoma was enforcing it strictly.
There’s no checkbox in Privacy & Security for that. If the entitlement isn’t present, the OS denies the bind.
I checked whether there was an App Store build that might carry proper sandbox permissions:
https://apps.apple.com/us/search?term=wxpRelay
Didn’t see a clearly official listing under that name. So this appears to be a direct-distribution developer utility.
At this point, I bookmarked this page because it outlines similar macOS behavior for developer tools that fail silently when sandbox network entitlements are missing — especially under newer mac OS systems:
https://deadtriggermod.xyz/developer/11751-wxprelay.html
It matched what I was seeing almost exactly.
What Actually Worked
In this case, there was no magic Terminal flag to fix it.
The solution was using a different build of the tool — specifically a non-sandboxed release provided by the developer. Once I replaced the app bundle with the updated version (which included proper network server entitlement), it bound to port 8080 instantly.
No errors. Relay traffic flowed normally. CPU usage minimal. Stable under sustained requests.
If I Had Known From the Start
I would have:
-
Checked Console immediately for sandbox denial logs
-
Verified entitlements using
codesign -d --entitlements :- -
Skipped firewall debugging entirely
Total time spent troubleshooting: about 1 hour.
Actual fix once identified: 3 minutes (download correct build).
The tool wasn’t broken. macOS wasn’t broken. The sandbox rules were simply doing their job.
On modern macOS, especially Sonoma on Apple Silicon, you can’t assume a network utility is allowed to act like a server just because it launches successfully.
Lesson logged.