# AVG Web Protection blokuje stronę lub jej elementy: przyczyna i rozwiązanie

> URL: https://4eck-media.de/pl/blog/avg-web-protection-blokuje-strone-lub-jej-elementy-przyczyna-i-rozwiazanie/  
> Language: pl  
> Description: Gdy nowoczesna technologia jest zbyt nowoczesna: jak oprogramowanie AVG blokowało HTTP/3 – i dlaczego nasze rozwiązanie może teraz pomóc innym rozwiązać problemy […]

---

Gdy nowoczesna technologia jest zbyt nowoczesna: jak oprogramowanie AVG blokowało HTTP/3 – i dlaczego nasze rozwiązanie może teraz pomóc innym **rozwiązać problemy z HTTP/3** – oto nasz artykuł na blogu. Gdy pod koniec października 2025 roku przeprowadziliśmy relaunch strony internetowej gimnazjum z internatem Schloss Torgelow (osobny artykuł na blogu jeszcze się ukaże!), wszystko miało być perfekcyjne … i takie właśnie było: nowy system WordPress, migracja treści strony z Typo3 do WordPressa, wysokowydajny hosting na nowoczesnym serwerze chmurowym Hetzner, najwyższe wyniki w PageSpeed, dostępności cyfrowej i bezpieczeństwie oraz projekt UX, który można zaliczyć do najnowocześniejszych stron szkolnych na świecie.

    
        
            
                
                    

