Błąd ERR_CACHED_IP_ADDRESS_SPACE_BLOCKED_BY_PRIVATE_NETWORK_ACCESS_POLICY – przyczyny i naprawa

Błąd ERRCACHEDIPADDRESSSPACEBLOCKEDBYPRIVATENETWORKACCESSPOLICY pojawia się w przeglądarce Chrome (i pochodnych) podczas prób połączenia z zasobem sieciowym, gdy polityka Private Network Access (PNA) blokuje dostęp do prywatnej przestrzeni adresowej IP z powodu niezgodnej konfiguracji sieciowej lub braku odpowiednich nagłówków CORS.

Co oznacza ten błąd?

Blokada wynika z tego, że przeglądarka wykrywa próbę uzyskania dostępu (np. przez XHR/fetch) z publicznej strony do zasobu znajdującego się w prywatnej sieci (adresy IP prywatne typowe dla lokalnych LAN: 10.x.x.x, 172.16.x.x–172.31.x.x, 192.168.x.x). Od niedawna mechanizmy w przeglądarkach wymagają specjalnych nagłówków i uwierzytelnienia takich zapytań. Celem jest zapobieganie zagrożeniom związanym z dostępem cross-origin do zasobów wewnętrznych (ochrona company LAN, API, IoT itp.).

• Brak nagłówka Access-Control-Allow-Private-Network: true w odpowiedzi na żądanie CORS do zasobu w prywatnej sieci.
• Nieprawidłowa konfiguracja zapory sieciowej (firewalla) lub sieci prywatnej – np. żądania kierowane są do adresu IP z nieautoryzowanego zakresu lub trasy routingu blokują przepływ ruchu.
• Próba dostępu z aplikacji hostowanej publicznie do prywatnych zasobów przez przeglądarkę, bez uwzględnienia obecnych polityk sieciowych Chrome/Edge.

• Webmasterów/deweloperów – Osób projektujących aplikacje webowe, które komunikują się z zasobami API lub backendami osadzonymi w sieciach prywatnych lub VPN.
• Administratorów systemów – Osób zarządzających zabezpieczeniami infrastruktury i konfiguracją sieci (np. w Microsoft Azure lub innych chmurach).
• Użytkowników końcowych – Którzy próbują korzystać ze stron używających zasobów wewnętrznych.

Dla webmastera/web dewelopera

1. Analiza komunikacji sieciowej

• Otwórz narzędzia deweloperskie w Chrome (F12) i przejdź do zakładki „Network”.
• Wyszukaj żądanie, które wywołuje błąd. Sprawdź request i response headers.

2. Weryfikacja źródła żądania

• Ustal, z jakiego adresu (hosta/IP) wysyłane jest żądanie i do jakiego adresu docelowego trafia. Jeśli żądasz z publicznego hostingu do zasobu w prywatnej sieci – napotkasz problem.

3. Skonfiguruj serwer docelowy

Aby umożliwić dostęp zgodnie z polityką PNA:

• Dodaj do odpowiedzi na żądanie preflight (OPTIONS) lub odpowiedzi CORS nagłówek:

 Access-Control-Allow-Private-Network: true 

• Upewnij się, że obecny jest również prawidłowy:

 Access-Control-Allow-Origin: <wartość z Origin> 

• Jeśli nie są wymagane żadne ograniczenia cross-origin, możesz dla testu dodać:

 Access-Control-Allow-Origin: * 

4. Zadbaj o obsługę zapytań preflight

• Serwer musi poprawnie obsługiwać zapytania typu OPTIONS, bo przeglądarka wyśle tzw. preflight przed właściwym żądaniem.

5. Skoryguj routing oraz reguły sieciowe

• W środowiskach chmurowych (np. Azure):
  • Zweryfikuj konfigurację Private Endpoints i połączenia VNet.
  • Sprawdź przypisanie adresów IP i tras w tablicach routingu subnetów prywatnych.
  • Upewnij się, że DNS rozwiązuje zasoby do właściwych, prywatnych adresów IP.
  • Jeśli korzystasz z firewalli (np. Azure Storage), dodaj odpowiednie hosty lub skorzystaj z opcji „Allow trusted services”/decyduj, czy dodać ręcznie adresy wyjściowe.

6. Przykładowe fragmenty kodu (back-end, Node.js/Express)

app.use((req, res, next) => { res.setHeader('Access-Control-Allow-Origin', req.headers.origin); res.setHeader('Access-Control-Allow-Private-Network', 'true'); res.setHeader('Access-Control-Allow-Methods', 'GET,POST,OPTIONS,PUT,DELETE'); res.setHeader('Access-Control-Allow-Headers', 'Content-Type,Authorization'); if (req.method === 'OPTIONS') { res.sendStatus(204); } else { next(); } }); 

Dla administratora infrastruktury/sieci

• Zweryfikuj mapowanie DNS – Czy nazwa endpointa rozwiązuje się do poprawnego (prywatnego) adresu IP.
• Sprawdź reguły firewalli i Network Security Groups – zezwól na ruch (inbound/outbound) w żądanym zakresie adresacji IP.
• Usuń konflikty w Route Table – ruta kierująca ruch nie powinna nadpisywać/kolidować z prywatnym endpointem.
• Dla Azure: Skonsultuj się z dokumentacją na temat [Private Link/Private Endpoint Troubleshooting].

Dla użytkownika końcowego

• Jeśli używasz aplikacji webowej wykorzystującej zasoby sieci lokalnej, powiadom administratora lub obsługę techniczną o komunikacie błędu.
• Nie możesz samodzielnie zmienić ustawień sieciowych aplikacji webowej; naprawa jest po stronie serwera lub dewelopera aplikacji.

Czy można „wyłączyć” tę blokadę w Chrome?
W środowiskach testowych (nieprodukcyjnych) można uruchomić Chrome z argumentem --disable-features=PrivateNetworkAccessChecksBypassSafetyChecks (niezalecane w produkcji ze względów bezpieczeństwa).

Czy VPN zmienia sytuację?
Tak, jeśli oba zasoby są w tej samej przestrzeni adresowej (np. przez VPN) – żądania nie będą przechodzić między publicznym a prywatnym IP, co może rozwiązać problem, o ile reszta infrastruktury na to pozwala.

Kiedy nagłówek Access-Control-Allow-Private-Network jest wymagany?
Przy próbie połączenia z publicznego origin do zasobu znajdującego się w przestrzeni adresowej określanej jako „private” przez przeglądarkę (czyli wewnętrzne IP).

Najczęstsze błędy podczas naprawiania

• Pominięcie nagłówka Access-Control-Allow-Private-Network: true.
• Ignorowanie żądań preflight (OPTIONS).
• Zła konfiguracja tras lub firewalli powodująca blokadę ruchu.
• Niezgodność adresacji rezultatów DNS (publiczny IP zamiast prywatnego endpointa).

Podsumowanie –
Naprawa błędu wymaga poprawnej obsługi polityk CORS z nowym nagłówkiem Access-Control-Allow-Private-Network: true na serwerze docelowym oraz zapewnienia, że konfiguracja sieci (firewall, DNS, routing) umożliwia autoryzowaną komunikację pomiędzy źródłem a zasobem w prywatnej przestrzeni IP.