ERR_QUIC_PROTOCOL_ERROR: ne anlama gelir ve nasıl düzeltilir

ERR_QUIC_PROTOCOL_ERROR ne anlama gelir

Chromium, QUIC_PROTOCOL_ERROR (-356) hatasını "There is a QUIC protocol error." (bir QUIC protokol hatası var) olarak tanımlar. QUIC, HTTP/3'ün taşıma protokolüdür: RFC 9000 QUIC'i, RFC 9114 de onun üzerinde çalışan HTTP/3'ü tanımlar. QUIC, TCP yerine UDP üzerinde çalışır; bu yüzden HTTP/1.1 ve HTTP/2'den farklı bir ağ yolu kullanır. Sunucu, HTTP/3'ü h3=":443" gibi bir Alt-Svc yanıt başlığıyla duyurur ve tarayıcı sonraki ziyarette ona bir QUIC bağlantısı açabilir. RFC 9114, engellenmiş UDP'nin bir QUIC bağlantısını başarısız kılabileceğini ve istemcilerin bu durumda TCP üzerinden HTTP kullanması gerektiğini (SHOULD) ekler.

Chromium kaynak kodu, bu kodun pratikte ne anlama geldiğini gösterir. QUIC el sıkışması hiç bitmezse Chrome farklı bir hata bildirir, ERR_QUIC_HANDSHAKE_FAILED (-358), ve isteği yeniden dener. ERR_QUIC_PROTOCOL_ERROR ise kurulmuş ve sonra bir hatayla sona ermiş bir bağlantı ya da akış için, ayrıca geçersiz başlıklar gibi HTTP/3 kurallarını bozan bir yanıt için kullanılan genel koddur. Yani hatadan önce en azından bir miktar UDP trafiği geçmiştir.

Chrome ayrıca kendiliğinden yeniden dener. Hata yanıt başlıkları gelmeden önce olursa Chrome isteği HTTP/3 olmadan, TCP üzerinden yeniden gönderir ve bu çalışırsa sitenin HTTP/3 hizmetini, tekrarlanan hatalarla uzayan bir süre boyunca bozuk olarak işaretler. Hata sayfası bu yüzden yeniden denemenin mümkün olmadığı durumlarda çıkar: yanıt zaten başlamıştır ya da yeniden deneme de başarısız olmuştur. DevTools'un çoğu zaman durum satırı gelmiş ama gövde gelmemiş şöyle bir istek göstermesinin nedeni budur:

GET https://example.com/downloads/report.zip net::ERR_QUIC_PROTOCOL_ERROR 200 (OK)

Hata nasıl görünür

Chrome'un bu kod için özel bir metni yoktur; bu yüzden en altta ERR_QUIC_PROTOCOL_ERROR yazan genel "This site can't be reached" sayfasını gösterir. Edge, Brave, Opera ve diğer Chromium tabanlı tarayıcılar aynı kodu gösterir. Bazen hiç hata sayfası çıkmaz: sayfa yüklenir ama bir resim, betik ya da indirme başarısız olur ve hata yalnızca DevTools konsolunda görünür.

Bir sitenin hangi protokolü kullandığını görmek için DevTools'u açın, Network paneline gidin, sütun başlıklarına sağ tıklayın ve "Protocol" sütununu etkinleştirin. h3 değeri HTTP/3, h2 değeri HTTP/2 demektir. Komut satırından Alt-Svc başlığına bakın ve curl'ünüz destekliyorsa HTTP/3'ü doğrudan test edin (curl -V özellikler arasında HTTP3'ü listeler):

curl -sI https://example.com/ | grep -i alt-svc
alt-svc: h3=":443"; ma=86400

curl --http3-only -sS -o /dev/null -w 'h3: %{http_version} %{http_code}\n' https://example.com/
h3: 3 200
curl --http2 -sS -o /dev/null -w 'h2: %{http_version} %{http_code}\n' https://example.com/
h2: 2 200

Çalışan bir HTTP/3 dinleyicisi olmayan bir sunucu ikinci komutta başarısız olur; örneğin curl: (7) Failed to connect to example.com:443 after 246 ms: Could not connect to server. Bir güvenlik duvarı paketleri yanıt vermeden düşürüyorsa komut bekler ve curl: (28) Connection timed out ile biter. İki komutu da geçen bir sunucu, sorun ziyaretçinin ağındaysa tarayıcıda yine de başarısız olabilir.

ERR_QUIC_PROTOCOL_ERROR ile benzer hatalar

