Wi-Fi Stuck in Internet Sharing After Upgrading to macOS 27

After upgrading from macOS 26 to macOS 27, I ran into a confusing network problem. I had been sharing the connection handled by Surge for Mac over Wi-Fi, and had left Internet Sharing enabled before the upgrade. Later, when I wanted the Mac to connect to a router over Wi-Fi again, it would not behave like an ordinary Wi-Fi client.

Turning off Surge’s Enhanced Mode made Wi-Fi work. Turning it back on brought the problem back. Meanwhile, System Settings reported “This service is currently unavailable” beside several unrelated Sharing services, and I could not reliably turn Internet Sharing off there.

I needed Enhanced Mode, so leaving it disabled was not a satisfactory fix. Eventually, Wi-Fi and Enhanced Mode worked together again, and the Sharing warnings disappeared. There were two separate issues to resolve: the active Internet Sharing configuration and the firewall’s Block all incoming connections option.

This is a record of that particular recovery, with the checks and commands that helped. The symptoms appeared after the upgrade; I did not establish that the upgrade created the firewall setting or that this is a general macOS 27 or Surge defect.

The setup and symptoms

The incident was resolved on 16 September 2026 with:

Component	Version or state
Previous operating system	macOS 26
Operating system during diagnosis	macOS 27.0, build 26A428
Surge for Mac	6.9.1, build 12290
Earlier sharing arrangement	Surge connection shared to Wi-Fi, with Ethernet available upstream
Desired arrangement	Mac joins a router over Wi-Fi, with Surge Enhanced Mode enabled

Surge was up to date on this machine at the time. The exact version above is more useful for future comparisons than the word “latest.”

The Wi-Fi menu provided an important clue: it said Wi-Fi: Internet Sharing and displayed a wireless channel. Wi-Fi was powered on, but being used as a hotspot instead of connecting to the router.

In General → Sharing, File Sharing, Screen Sharing, Printer Sharing, Internet Sharing, Remote Management, Remote Login, and Remote Application Scripting showed unavailable warnings. Internet Sharing initially appeared on. Later, even after its switch appeared off, the other warnings remained.

The appearance of that switch alone was not enough to tell whether the hotspot had actually stopped.

Why Enhanced Mode looked responsible

Surge’s Enhanced Mode captures traffic through a virtual network interface. Current Surge for Mac uses Apple’s Network Extension framework for this. System Proxy mode has a different scope: applications must respect the system proxy settings to use it. Surge’s Enhanced Mode documentation

Disabling Enhanced Mode was a useful diagnostic comparison, but the final recovery did not require leaving it off. In this case, the relationship between Surge’s active connection and the existing Internet Sharing configuration was the more useful lead.

I found that Internet Sharing had Surge selected as its source and the Mac’s Wi-Fi interface as its output. A hotspot interface remained active, and the sharing service restarted during troubleshooting even after the saved enabled flag had been changed to zero.

That distinction mattered: a preference file on disk, a running network configuration, and a switch in System Settings can temporarily disagree.

Check the firewall before assuming every service is broken

The broad Sharing warnings had a separate explanation. The built-in macOS firewall had Block all incoming connections enabled.

Apple describes that option as blocking incoming connections to non-essential services and applications. It affects the availability of sharing services. In this incident, switching that option off and reopening Sharing settings cleared the warnings. Apple’s firewall settings guide

The setting is under System Settings → Network → Firewall → Options. To use sharing services, turn off Block all incoming connections, while keeping the firewall itself enabled.

This changes the incoming-connection policy: existing application allow rules can take effect again. It does not mean every sharing service should be turned on. Leave services you do not need off. If block-all is intentional or required by your organisation, keep that policy and ask the administrator about the sharing access you need.

These read-only commands distinguish the two firewall settings:

/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
/usr/libexec/ApplicationFirewall/socketfilterfw --getblockall

The equivalent change, with administrator authentication, is:

sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setblockall off

Afterward, the first check should still report that the firewall is enabled, and the second should report that block-all is disabled. There was no need to turn off the firewall or System Integrity Protection.

Stop sharing before using Wi-Fi as the upstream connection