![Neue Website für Schloss Torgelow](https://4eck-media.de/wp-content/uploads/2025/11/schlosstorgelow-relaunch-1920x1080.avif "schlosstorgelow-relaunch")
                
            
        
    

Jednak podczas gdy u nas wszystko działało błyskawicznie, klient nagle zgłosił: *„Strona ładuje się bardzo wolno albo wcale. Czasami brakuje obrazów, czasami wszystko jest białe.”*

To, co początkowo brzmiało jak typowy błąd pamięci podręcznej lub przeglądarki, po intensywnej analizie okazało się wysoce specyficznym współdziałaniem Firefoksa, Windowsa, ochrony WWW AVG i nowego protokołu HTTP/3.

## Objawy: ERR_QUIC_PROTOCOL_ERROR & NS_ERROR_NET_PARTIAL_TRANSFER

W środowisku deweloperskim (staging) występowały osobliwe błędy:

- Skrypty i obrazy nie ładowały się w całości.
- W konsoli przeglądarki pojawiały się komunikaty takie jak ERR_QUIC_PROTOCOL_ERROR i NS_ERROR_NET_PARTIAL_TRANSFER.
- Ten sam obraz, którego nie dało się załadować na stronie, otwierał się bez problemu w nowej karcie.

Podejrzenie nasuwało się samo: to nie błąd w kodzie, lecz problem transportowy – a więc coś pomiędzy przeglądarką, serwerem a siecią.

## Poszukiwanie przyczyny: od motywu po antywirusa

Aby wykluczyć czynniki zakłócające, działaliśmy systematycznie:

- Zmiana motywu → bez zmian
- Dezaktywacja pamięci podręcznej → bez zmian
- Wyłączenie wtyczek → bez zmian
- Sprawdzenie firewalla & WAF → nic podejrzanego

Dopiero gdy przygotowaliśmy czyste środowisko testowe – świeży system Windows z AVG Antivirus i Firefoksem – okazało się:  
Gdy tylko ochrona WWW AVG była aktywna, pojawiały się błędy. Po dezaktywacji modułu ochrony WWW wszystko działało bez zarzutu.

Równolegle wspierał nas administrator systemów naszego klienta, który zgłosił: *… że przeanalizował właśnie jeszcze raz ok. 15 różnych skanerów antywirusowych. Testowaliśmy przy tym wyłącznie wersje bezpłatne.  
Nowa strona nie działa przy AVG free, AVG Business i Avast Free – za każdym razem w połączeniu z Firefoksem.*

## Przyczyna: HTTP/3 przez QUIC napotyka oprogramowanie zabezpieczające

HTTP/3 to najnowsza wersja protokołu internetowego, która w przeciwieństwie do HTTP/2 nie opiera się już na TCP, lecz na QUIC przez UDP (port 443). Kompatybilność jest zapewniona we wszystkich dużych przeglądarkach – zobacz zrzut ekranu z https://caniuse.com/http3.

    
        
            
                
                    

![Browserkompatibilität von HTTP/3](https://4eck-media.de/wp-content/uploads/2025/11/can-i-use-http3-1920x1080.avif "can-i-use-http3")
                
            
        
    

Zastosowanie HTTP/3 sprawia, że połączenia są teoretycznie szybsze i stabilniejsze – jednak nie wszędzie.

Niektóre firewalle, routery i rozwiązania antywirusowe traktują ruch UDP bardziej restrykcyjnie. Dokładnie tak najwyraźniej działał również skaner DNS/DoS AVG, który błędnie ograniczał strumień danych QUIC.  
Skutek: przerwane transfery plików – zwłaszcza w przypadku większych obrazów lub plików JavaScript.

Co ciekawe: na innej domenie działającej na tym samym serwerze problemy nie występowały. Różnica?  
Ta domena pozostała na HTTP/2 (TCP) – czyli starszym, bardziej konserwatywnym protokole, którego AVG nie blokował.

## Rozwiązanie: wyłączyć HTTP/3 & poinformować przeglądarki

Aby zapewnić stabilność wszystkim użytkownikom, zdecydowaliśmy się na pragmatyczną drogę:  
Wyłączyliśmy HTTP/3 dla dotkniętej problemem domeny i dodatkowo wysłaliśmy do wszystkich przeglądarek nagłówek *Alt-Svc: clear*. W ten sposób wydawane jest polecenie: „Zapomnij o HTTP/3 dla tej strony – korzystaj znowu z HTTP/2.”

W konfiguracji nginx wyglądało to tak:

*listen 443 ssl http2;  
add_header Alt-Svc „clear” always;*

Od tego momentu strona natychmiast działała stabilnie na wszystkich urządzeniach, we wszystkich przeglądarkach i na wszystkich komputerach chronionych przez AVG.

## Czego można się z tego nauczyć

To doświadczenie było istotne nie tylko dla nas, lecz potencjalnie także dla tysięcy innych operatorów stron. Podczas naszego researchu szukaliśmy wcześniej przyczyny problemu przez Google i omawialiśmy problem także z różnymi silnikami odpowiedzi AI, ale HTTP/3 jako przyczyna takiego problemu przy korzystaniu z AVG w połączeniu z przeglądarką Firefox najwyraźniej nie był jeszcze nigdzie publicznie udokumentowany. Co ciekawe, to właśnie kombinacja AVG i Firefoksa jest prawdopodobnie jednym z kluczowych problemów. Omówiłem ten problem z moją żoną, która w gimnazjum z internatem w Torgelow uczy matematyki i ekonomii, a ona przekazała mi, że na lekcje ekonomii również otwiera z uczniami pewną stronę internetową … zawsze ze wskazówką, aby nie otwierać jej w Firefoksie, ponieważ występują problemy z wyświetlaniem i ładowaniem, których nie ma w Edge ani Chrome. Zakładam, że operatorzy tych stron po prostu nic o tym nie wiedzą.

Kto dziś aktywuje HTTP/3, ryzykuje, że określone rozwiązania zabezpieczające będą niezauważenie blokować treści – szczególnie w środowisku Windows, Firefoksa i systemów antywirusowych z ochroną WWW (np. AVG, Avast, …).

Także tutaj dostawcy rozwiązań zabezpieczających muszą zmienić podejście. Obecnie ok. 36 procent wszystkich stron internetowych korzysta z HTTP/3. Zobacz tutaj zrzut ekranu z https://w3techs.com/technologies/overview/site_element

    
        
            
                
                    

![Prozentuale Nutzung von Site Elementen nach w3techs.com](https://4eck-media.de/wp-content/uploads/2025/11/site-elements-websites-w3techs-1920x1080.avif "site-elements-websites-w3techs")
                
            
        
    

**Kilka praktycznych wskazówek:**

- Obrazy błędów, takie jak ERR_QUIC_PROTOCOL_ERROR czy NS_ERROR_NET_PARTIAL_TRANSFER, często wskazują na problemy z HTTP/3/QUIC.
- W Firefoksie można to sprawdzić w  
about:config → network.http.http3.enabled = false.
- Po stronie serwera można to tymczasowo przetestować, wyłączając HTTP/3 i wysyłając Alt-Svc: clear.

W razie potrzeby można później ponownie celowo aktywować HTTP/3 – ale tylko wtedy, gdy jest pewne, że żadne oprogramowanie ochronne nie ingeruje już w komunikację UDP.

## Podsumowanie: HTTP/3 i AVG

To nie kod, nie hosting i nie CMS, lecz kombinacja nowoczesnego protokołu i nadmiernie ostrożnej ochrony antywirusowej sprawiła, że strona zaczęła się chwiać. Nasz wniosek: innowacje wydajnościowe, takie jak HTTP/3, są świetne, ale w praktyce trzeba sprawdzić, czy naprawdę wszystkie ogniwa łańcucha są na nie gotowe. Gdyby nasz klient sam nie korzystał z AVG, szczerze mówiąc, w ogóle byśmy tego nie zauważyli. Nawet jeśli ostatecznie problemy z ładowaniem dotknęłyby tylko promil użytkowników, i tak jest to irytujące.

Dzięki gruntownej analizie naszego zespołu deweloperskiego strona schlosstorgelow.de działa teraz szybko, bezpiecznie i stabilnie. Dzielimy się tym wnioskiem, aby także inni deweloperzy stron, administratorzy i agencje szybciej doszli do celu, gdy wydarzy się coś podobnego.