upgrading SFM (sing-box for macOS) from 1.13.9 to 1.14.0, a VLESS + Reality + gRPC config that has worked reliably for months stops passing any traffic

Operating system

macOS

System version

15.7.9

Installation type

sing-box for macOS Graphical Client

If you are using a graphical client, please provide the version of the client.

1.14.0

Version

Description

Description

After upgrading SFM (sing-box for macOS) from 1.13.9 to 1.14.0, a VLESS + Reality + gRPC config that has worked reliably for months stops passing any traffic. The tunnel appears to connect, but no data ever gets through, and after roughly 1-2 minutes the underlying HTTP/2 connection is force-closed client-side.

Downgrading the exact same config to SFM 1.13.9 fixes it immediately — no other change.

Environment

• SFM version (broken): 1.14.0
• SFM version (working): 1.13.9
• macOS: Sequoia (Apple Silicon)
• Outbound: VLESS, TLS Reality, gRPC transport
• Config uses idle_timeout: 15s / ping_timeout: 15s on the grpc transport (server-recommended values, unchanged between versions)

Steps to reproduce

1. Install SFM 1.14.0 via Homebrew cask.
2. Import a working VLESS + Reality + gRPC config (TUN inbound, auto_route, strict_route).
3. Connect.

Observed behavior (1.14.0)

• Connection appears to establish (TUN comes up, DNS queries get sent through the proxy outbound).
• No real traffic ever gets a response:
  • TCP external IP check: fails, context deadline exceeded
  • STUN external IP check: fails, i/o timeout
  • DNS resolution through the hijacked port 53: fails, i/o timeout
• Debug log shows multiple gRPC/HTTP2 streams opened at different times (ages ~48s-111s), then all force-closed at the same timestamp:

  ERROR[0112] [...] connection: connection download closed: http2: client connection force closed via ClientConn.Close
  ERROR[0112] [...] connection: connection download closed: http2: client connection force closed via ClientConn.Close
  ERROR[0112] [...] connection: connection download closed: http2: client connection force closed via ClientConn.Close
  (packet-tunnel) stopping, reason: NEProviderStopReason(rawValue: 1)
  

  This looks like the client's own keepalive (idle_timeout/ping_timeout) gives up after never receiving any response on the underlying gRPC connection, and force-closes it — but the connection never carried any real data in the first place.

Expected behavior

Same config, same server, works with SFM 1.13.9 (and with a third-party client using the same VPN account, tested in parallel) — traffic flows immediately, TCP/STUN/QUIC checks all resolve to the real external IP, DNS hijack works.

Isolation already done

• Same config file, same server, same credentials tested three ways:
  1. Third-party official app for this VPN provider → works.
  2. SFM 1.13.9 → works.
  3. SFM 1.14.0 → connects but zero data transfer, force-closed after ~1-2 min.
• This rules out the server/provider and the config itself; the regression is isolated to the SFM/sing-box core client between 1.13.9 and 1.14.0.
• Not an isolated case — closely matches a previously reported, unresolved issue: #3304 ("SFA completely not working (no data transfer) for version >= 1.12"), same core, same symptom class (connects, no data transfer), closed without root cause due to lack of a reproducible config. This report includes matching debug log evidence.

Config (redacted)

{
  "outbounds": [
    {
      "type": "vless",
      "tag": "proxy",
      "server": "REDACTED.example.com",
      "server_port": 443,
      "uuid": "REDACTED-UUID",
      "tls": {
        "enabled": true,
        "server_name": "REDACTED-SNI.example.com",
        "utls": { "enabled": true, "fingerprint": "firefox" },
        "reality": {
          "enabled": true,
          "public_key": "REDACTED",
          "short_id": "REDACTED"
        }
      },
      "transport": {
        "type": "grpc",
        "service_name": "REDACTED",
        "idle_timeout": "15s",
        "ping_timeout": "15s"
      },
      "packet_encoding": "xudp"
    }
  ]
}

Additional notes

Happy to provide the full debug-level log (with server/identity details redacted) if useful.

Reproduction

Above

Logs

Supporter

• I am a sponsor

Integrity requirements

• I confirm that I have read the documentation, understand the meaning of all the configuration items I wrote, and did not pile up seemingly useful options or default values.
• I confirm that I have provided the server and client configuration files and process that can be reproduced locally, instead of a complicated client configuration file that has been stripped of sensitive data.
• I confirm that I have provided the simplest configuration that can be used to reproduce the error I reported, instead of depending on remote servers, TUN, graphical interface clients, or other closed-source software.
• I confirm that I have provided the complete configuration files and logs, rather than just providing parts I think are useful out of confidence in my own intelligence.

No source files or tests are named. Start by comparing the sing-box core's gRPC/HTTP2 transport behavior between 1.13.9 and 1.14.0, using the reported force-close logs and a reproducible configuration if the reporter supplies one. Done means the same VLESS + Reality + gRPC setup carries traffic and the TCP, STUN, and DNS checks succeed without the client force-closing the connection.