Start with the normal controls: open System Settings → General → Sharing and turn Internet Sharing off. Then use the Wi-Fi menu to join the router’s network.

Apple documents Internet Sharing as a connection from one source interface to other devices over a selected output interface. In my earlier setup, Wi-Fi was the output. To use it as the Mac’s connection to the router, I needed to release it from that role. Apple’s Internet Sharing guide

If both Ethernet and Wi-Fi are connected, also check the network service order. I moved Wi-Fi above the USB Ethernet adapter so the Mac would prefer Wi-Fi. Interface names and service names vary by machine; list them before using interface-specific commands:

networksetup -listallhardwareports
networksetup -listnetworkserviceorder

On this Mac, Wi-Fi was en0. It need not be en0 on yours.

Recovery when the saved Off setting does not stop the hotspot

The following was the advanced recovery used in this incident, after the normal controls failed. It changes a system networking preference and stops sharing to connected devices. It is unnecessary if the graphical switch already works.

First, inspect the existing setting:

/usr/libexec/PlistBuddy -c 'Print :NAT:Enabled' \
  /Library/Preferences/SystemConfiguration/com.apple.nat.plist

If that file or key is absent, stop here: this procedure assumes an existing Internet Sharing configuration. Do not create one from this example.

Before changing it, keep a backup in a private temporary directory:

sharing_backup_dir="$(mktemp -d /private/var/tmp/internet-sharing-backup.XXXXXX)"
sudo cp -p /Library/Preferences/SystemConfiguration/com.apple.nat.plist \
  "$sharing_backup_dir/com.apple.nat.plist"
printf 'Backup directory: %s\n' "$sharing_backup_dir"

Then update the existing NAT dictionary through macOS’s System Configuration preferences interface, commit it, and apply it:

sudo /usr/sbin/scutil --prefs /Library/Preferences/SystemConfiguration/com.apple.nat.plist <<'SCUTIL'
get /NAT
d.add Enabled # 0
set /NAT
commit
apply
quit
SCUTIL

This preserves the other entries in the NAT dictionary and sets its Enabled value to numeric zero. The apply step was the decisive difference in this recovery: macOS received the configuration notification and tore down the active sharing network.

Immediately afterward, the logs recorded sharing stopping, routes being removed, and “AP stopped.” Wi-Fi connected and obtained an address while Surge Enhanced Mode remained on.

Earlier attempts to change only the file or terminate the Internet Sharing process had not reliably cleared the active state. Unloading the protected service was also rejected by System Integrity Protection. Those attempts are not part of the recovery procedure I would repeat.

Verify the connection, not just the switch

For my setup, these checks were useful:

# Replace en0 with the Wi-Fi interface identified above.
networksetup -getairportpower en0
ifconfig en0
scutil --nwi

# Query Surge's actual Enhanced Mode state.
/Applications/Surge.app/Contents/Applications/surge-cli feature get enhanced-mode

# Check an ordinary HTTPS request.
curl --connect-timeout 10 --max-time 15 -sS -o /dev/null \
  -w 'HTTPS status: %{http_code}\n' \
  https://www.apple.com/library/test/success.html

An HTTPS success alone does not prove the physical connection is Wi-Fi when Ethernet is also attached. Check the network service order and active interfaces too. With Enhanced Mode enabled, seeing a virtual tunnel interface in routing output is expected.

In this incident, ap1 was the hotspot interface. It became inactive after the configuration was applied. That name is an observation from this machine, not a universal interface to modify.

The final verified state was:

Check	Result
Wi-Fi client connection	Active, with an assigned address
Network preference	Wi-Fi ahead of the connected USB Ethernet adapter
Surge Enhanced Mode	On
Internet Sharing hotspot	Inactive
HTTPS request	HTTP 200
macOS firewall	Enabled
Firewall block-all option	Disabled
Sharing-panel unavailable warnings	Cleared after reopening System Settings

For a future upgrade, I will turn off Internet Sharing before upgrading or changing the Mac from a hotspot to a Wi-Fi client. If the same symptoms return, I will check both the active sharing state and the firewall’s block-all option before blaming Enhanced Mode. That is a precaution based on this incident, not a demonstrated requirement for every macOS upgrade.