macOS 27 - 502 error when including external network call

za0

Hi there, hope all well! I'm on IndigoStack v1.2.3 on macOS 27 and am seeing 502 errors in my Laravel app when the Http request attempts to do a DNS lookup. With Claude's help the root cause is apparently as follows:

Inner nginx error log (~/.indigo/stacks/61598A/nginx_B433/logs/SITENAME-error.log):

2026/09/23 12:00:54 [error] ... (54: Connection reset by peer) while reading response header from upstream ... upstream: "fastcgi://127.0.0.1:50000"

Port 50000 is the PHP 8.5.0 pool (php_B7D5). That log has 68 of these errors today, all since 10:34.

Xdebug log. Worker PID 56002 opened a request log at 11:00:54.61 UTC and never closed it. That PID never appears again, and a new worker (56032) starts 60 ms later.

Crash report. /Library/Logs/DiagnosticReports/php-fpm-2026-09-23-120055.ips is for PID 56002:

EXC_CRASH (SIGABRT), namespace OBJC
"*** single-threaded process forked ***" / "crashed on child side of fork pre-exec"

libcurl  getaddrinfo_thread → getaddrinfo → _gai_nat64_second_pass
Network  nw_path_is_ultra_constrained_allowed → SecTaskCopyValueForEntitlement
libobjc  performForkChildInitialize → _objc_fatal

Cause

This is macOS's Objective-C fork-safety check. FPM workers are forked from the master process. When curl's threaded DNS resolver calls getaddrinfo, macOS goes through Network.framework and Security.framework, which initialise an Objective-C class for the first time. The Objective-C runtime doesn't allow that in a forked child, so it aborts the process. The machine is on macOS 27, and those Network.framework calls are part of the stack.

That outbound HTTPS call triggers the DNS lookup. The request 15 ms later which worked fine only queries your database, so it never goes near curl's resolver. Your app serving the web app is fine. Only requests that make outbound HTTP calls crash, and production on Linux is not affected.

Fix

Set OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES in the environment of the PHP-FPM master process, then restart it.

It has to be on the master. The Objective-C runtime reads it when the process starts, so an env[...] line in www.conf (which applies to workers after the fork) won't help.

Any thoughts?!! Thanks!

za0

Btw I've tested this with a hacky workaround, renaming php-fpm in my stack to php-fpm.real then adding a new php-fpm launcher script per the below, which I made executable, and it does seem to have fixed the issue..!

#!/bin/sh
export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES
exec "$(dirname "$0")/php-fpm.real" "$@"

Indigo

Hi, thanks for your excellent triage, fantastic work! Your diagnosis was spot on.

I've just released a new version which contains a fix for this issue. Indigo now sets OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES in the environment of the PHP-FPM master process when it starts PHP, so workers can make outbound calls again. Once you've updated to 1.2.4, you can put your original php-fpm binary back in place of the wrapper script (or rebuild the stack).

za0

Indigo Many thanks, all sorted on 1.2.5!