Field Report: Sing-box (app) on macOS — Why It Wouldn’t Connect Until I Fixed the System, Not the Config
What I wanted to do was simple: install Sing-box (app) from OrchardKit on my MacBook Pro (Intel, macOS Ventura 13.6) and run a local proxy setup for testing network routes. Nothing fancy. Just spin it up, point a couple of clients at it, verify traffic.
Install went fine. Binary downloaded. Moved into /usr/local/bin. Config file ready.
And then it just… wouldn’t connect.
No crash. No obvious error. The process ran, but ports weren’t listening. Clients timed out like nothing existed.
At first I assumed bad config. That’s usually the culprit with tools like this.
Attempt 1 — Blame the JSON
I triple-checked the config. Validated JSON. Compared it to the official examples. Even stripped it down to a minimal inbound/outbound pair.
Still nothing listening on the declared port.
Ran:
lsof -iTCP -sTCP:LISTEN
No sign of the service.
The process showed up in ps aux, but the networking layer wasn’t actually binding. That was my first clue this wasn’t a syntax issue.
Attempt 2 — Permissions & sudo
Next thought: maybe it needed elevated privileges.
Killed the process. Restarted with sudo.
Same behavior.
That ruled out privileged port binding. Also ruled out sandbox limitations (it wasn’t an App Store build anyway — there’s no official listing under https://apps.apple.com/search?term=sing-box).
So the binary was executing, but macOS was silently blocking something.
That’s when I remembered Ventura’s tightened network controls.
The Real Problem — macOS Firewall & Network Filtering
Ventura introduced more aggressive network filtering and system-level firewall behavior. Especially for unsigned or non-notarized binaries.
Checked System Settings → Network → Firewall.
It was enabled.
Clicked “Options…” and there it was: the app wasn’t listed at all. Which means it wasn’t automatically granted incoming connection rights.
Apple documents how macOS handles firewall access here:
https://support.apple.com/guide/mac-help/block-connections-to-your-mac-with-a-firewall-mh11783/mac
What caught me off guard is that command-line tools don’t always trigger the standard “Allow incoming connections?” dialog.
GUI apps usually do. Daemons often don’t.
So macOS wasn’t crashing it. It was just quietly preventing it from accepting connections.
Attempt 3 — Codesigning Check
Before changing firewall settings, I wanted to verify signature status.
Ran:
spctl -a -vv /usr/local/bin/sing-box
Result: rejected.
Not notarized. Not signed.
That explains why Ventura treated it cautiously.
Apple’s documentation on notarization makes it clear how Gatekeeper and network security policies interact:
https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution
Unsigned binaries don’t get automatic trust, especially for inbound networking.
What Actually Worked
Two things.
- I manually added the binary to Firewall exceptions.
- I removed quarantine attributes just in case.
Firewall first:
System Settings → Network → Firewall → Options → Add → selected the binary.
Then verified it was set to “Allow incoming connections.”
After that, I ran:
sudo xattr -cr /usr/local/bin/sing-box
Just to eliminate any quarantine flags that Safari might have attached during download.
Restarted the service.
Immediately:
lsof -iTCP -sTCP:LISTEN
There it was. Listening on the configured port.
Clients connected instantly.
No config changes required. No recompile. The tool was fine the entire time.
The operating system was just being protective.
Side Note: Why It Didn’t Prompt Me
What made this frustrating is that macOS didn’t display a permission dialog. GUI-based apps often trigger an alert asking to allow network connections.
CLI tools don’t reliably do that.
So the behavior looked like a broken proxy, when in reality it was a silent firewall rule.
I saved this page because it explains how macOS network behavior can differ depending on binary type and system settings:
https://deadtriggermod.xyz/internet/42457-sing-box.html
It helped confirm I wasn’t dealing with a corrupt build or incompatible release.
If I Knew Then What I Know Now
I would’ve done this immediately after install:
- Check signature with
spctl - Clear quarantine attributes
- Add firewall exception manually
- Only then debug config
Instead, I lost about 40 minutes chasing a JSON ghost.
The irony is the networking stack inside the tool worked perfectly once macOS allowed it to operate normally.
Final State
Running stable on Ventura 13.6 (Intel).
No performance issues.
No memory leaks observed after a few hours of traffic routing.
The lesson here isn’t about Sing-box itself. It’s about how modern macOS handles unsigned networking utilities. The system doesn’t always block loudly. Sometimes it just blocks quietly.
And quiet failures are the most misleading kind.
If you’re testing local proxies, tunnels, or custom networking daemons on macOS, assume the firewall is involved before assuming your configuration is wrong.
It’ll save you a small existential crisis in Terminal.
Top comments (0)