macOS Sonoma users experience periodic ERR_NETWORK_CHANGED (and related ERR_SSL_PROTOCOL_ERROR) errors when using Brave. Users will experience the problem more frequently if they have HomeKit devices, iOS or Apple Watch devices paired with XCode, or iPhones configured to allow calling from the Mac. All of these use cases cause macOS to create and destroy ephemeral utun interfaces, which causes Brave to reset server connections.
The problem happens much more frequently under Sequoia, to the point of crippling Brave. Sequoia increases the frequency of utun creation and destruction.
Introduce ReduceIPAddressChangeNotification flag for Mac
Chromium Mac uses the DynamicStore API to monitor IP address changes. It
also resets all TCP and QUIC connections whenever it receives
notification of a network state change from the API. This logic was
introduced over 10 years ago (crbug.com/26156).
This notification is triggered whenever a new interface is added to the
machine. This causes an issue in macOS 14 where an utun interface for
communicating with iOS devices is regularly created and destroyed.
This CL introduces a new flag ReduceIPAddressChangeNotification. When
this feature is enabled, Chromium Mac ignores notifications from the
DynamicStore API if the network interface delta is a non-primary
interface with a local IPv6 address.
I’m hitting this issue as well. Brave is absolutely borked on Sequoia - most pages are stuck in a forever loading loop, with or without shields up. Major sites like gmail and github. Running Sequoia 15.0 and Brave Version 1.69.168 Chromium: 128.0.6613.138 (Official Build) (arm64). The checking for updates tool inside Brave can’t even run.
I was having the same issues with sites completely failing to load after recent browser/OS updates. After years of using Brave, I’ve made the switch to Firefox, where there are no issues.
Switching to Firefox ecosystem is not a useful idea I’m afraid given the rendering engine is not the same as Chrome and therefore won’t be the right choice for WebDevs or people willing to keep on Chrome plugins ecosystems while staying out of big tech tracking/controlling world. Indeed, on OSX Sequoia + Brave, it is now a real nightmare and for some totally impossible to use some websites, like openAI one… Unless Brave update fast and efficiently, it will be a massive exode from Bravo to alternatives, whatever bad they are…
Can anyone here encountering this try going to brave://flags and enabling the ReduceIPAddressChangeNotification flag and tell me if this resolves the issue?
@Mattches I just looked now and it seems like that flag has been deprecated/removed (code should have landed as default on). It was originally was introduced Chromium 124 (Brave 1.65.x) but typically Chromium sunsets flags after 3 months.
I am looking at patches we have which are Brave specific. If this does NOT happen on Chrome, then I am curious about a few things.
Is anyone here experiencing the problem using a proxy server? Or maybe the root cause for this is when you setup Facetime or iMessage to answer the call from iPhone (which must be doing a proxy).