İlk iki satır yakın akrabadır. Diğerleri aynı sayfa yüklemesinin TCP tarafından gelir. Parantezli sayılar Chromium'un iç hata kodlarıdır.

Hata	Ağ veya protokol düzeyinde ne oldu	İlk bakılacak yer
ERR_QUIC_PROTOCOL_ERROR (-356)	Bir QUIC bağlantısı kuruldu, sonra bir akış ya da tüm bağlantı bir hatayla sona erdi veya yanıt HTTP/3 kurallarını bozdu.	UDP yolu (güvenlik duvarı, NAT, MTU), sunucunun HTTP/3 yığını, UDP yük dengeleyiciler.
ERR_QUIC_HANDSHAKE_FAILED (-358)	QUIC el sıkışması tamamlanmadı. Chrome isteği yeniden dener.	UDP 443'ün sunucuya hiç ulaşıp ulaşmadığı.
ERR_HTTP2_PROTOCOL_ERROR	TLS çalıştı, ama bir çerçeve ya da akış TCP üzerindeki HTTP/2 kurallarını bozdu.	Proxy ve CDN'in HTTP/2 ayarları, başlık boyutları.
ERR_SSL_PROTOCOL_ERROR (-107)	TCP üzerindeki TLS el sıkışması, kullanamayacağı veri aldı.	TLS yapılandırması ve portun gerçekte konuştuğu protokol.
ERR_CONNECTION_RESET (-101)	Açık bir TCP bağlantısı bir RST ile sonlandırıldı.	Proxy, WAF ve uygulama günlükleri; istemci tarafındaki antivirüs, VPN veya filtreleme.
ERR_CONNECTION_TIMED_OUT (-118)	TCP SYN paketi gitti ve istemci vazgeçene kadar hiçbir şey dönmedi.	Paketleri düşüren güvenlik duvarları ve sunucunun ayakta olup olmadığı.

ERR_QUIC_PROTOCOL_ERROR'a ne sebep olur

• UDP 443 filtreleniyor ya da sınırlanıyor. Bir güvenlik duvarı, yönlendirici ya da güvenlik ürünü ilk paketleri geçirip sonrakileri düşürüyor veya UDP hızını sınırlıyor. Bazı şirket güvenlik duvarları QUIC'i bilinmeyen trafik sayar.
• Yol büyük paketleri düşürüyor. RFC 9000, ilk QUIC paketleri için en az 1200 baytlık UDP datagramları ister. Küçük MTU'lu bir VPN, tünel veya PPPoE bağlantısı ya da parçalara ayrılmış paketleri düşüren bir cihaz bunu bozar.
• NAT ve boşta kalma zaman aşımları. Bir NAT cihazı, kısa bir boşta kalma süresinden sonra UDP eşlemesini unutur ve sunucunun paketleri hiçbir yere gitmez.
• UDP'yi kötü işleyen bir VPN, proxy ya da antivirüs. Cihazdaki yazılım UDP trafiğini engelleyebilir, inceleyebilir veya yeniden yazabilir.
• Sunucu durumunu kaybediyor. Yeniden başlatma ya da çökmeden sonra sunucuda eski bağlantılara dair kayıt kalmaz. RFC 9000 bu durum için durumsuz sıfırlamayı (stateless reset) tarif eder ve istemci bağlantının bittiğini görür.
• QUIC'ten haberi olmayan bir yük dengeleyici. Tek bir bağlantının paketleri aynı arka uca ulaşmalıdır. Yalnızca kaynak adres ve porta göre dengeleme, bir NAT istemcinin portunu değiştirdiğinde bozulabilir.
• HTTP/3 duyuruluyor ama erişilemiyor. Sunucu Alt-Svc gönderiyor, ama UDP 443 bir güvenlik duvarında, bulut güvenlik grubunda ya da Docker port eşlemesinde kapalı.
• Bir HTTP/3 uygulamasındaki hatalar. Geçersiz başlık veya çerçeve gönderen bir sunucu ya da CDN ucu ya da eski bir tarayıcı, bir bağlantıyı protokol hatasıyla sonlandırabilir.
• Chrome bayrakları ve eklentileri. Deneysel bayraklar ve ağ davranışını değiştiren eklentiler araya girebilir.

Sunucu tarafı nedenler ve yapılandırma

Siteyi siz işletiyorsanız, HTTP/3'ün internetten yanıtı veren sürece kadar uçtan uca çalıştığından emin olun ya da onu temiz biçimde kapatın.

