How to resolve the “Failed to Fetch Data” or “Server Not Found” Errors in Bold BI Embedded Applications Due to Browser Private Network Access (PNA) Restrictions?

Overview

If your embedded application is hosted on a public network and communicates with a Bold BI instance hosted on a private network, dashboards may fail to load in Chrome, Microsoft Edge, and other Chromium-based browsers, displaying errors such as “Failed to Fetch Data”, “Server Not Found”, or a blank page.

This behavior is caused by Private Network Access (PNA) security restrictions, which prevent browsers from making requests from a public origin to private network resources. This article explains how to identify whether PNA restrictions are causing the issue and the steps required to resolve it.

What is Private Network Access (PNA)?

Private Network Access (PNA), also known as Local Network Access (LNA), is a browser security feature introduced in Chromium-based browsers such as Google Chrome and Microsoft Edge.

PNA is designed to prevent publicly accessible websites from directly accessing resources hosted on private or local networks. This helps protect users and internal systems from unauthorized access originating from websites on the public internet.

As a result, when an embedded application hosted on a public domain attempts to communicate with Bold BI services that resolve to private network addresses, the browser may block the requests. This can lead to dashboard loading failures, “Failed to Fetch Data” errors, “Server Not Found” errors, or failed API calls displayed in the browser’s developer tools.

Prerequisites

• Access to update your DNS / Ingress / Load Balancer configuration.
• Admin/DevOps permissions to review the Bold BI endpoint URLs used by your embedded application.

Understanding the Root Cause

Google Chrome, Microsoft Edge, and other Chromium-based browsers have introduced and continue to expand Private Network Access (PNA) and related local network security restrictions. As a result, requests from publicly accessible websites to resources hosted on private network addresses may be blocked depending on the browser version and security policies in effect.

In a typical affected deployment:

• The embedded application is accessed through a public domain.
• Requests originating from the browser are routed to Bold BI services hosted on private network addresses (VPC, internal subnet, private load balancer, etc.).
• Chrome and Edge identify the target as a private network resource and block the request.
• As a result, users may experience:
  • “Failed to Fetch Data”
  • “Server Not Found”
  • Blank dashboards
  • Failed API requests in the browser network console

Since this restriction is enforced by the browser itself, it cannot be resolved through Bold BI application settings alone. The deployment architecture must be updated so that all browser-facing requests are routed through publicly accessible endpoints.

Investigation and Resolution Steps

1. Verify whether the issue is caused by Private Network Access (PNA) restrictions.

   Before making configuration changes, confirm that the requests are being blocked by the browser due to PNA restrictions.

   Why this step is required:
   Similar symptoms can occur because of network connectivity, DNS, proxy, or application configuration issues. Verifying the browser behavior helps confirm whether PNA is the root cause.

   Steps:

   • Open the embedded application in Google Chrome or Microsoft Edge.
   • Press F12 and navigate to the Network tab.
   • Reload the page and review the failed Bold BI requests.
   • Look for errors such as:
     • ERR_FAILED
     • ERR_ADDRESS_UNREACHABLE
     • Blocked or failed fetch requests
   • Verify whether the same dashboard loads successfully when accessed directly through the Bold BI URL.
   • If the dashboard loads directly but fails when embedded, continue with the following steps.

