Safari 26.5.2 keeps crashing? The QUIC handshake bug and the 5-minute fix

If you are on a Mac and Safari keeps reporting “This webpage was reloaded because a problem occurred”, over and over on major sites, check the crash evidence before changing any network settings. We hit this exact bug on one of our own Macs: Safari 26.5.2’s network process crashed during the QUIC (HTTP/3) handshake. When the same NetworkProcess and QUIC clues appear in your crash report, the reversible fix below takes about five minutes.

The symptoms

• Safari tabs reload themselves with “a problem occurred”, especially on Google, YouTube, and Cloudflare-hosted sites.
• Console.app / Crash Reports show repeated com.apple.WebKit.Networking (NetworkProcess) crashes.
• The crashing thread references QUIC / HTTP3 handshake frames.
• Chrome and Firefox on the same Mac are fine. It is Safari-specific.

Why Safari says a problem occurred repeatedly

QUIC is the transport under HTTP/3: instead of TCP, it runs over UDP port 443. Safari 26.5.2 has a bug where its NetworkProcess can crash while negotiating that QUIC handshake. Because most of the modern web advertises HTTP/3, Safari keeps attempting the handshake and keeps crashing.

The fix exploits a guarantee built into the protocol: every HTTP/3 site also serves HTTP/2 over TCP. If the QUIC path is unavailable, browsers silently fall back. So we block outbound UDP 443 system-wide with macOS’s built-in pf firewall. Safari stops crashing instantly, and browsing continues over HTTP/2 as if nothing happened.

How to disable QUIC on a Mac

You need an admin account and Terminal. Everything below is reversible (undo steps at the end).

Step 1: create the pf anchor file. This single rule drops outbound QUIC traffic:

sudo tee /etc/pf.anchors/no-quic << 'EOF'
block drop out quick proto udp from any to any port = 443
EOF

Step 2: back up pf.conf, then hook the anchor in.

sudo cp /etc/pf.conf /etc/pf.conf.pre-noquic.bak
sudo tee -a /etc/pf.conf << 'EOF'
anchor "no-quic"
load anchor "no-quic" from "/etc/pf.anchors/no-quic"
EOF

Step 3: enable pf with the new rules.

sudo pfctl -E -f /etc/pf.conf

Step 4: make it survive reboots. macOS parses pf.conf at boot but does not enable pf by default, so install a tiny LaunchDaemon that re-enables it:

sudo tee /Library/LaunchDaemons/com.user.noquic.plist << 'EOF'
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key><string>com.user.noquic</string>
  <key>ProgramArguments</key>
  <array>
    <string>/sbin/pfctl</string>
    <string>-E</string>
    <string>-f</string>
    <string>/etc/pf.conf</string>
  </array>
  <key>RunAtLoad</key><true/>
</dict>
</plist>
EOF
sudo launchctl bootstrap system /Library/LaunchDaemons/com.user.noquic.plist

Step 5: verify.

sudo pfctl -a no-quic -s rules   # shows the block rule
sudo pfctl -s info               # Status: Enabled

Trade-offs to know about

The block is system-wide: Chrome, Edge, and any other QUIC-capable app also falls back to HTTP/2. For everyday browsing on broadband this is imperceptible. HTTP/3’s wins are mostly on lossy mobile networks. If a specific app genuinely needs HTTP/3, undo the fix below.

How to undo it

# 1. restore pf.conf (or delete the two anchor lines)
sudo cp /etc/pf.conf.pre-noquic.bak /etc/pf.conf
sudo rm /etc/pf.anchors/no-quic
sudo pfctl -f /etc/pf.conf

# 2. remove the LaunchDaemon (or it re-enables pf at next boot)
sudo launchctl bootout system /Library/LaunchDaemons/com.user.noquic.plist
sudo rm /Library/LaunchDaemons/com.user.noquic.plist

FAQ