QUIC hatasını bir Chrome günlüğünde bulun

chrome://net-export sayfasını açın, "Start Logging to Disk" düğmesine tıklayın, hatayı yeniden üretin, "Stop Logging" düğmesine tıklayın ve dosyayı sayfanın bağlantı verdiği NetLog görüntüleyicide açın. QUIC_SESSION_CLOSED olayını bulun. Olayın quic_error alanı nedeni söyler, from_peer alanı da bağlantıyı sunucunun bitirip bitirmediğini. Chromium'un QUIC kütüphanesinden gelen şu değerler yaygındır:

quic_error	Kütüphanedeki anlamı	İlk bakılacak yer
QUIC_TOO_MANY_RTOS	QUIC, çok fazla yeniden iletim zaman aşımından sonra zaman aşımına uğradı: paketler gönderildi ve hiç onaylanmadı.	UDP yolundaki paket kaybı: güvenlik duvarı, NAT, MTU, aşırı yüklü bir sunucu.
QUIC_NETWORK_IDLE_TIMEOUT	Bağlantı, ağ etkinliği olmadığı için zaman aşımına uğradı.	Süresi dolan NAT eşlemeleri ya da paketleri yanıt vermeden düşüren bir yol.
QUIC_PUBLIC_RESET	Bu bağlantı için bir sıfırlama alındı.	Sunucunun yeniden başlaması ya da paketleri başka bir arka uca gönderen bir yük dengeleyici.
QUIC_PACKET_WRITE_ERROR	Sokete yazarken bir hata oluştu.	Cihazdaki ağ yığını: VPN, güvenlik duvarı sürücüsü, bağdaştırıcı.

UDP 443'ü her katmanda açın

Güvenlik duvarları için TCP 443 ve UDP 443 farklı portlardır. Kendi kuralları olan her katmanı kontrol edin:

# UDP 443'te dinleyen bir şey var mı?
sudo ss -lunp | grep ':443'

# ufw
sudo ufw allow 443/udp

# iptables
sudo iptables -A INPUT -p udp --dport 443 -j ACCEPT

# Docker: UDP portunu TCP portunun yanında yayınlayın
docker run -d -p 443:443/tcp -p 443:443/udp my-web-image

Bulut güvenlik gruplarında ve ağ ACL'lerinde UDP 443 için bir gelen kuralı ekleyin. Kubernetes'te bir Service'in UDP için ayrı bir port girdisine ihtiyacı vardır:

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
    - name: http3
      protocol: UDP
      port: 443
      targetPort: 8443

nginx

nginx belgeleri HTTP/3 desteğini 1.25.0 sürümünden itibaren listeler ve modülü deneysel olarak işaretler. HTTP/3 ve HTTPS için aynı portun kullanılmasını önerir. Dinleyicinin quic parametresine, yanıtın da Alt-Svc başlığına ihtiyacı vardır:

server {
    listen 443 quic reuseport;   # UDP üzerinden HTTP/3
    listen 443 ssl;              # TCP üzerinden HTTPS
    server_name example.com;
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;
    add_header Alt-Svc 'h3=":443"; ma=86400' always;
}

ma değeri, istemcilerin HTTP/3 hizmetini kaç saniye boyunca hatırlayabileceğidir (86400 saniye 24 saattir). HTTP/3'ü kapatmak için quic dinleyicisini ve Alt-Svc başlığını kaldırın. Eski başlığı hatırlayan istemciler ma süresi dolana kadar denemeye devam eder. Bunun yerine bir süre add_header Alt-Svc 'clear' always; gönderin: RFC 7838, clear değerini kaynağın (origin) tüm alternatif hizmetlerini geçersiz kılmak üzere tanımlar. nginx hata ayıklama günlüğü tüm QUIC iletilerini "quic" önekiyle işaretler; bu da onları süzmeyi kolaylaştırır.

Caddy

Caddy varsayılan olarak HTTP/3 sunar. Belgeleri, protocols seçeneğinin varsayılanı olarak h1 h2 h3 değerini listeler. HTTP/3'ü kapatmak için listeyi h3 olmadan ayarlayın:

{
    servers {
        protocols h1 h2
    }
}

CDN'ler ve yük dengeleyiciler

Çoğu CDN'in ağ ayarlarında HTTP/3 için bir anahtar vardır. Hatalar bir CDN ya da yük dengeleyici değişikliğinden sonra başladıysa, önce orada HTTP/3'ü kapatın ve hataların durup durmadığına bakın. Kendi UDP yük dengeleyicileriniz için, istemcinin kaynak portu değişse bile tek bir QUIC bağlantısının paketlerinin aynı arka uca ulaştığından emin olun.