2. Verify whether the Bold BI endpoint resolves to a private network address.

   Why this step is required:
   Browsers enforce PNA restrictions when a public application attempts to access resources hosted on a private network. Identifying whether the configured Bold BI endpoint resolves to a private IP helps confirm this scenario.

   Steps:

   • Identify the URL used by the embedded application to connect to Bold BI (typically the serverUrl).
   • Run a DNS lookup from the client machine or review the Remote Address value in the browser’s Network tab.
   • Check whether the resolved address belongs to a private IP range, such as:
     • 10.0.0.0/8
     • 172.16.0.0/12
     • 192.168.0.0/16
   • If the hostname resolves to a private IP address, or if the public hostname ultimately routes traffic through a private network endpoint, Chromium-based browsers may block the requests under PNA restrictions.

   Private Network IP Ranges Commonly Restricted by Browsers

   When investigating the issue, verify whether the Bold BI endpoint ultimately resolves to one of the following private or local network ranges:

   IP Range	Description
   10.0.0.0 - 10.255.255.255	RFC1918 Private Network
   172.16.0.0 - 172.31.255.255	RFC1918 Private Network
   192.168.0.0 - 192.168.255.255	RFC1918 Private Network
   127.0.0.0/8	Loopback
   169.254.0.0/16	Link-local
   100.64.0.0/10	Carrier-grade NAT
   fd00::/8	IPv6 Unique Local Address (ULA)
   fe80::/10	IPv6 Link-local

   Requests from a public website to endpoints that resolve to these addresses may be blocked by Chromium-based browsers under Private Network Access (PNA) restrictions.

3. Configure a publicly accessible endpoint for Bold BI.

   Why this step is required:
   To comply with browser security requirements, all browser-facing requests must be routed through a publicly reachable endpoint. Direct communication from the browser to private network addresses is not supported under PNA restrictions.

   Steps:

   • Configure a public-facing Ingress, internet-facing Load Balancer, or reverse proxy for Bold BI.
   • Update DNS so that the Bold BI hostname resolves to the public endpoint.
   • Ensure the public endpoint forwards requests internally to the Bold BI services.
   • Internal communication can remain on the private network; only browser-accessible endpoints must be publicly reachable.

4. Update the embedded application to use the public Bold BI URL.

   Why this step is required:
   Even after exposing a public endpoint, the issue will continue if the embedded application still references a private hostname or IP address.

   Steps:

   • Update the Bold BI serverUrl configuration to use the public URL.
   • Ensure that no private IP addresses or internal hostnames are referenced in the embedding configuration.
   • If scripts or style files fail to load after updating the URL, verify the embedding configuration using the following article:

5. Verify reverse proxy or load balancer settings.

   Why this step is required:
   Incorrect forwarding headers can cause redirect issues, incorrect URL generation, mixed-content errors, or HTTPS-related problems after introducing a public endpoint.

   Steps:

   • Validate that forwarded headers are configured correctly on the reverse proxy or load balancer.
   • Verify that requests are forwarded using the expected host and protocol values.
   • If you observe HTTPS redirection issues, refer to the following article:

6. Validate the configuration changes.

   Why this step is required:
   Final validation confirms that all browser requests are being routed through the public endpoint and that dashboards load successfully across supported browsers.

   Steps:

   • Clear the browser cache or perform a hard refresh.
   • Confirm that all Bold BI requests are being sent to the public hostname.
   • Verify that the requests complete successfully (HTTP 200/204 responses as applicable).
   • Confirm that dashboards render correctly across Chrome, Microsoft Edge, Firefox, and other supported browsers.

Browser Compatibility Considerations

Google Chrome, Microsoft Edge, and other Chromium-based browsers enforce Private Network Access (PNA) security restrictions that can block requests from a public website to resources hosted on private network addresses.

To avoid dashboard loading failures and ensure compatibility across browsers, all browser-facing Bold BI endpoints should resolve to publicly accessible URLs rather than private network addresses.

JavaScript Embedding: Ensure serverUrl Uses the Public Bold BI Endpoint

// Ensure serverUrl points to a PUBLIC endpoint that is accessible from the browser.
// Example:
// https://{public-domain}/bi/site/{tenantIdentifier}

Recommended Network Architecture

✅ Supported

User Browser
→ Public Application URL
→ Public Load Balancer / Ingress
→ Bold BI Services (Private Network)

❌ Not Supported

User Browser
→ Public Application URL
→ Private IP / Internal Load Balancer
→ Bold BI Services

References

• Chrome Private Network Access
• Chrome Release Notes
• Resolving “404 errors” for script and style files when Embedding Bold BI Dashboards
• How to resolve the HTTPS redirection issue in Bold BI when using it with an external load balancer