dnscrypt-proxy on macOS: should launchd ProcessType be Standard? Boot readiness improved from 117s to 42s

[corbon95]

Output of brew config

HOMEBREW_VERSION: 7.0.11
ORIGIN: https://github.com/Homebrew/brew
HEAD: c6069d2a943b71b0a90d91fc1ac93cb9c1634dcc
Last commit: 7 days ago
Branch: stable
Core tap: N/A
Core cask tap: N/A
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_NO_AUTO_UPDATE: set
Homebrew Ruby: 4.0.9 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/4.0.9/bin/ruby
CPU: octa-core 64-bit dunno
Clang: 21.0.0 build 2100
Git: 2.56.0 => /opt/homebrew/opt/git/bin/git
Curl: 8.23.0 => /opt/homebrew/opt/curl/bin/curl
macOS: 26.7.2-arm64
CLT: 27.0.0.0.1788430756
Xcode: N/A

Output of brew doctor

Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: Some installed formulae are deprecated or disabled.
You should find replacements for the following formulae:

  icu4c@78
  kubernetes-cli@1.35
  minio-mc
  openssl@3.0

Description of issue

Summary

After a macOS reboot, my local DNS chain was unavailable while the Homebrew dnscrypt-proxy service was starting. In one before/after comparison, changing only the generated launchd plist's ProcessType from Background to Standard reduced the time from kernel boot to the first successful Cloudflare upstream health check from 117 seconds to 42 seconds.

I am posting in Discussions first because this is a limited observation on one machine, not a demonstrated general regression. I have not run brew update as part of this comparison, and brew doctor currently reports the deprecated/disabled formulae listed above. I cannot truthfully complete all the reproducible-bug issue checklist items yet.

Environment and setup

• Apple Silicon, macOS 26.7.2 (25G332).
• Homebrew dnscrypt-proxy 2.1.20 and dnsmasq 2.93.
• Both are system launchd services running at boot.
• macOS resolver: 127.0.0.1:53 (dnsmasq).
• Public DNS forwarding: dnsmasq -> 127.0.0.1:5053 (dnscrypt-proxy) -> Cloudflare over DoH.
• Queries directly to dnscrypt-proxy also timed out during the affected startup, so the observation was not limited to macOS resolver selection or dnsmasq.

The dnscrypt-proxy formula explicitly contains:

service do
  run [opt_sbin/"dnscrypt-proxy", "-config", etc/"dnscrypt-proxy.toml"]
  keep_alive true
  require_root true
  process_type :background
end

Before/after measurements

Both boots were on 2026-11-02. All times below are elapsed from kern.boottime, not from login, desktop appearance, or Wi-Fi readiness.

Event	Background (before)	Standard (after)
First dnscrypt-proxy application log line	106 s	33 s
UDP listener on 127.0.0.1:5053 reported ready	106 s	39 s
First '[cloudflare] OK (DoH)' health-check message	117 s	42 s

During the Background capture, UDP queries to both 127.0.0.1:53 and 127.0.0.1:5053 timed out, and a TCP query through dnsmasq returned REFUSED. Direct dnscrypt-proxy queries began succeeding just after the upstream became ready. At the subsequent public-resolver checks, ordinary Cloudflare DNS, both configured bootstrap resolvers, and direct Cloudflare DoH requests were working.

With Standard, the diagnostic run after reboot found all local UDP/TCP and A/AAAA checks successful. Local queries completed in approximately 6-22 ms.

The post-change startup log also shows a short, explicit wait for networking:

[2026-11-02 20:44:22] [NOTICE] dnscrypt-proxy 2.1.20
[2026-11-02 20:44:23] [NOTICE] Network not available yet -- waiting...
[2026-11-02 20:44:28] [NOTICE] Network connectivity detected
[2026-11-02 20:44:28] [NOTICE] Now listening to 127.0.0.1:5053 [UDP]
[2026-11-02 20:44:28] [NOTICE] Now listening to 127.0.0.1:5053 [TCP]
[2026-11-02 20:44:31] [NOTICE] [cloudflare] OK (DoH) - rtt: 461ms

The earlier boot had its first application log line and 'Network connectivity detected' at 17:47:38, followed by '[cloudflare] OK' at 17:47:49; kern.boottime was 17:45:52. Therefore, most of that boot's delay occurred before the first application log line, rather than inside the configured 60-second network probe.

Configuration and the change tested

The only intentional configuration change between these two measured boots was:

 <key>ProcessType</key>
-<string>Background</string>
+<string>Standard</string>

The service was unloaded/reloaded to read the new plist, and then the Mac was rebooted for the after measurement. launchctl print reported 'spawn type = daemon (3)' after the change, and the plist still contained Standard after reboot.

Relevant dnscrypt-proxy global settings were unchanged (the usual public-resolvers source block is omitted here):

listen_addresses = ['127.0.0.1:5053']
server_names = ['cloudflare']
ipv4_servers = true
ipv6_servers = false
dnscrypt_servers = false
doh_servers = true
odoh_servers = false
ignore_system_dns = true
bootstrap_resolvers = ['9.9.9.11:53', '8.8.8.8:53']
netprobe_timeout = 60
netprobe_address = '9.9.9.9:53'
cache = false
log_level = 2
log_file = '/opt/homebrew/var/log/dnscrypt-proxy.log'
log_file_latest = false

Public forwarding in dnsmasq used port=53, listen-address=127.0.0.1, no-resolv, and server=127.0.0.1#5053.

Questions

Is Background the intended launchd classification for dnscrypt-proxy when the machine's DNS depends on it? Would process_type :standard be appropriate for this formula, or is there a reason to retain Background?

What additional measurements would be useful to distinguish launchd resource-priority effects from other boot-time factors?

There is only one measured boot per setting so far. This comparison does not establish causation, exclude different boot workloads, or show that every macOS system is affected. I have previously used dnscrypt-proxy on Linux without noticing a comparable startup delay, but I do not have a directly comparable Linux measurement to include.

AI disclosure: this initial post was drafted with OpenAI Codex (GPT-6) from the diagnostic results collected on this Mac. Full diagnostic archives, private DNS zones, and unrelated network details are not included.