Customers are encountering issues with access, showing the error: ERR_QUIC_PROTOCOL_ERROR.
ForumForumCustomers are encountering issues with access, showing the error: ERR_QUIC_PROTOCOL_ERROR.
This ticket is urgent, requesting assistance.
The website is currently operating normally (HTTP/2 responses are fine). ERR_QUIC_PROTOCOL_ERROR occurs because the browser failed to connect using HTTP/3 (QUIC), usually due to the client's network environment blocking UDP port 443.
Temporary workaround for clients: Enter chrome://flags/#enable-quic in the Chrome address bar, set QUIC to Disabled, and restart the browser.
Currently, the platform does not support disabling HTTP/3 individually, but this issue does not affect normal access via HTTP/2. If most clients are experiencing this issue, please let us know, and we can assist by removing the alt-svc header from the server side.
My client is in Taiwan. They cannot access it from either their computer or mobile phone. My server is also on GCP Taiwan. Do we have any other solutions?
The server being in GCP Taiwan doesn't affect this issue — the problem is the same regardless of server location.
Your client's network is blocking UDP port 443, which is required for HTTP/3 (QUIC). When the browser fails the QUIC connection, it shows ERR_QUIC_PROTOCOL_ERROR. HTTP/2 works fine — we've confirmed the site responds normally.
The alt-svc header that triggers HTTP/3 is set by the platform's ingress controller and can't be disabled per-server at the moment. We'll add this as a feature request.
In the meantime, ask your client to try switching networks (e.g., mobile data instead of WiFi) to confirm it's a network-level block. On desktop Chrome, disabling QUIC at chrome://flags/#enable-quic will also work.
Do my customers really have to perform this operation for every single device? That doesn't make sense. Is there no other solution?
It's not working on the client's mobile phone either, ahhhhh!
?
You are right; it is not realistic to ask every customer to manually disable QUIC. We have submitted a ticket to our engineering team (PLA-1738) to add an option to disable HTTP/3 in the ingress controller.
However, one point needs to be clarified: under normal circumstances, even if a QUIC connection fails, the browser should automatically fall back to HTTP/2, and it should not result in a complete inability to access the site. The situation your customer is experiencing is quite unusual.
Please ask your customer to try the following two things to help us determine if the issue is indeed caused by QUIC:
If Firefox/Safari can access the site normally but Chrome cannot, then it is confirmed to be a QUIC issue, and we will expedite the fix. If all browsers fail, the issue might not be related to HTTP/3, and we will need to investigate further.
My client reported that it works on Safari, so this issue is difficult to reproduce. Could you please help me look into this?
Hello, we are currently working on a fix for this issue. Before the fix is deployed, please ask the customer to use Safari for now.
This ticket has been inactive for a while. We will be closing it in 2 days if there is no new activity.