Dışarıdan nasıl görünür

• HTTP/2 üzerinden çalışıyor, HTTP/3 üzerinden her konumdan başarısız oluyor: sunucunun veya CDN'in HTTP/3 yığını suçludur. Araştırırken o katmanda HTTP/3'ü kapatın.
• Yalnızca bazı ağlardan başarısız oluyor: o ağlardaki bir güvenlik duvarı veya sağlayıcı UDP 443'ü yanlış işliyor. Sunucu sağlam ve Chrome çoğu durumda TCP'ye geri döner.
• Yalnızca sizde başarısız oluyor, diğer tarayıcılar veya cihazlar çalışıyor: neden cihazınızda veya yönlendiricinizdedir; güvenlik yazılımı, VPN, bir Chrome bayrağı ya da eklenti gibi.
• Büyük dosyalar ve uzun yanıtlar başarısız oluyor, küçük sayfalar yükleniyor: hata başlıklar geldikten sonra olduğu için Chrome yeniden deneyemez. MTU sorunlarına, UDP hız sınırlarına ve boşta kalma zaman aşımlarına bakın.
• Hatalar dağıtımlardan veya yeniden başlatmalardan sonra çıkıyor: sunucu bağlantı durumunu kaybetti ya da yük dengeleyici bağlantıları başka yere taşıdı.

UDP 443, TCP 443'ten ayrı bir ağ yoludur; bu yüzden TCP üzerinden yüklenen bir sayfa, HTTP/3 hakkında hiçbir şey söylemez. HTTP/3'ü yukarıdaki curl komutlarıyla doğrudan test edin ve bir ana bilgisayarın HTTP durumunu, yanıt süresini ve erişilebilirliğini dünyanın dört bir yanındaki konumlardan kontrol eden HTTP denetleyicisi ile karşılaştırın.

ERR_QUIC_PROTOCOL_ERROR nasıl düzeltilir

Ziyaretçiyseniz

1. Sayfayı yeniden yükleyin. Chrome çoğu zaman TCP üzerinden kendiliğinden yeniden dener ve o site için HTTP/3'ün başarısız olduğunu hatırlar.
2. Başka bir ağ deneyin ve VPN'i kapatın. Site mobil veride çalışıyorsa, ilk ağ ya da VPN UDP'yi engelliyor veya bozuyor demektir.
3. Chrome'u güncelleyin: chrome://settings/help sayfasından güncelleyip yeniden başlatın.
4. Chrome'da QUIC'i kapatın. chrome://flags/#enable-quic sayfasını açın, "Experimental QUIC protocol" seçeneğini "Disabled" yapın ve "Relaunch" düğmesine tıklayın. Bu bayrağın adı ve yeri Chrome sürümleri arasında değişebilir; bulamazsanız chrome://flags içinde "QUIC" araması yapın. Edge ve diğer Chromium tabanlı tarayıcıların kendi bayraklar sayfası vardır, örneğin edge://flags. Siteler TCP üzerinden çalışmaya devam eder.
5. İsterseniz Chrome'u QUIC olmadan başlatın; bir komut satırı anahtarı kullanabilirsiniz. Windows'ta kurulum klasöründen chrome.exe --disable-quic çalıştırın. macOS'ta open -a "Google Chrome" --args --disable-quic, Linux'ta google-chrome --disable-quic çalıştırın.
6. Eklentileri devre dışı bırakın veya gizli pencere kullanın. Hata kayboluyorsa eklentileri tek tek yeniden açın.
7. Güvenlik yazılımını ve yönlendiriciyi kontrol edin. Bazı ürünler QUIC'i engeller veya inceler. Bir şirket bilgisayarında BT ekibinden UDP 443'e izin vermesini ya da QUIC'i yasaklayan Chrome ilkesi QuicAllowed'ı false yapmasını isteyin.

Siteyi siz işletiyorsanız

