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

Tabs dying with “This webpage was reloaded because a problem occurred”, over and over, on almost every big site? We hit this exact bug on one of our own Macs. The culprit is Safari 26.5.2’s network process crashing during the QUIC (HTTP/3) handshake — and there is a clean, reversible fix that takes about five minutes. Here is the write-up we wish we had found when it happened to us.

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.

What is actually breaking

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.

The fix: block QUIC with pf

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