1. Neyi duyurduğunuza bakın: curl -sI https://example.com/ | grep -i alt-svc.
2. HTTP/3 ile HTTP/2'yi karşılaştırın: yukarıdaki iki curl komutuyla, hem kendi ağınızdan hem de başka bir ağdaki bir sunucudan.
3. UDP 443'ü açın: ana makine güvenlik duvarında, bulut güvenlik grubunda, konteyner eşlemesinde ve yük dengeleyicide; dinleyiciyi ss -lunp ile kontrol edin.
4. Sunucu günlüklerini okuyun; hata anındaki QUIC hatalarını arayın ve web sunucusunu ile TLS kütüphanesini, üreticinin HTTP/3 için listelediği sürümlere güncelleyin.
5. Hemen çözemiyorsanız HTTP/3'ü kapatın: CDN'de ya da web sunucusunda kapatın ve bir süre Alt-Svc: clear gönderin. Ziyaretçiler o zaman TCP üzerinden HTTP/2 kullanır.
6. Her değişiklikten sonra DevTools'taki Protocol sütunuyla doğrulayın.

HTTP/3 sunan bir siteyi izlemek

Bir HTTP/3 sorunu çoğu zaman bazı ağları ve bölgeleri etkiler, diğerlerini etkilemez; bu yüzden tek bir sonuçtan çok örüntü önemlidir. HostTracker web sitelerini 2004'ten beri izliyor ve 158 şehirdeki 300'den fazla kontrol noktasından kontrol ediyor; e-posta, SMS, sesli arama, Slack, Telegram ve daha fazlasıyla uyarı gönderiyor. Güvenlik duvarlarında, yük dengeleyicilerde veya CDN ayarlarında yaptığınız her değişiklikten sonra UDP 443'ü ayrıca curl ile doğrudan test edin; çünkü bu ayrı bir yoldur.

Sık sorulan sorular

QUIC ile HTTP/3 arasındaki fark nedir?

QUIC, UDP üzerinde çalışan ve RFC 9000'de tanımlanan bir taşıma protokolüdür. HTTP/3, QUIC üzerinde çalışan HTTP sürümüdür ve RFC 9114'te tanımlanır. İkisi de şifrelidir: HTTP/3, QUIC içinde TLS 1.3 kullanır; tarayıcılar HTTP/2'yi yalnızca TCP üzerindeki TLS ile kullanır.

Chrome'da QUIC'i kapatmak güvenli mi?

Evet. Web siteleri TCP üzerinden HTTP/2 veya HTTP/1.1 ile çalışmaya devam eder ve bu trafik de TLS ile şifrelidir. Yalnızca HTTP/3'ün özelliklerini kaybedersiniz.

ERR_QUIC_PROTOCOL_ERROR web sitesinin çöktüğü anlamına mı gelir?

Hayır. Aynı site normalde TCP üzerinden hâlâ çalışır. Hata, HTTP/3 bağlantısının yolda başarısız olduğunu söyler; neden ağınız, sunucu ya da aradaki herhangi bir şey olabilir.

Neden yalnızca büyük dosyalarda oluyor?

Chrome bir isteği TCP üzerinden yalnızca yanıt başlıkları gelmeden önce yeniden deneyebilir. Büyük bir gövdenin ortasındaki hata yeniden denenecek bir şey bırakmaz ve hata sayfası ya da konsol mesajı çıkar. Paket kaybı, MTU sınırları ve boşta kalma zaman aşımları uzun aktarımları daha sık vurur.

Neden Chrome ve Edge'de görüyorum ama Firefox'ta görmüyorum?

Chrome ve Edge, Chromium ağ yığınını ve hata kodlarını paylaşır. Firefox'un kendi HTTP/3 uygulaması ve kendi hata mesajları vardır; bu yüzden aynı ağ sorunu orada farklı görünür.

Sunucumda HTTP/3'e ihtiyacım var mı?

Hayır. HTTP/3 isteğe bağlıdır ve TCP üzerinden HTTP/2 her tarayıcıda çalışır. UDP 443'ü uçtan uca güvenilir tutamıyorsanız HTTP/3'ü kapatmak geçerli bir tercihtir.

Kaynaklar ve ek okumalar

• Chromium net error list: QUIC_PROTOCOL_ERROR (-356), QUIC_HANDSHAKE_FAILED (-358) ve yukarıdaki tablodaki diğer kodların tanımları.
• RFC 9114, HTTP/3: bir HTTP/3 uç noktasını keşfetme ve TCP'ye geri dönme hakkında bölüm 3.1, Alt-Svc başlığı hakkında bölüm 3.1.1.
• RFC 9000, QUIC: 1200 baytlık datagram boyutu hakkında bölüm 14.1, durumsuz sıfırlama hakkında bölüm 10.3.
• nginx: ngx_http_v3_module: quic dinleyicisi, Alt-Svc örneği ve HTTP/3 yönergeleri.