Test Chrome Local Network Access with an HTTPS Tunnel

Why direct local requests and tunnel requests behave differently

A browser request can reach the same application through two materially different network paths. In the direct path, Chrome connects to a loopback name such as localhost, a loopback IP address, or an address on the local private network. In the tunnel path, Chrome connects to a public HTTPS origin. The Localtonet relay then carries that traffic through the outbound connection established by the Localtonet client and forwards it to the application running on or reachable from the client device.

The application behind both paths may be identical, but the browser-facing destination is not. Chrome makes security decisions using details such as the initiating page's origin, the destination origin, the security context, the requested method and headers, and whether the destination is considered local or private from the browser's perspective. Changing the destination from a private address to a public HTTPS URL can therefore change which browser checks apply before the request reaches the application.

This makes an HTTP tunnel useful as a diagnostic control. If a request fails when a page calls a LAN address directly but succeeds when the same application is reached through a Localtonet public HTTPS address, the comparison points toward a browser-facing network boundary. It does not prove that one specific Chrome feature is responsible. You must still inspect the console, request details, preflight traffic, response headers, and server logs to distinguish Local Network Access behavior from CORS, mixed content, DNS, authentication, and application failures.

Understand the four boundaries before testing

Several independent browser protections can produce similar symptoms. A useful test keeps them conceptually separate. Otherwise, a CORS rejection may be mislabeled as a local-network permission issue, or a mixed-content block may be mistaken for a tunnel failure.

Origin boundaries

A web origin is generally defined by its scheme, host, and port. Two URLs are cross-origin if one of those components differs. A page loaded from a public HTTPS site and an API reached through a different public HTTPS hostname are still separate origins. Moving the API behind a public tunnel does not automatically make it same-origin with the calling page.

The same rule applies during local development. A page and API can both run on the same computer yet still be cross-origin because they use different ports, hostnames, or schemes. Conversely, a reverse proxy can present multiple backend services through one browser-facing origin. Record complete URLs in your test notes rather than labeling them only as “local” or “remote.”

Local Network Access controls

Chrome's Local Network Access work addresses requests from web content to destinations associated with the user's local environment. Depending on the Chrome version and configuration, browser enforcement may involve permission behavior or request restrictions. The exact user interface and enforcement state should be verified against the current browser release rather than assumed from an older article or screenshot.

These controls are not the same as CORS. Local-network checks concern the relationship between the browser context and the destination's network location. CORS concerns whether script running at one origin is permitted to read a response from another origin. A request can encounter both categories of checks.

Secure contexts and mixed content

An HTTPS page attempting to use an insecure HTTP endpoint can run into mixed-content rules before the application handles the request. Loopback origins may receive special treatment in some web-platform contexts, but developers should not generalize that treatment to arbitrary LAN addresses or assume that it remains identical across browser versions.

A Localtonet HTTP tunnel provides a public HTTPS address for the configured local HTTP service. This changes the browser-facing scheme and destination. It does not modify the local application itself, and it does not guarantee that every browser request will succeed. Cross-origin policy, authentication, application routing, cookies, and response headers can still affect the result.

CORS and preflight requests

For a cross-origin request, Chrome may send an OPTIONS preflight before the intended request. Whether a preflight is required depends on the request method, headers, and content type. If the server does not handle the preflight correctly, the browser can block the scripted request even though navigating directly to the endpoint works.

A tunnel does not remove CORS. When JavaScript calls the public tunnel URL from another origin, the application still needs an appropriate cross-origin policy. The browser evaluates the response as coming from the tunnel's public origin. If credentials are involved, wildcard policies and credentialed-request rules require particular care.

Prepare a controlled Chrome test environment

Start with a small endpoint whose behavior you understand. A health route returning a short response is better than a complex application page because it reduces unrelated variables. The service must listen on a local IP address and port reachable from the device running the Localtonet client. Do not copy a sample port from an unrelated tutorial. Use the actual port on which your application is listening.

You also need a Chrome version representative of the environment you are investigating. Record whether it is stable, beta, development, or managed by an organization. Browser policy can affect permissions and network access, so a managed workstation may behave differently from a personal test machine.

Prepare the following before running the matrix:

• The exact local service URL, including scheme, hostname or IP address, port, and path.
• A simple endpoint that can be requested safely without changing data.
• Access to the application's request logs or equivalent diagnostics.
• Chrome DevTools, with the Console and Network panels available.
• The Localtonet client installed on a device that can reach the service.
• A device-specific Localtonet authentication token selected through the normal account workflow.
• An available Localtonet relay server or region selected from the current dashboard.
• A separate calling page if the workflow specifically involves JavaScript making a cross-origin request.

Record the variables you will hold constant

For a meaningful comparison, keep the method, request body, custom headers, credentials mode, and application route the same. Change only the destination URL first. If you change the endpoint, authentication, browser profile, and request headers at the same time, the result will not isolate the local-network boundary.

Browser navigation and JavaScript fetches are not equivalent tests. A URL can load successfully in a tab while a script from another origin cannot read it. Plan to test both when the real workflow includes frontend code.

Establish the direct local baseline

Test the application locally before introducing Localtonet. This confirms that the service is running and gives you a known response to compare with the tunnel result.

Verify the service outside the browser workflow

Use the application's own health check, a trusted local HTTP client, or a direct browser navigation to confirm that the endpoint answers on the expected local address and port. Record the status code, response body, and any relevant response headers. If the service does not work directly on its host, creating a tunnel will not repair it.

Pay attention to which interface the service uses. An application bound only to a specific interface may be reachable through one hostname but not another. The Localtonet client must be able to connect to the exact local target configured for the tunnel.

Test direct navigation

Open the local URL directly in Chrome. Keep DevTools open and preserve the network log if redirects are expected. Direct navigation answers a narrow question: can Chrome navigate to the endpoint from this device? It does not by itself prove that a public page can call the same endpoint through JavaScript.

Test the real calling context

Next, load the page that normally initiates the request and reproduce the operation. If the initiating site is public HTTPS and the destination is localhost or a private-network address, this is the test most likely to expose the browser-facing boundary discussed in this guide.

You can use a minimal request pattern in your own test page, replacing the placeholder with your actual endpoint:

const targetUrl = "LOCAL_SERVICE_URL";

fetch(targetUrl, {
  method: "GET"
})
  .then(async response => {
    console.log("Status:", response.status);
    console.log("Body:", await response.text());
  })
  .catch(error => {
    console.error("Request failed:", error);
  });

Do not add custom headers merely to make the test look realistic. Custom headers can trigger a preflight and introduce another variable. Begin with the simplest request that represents useful application behavior, then add methods, headers, request bodies, and credentials one at a time.

Capture baseline evidence

Record whether Chrome displayed a permission prompt, whether the request appeared in the Network panel, whether an OPTIONS request occurred, and whether the application logged either the preflight or intended request. Also capture the exact console message. The same visible symptom, such as a failed button action, can correspond to very different network evidence.

Create the public HTTPS comparison path with Localtonet

With Localtonet, the client application on the device establishes an outbound connection to one of our relay servers. An HTTP tunnel points to a local IP address and port on, or reachable from, that client device. The resulting public HTTPS address becomes the browser-facing endpoint.

This workflow does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address. It also does not convert the application into a public service permanently. The endpoint is available only while the selected Localtonet client is connected and the tunnel is running.

For the maintained product workflow, consult our Localtonet documentation. Exact dashboard availability, server choices, plan-specific options, and domain requirements can change, so the current dashboard remains authoritative for those selections.

Run a test matrix that isolates the failure

A useful matrix starts simple and adds complexity gradually. Use a fresh Network recording for each case, label the result, and note which requests reached the application. Avoid treating one successful navigation as proof that every JavaScript workflow will work.

Interpret common result patterns

If direct navigation and tunnel navigation both fail, inspect the local service first. The process may not be running, the route may be wrong, or the configured local target may be unreachable from the Localtonet client.

If direct navigation works but the direct scripted request fails, inspect the initiating page's scheme and origin, Chrome's permission or local-network diagnostics, mixed-content messages, and CORS evidence. Successful navigation does not grant a different origin permission to read the response.

If the direct scripted request fails but the tunnel scripted request succeeds, the change in browser-facing destination is relevant. The result is consistent with a local-network or insecure-destination boundary, but confirm the exact cause from DevTools rather than inferring it solely from success through the tunnel.

If tunnel navigation works but the tunnel scripted request fails, the Localtonet route is probably reaching the application. Focus next on CORS, preflight handling, credentials, cookies, authorization, and frontend configuration.

If the tunnel request reaches the application but produces a different route or redirect behavior, inspect assumptions about hostnames, schemes, callback URLs, and trusted hosts. Do not weaken global host or origin validation merely to make a test pass. Add only the specific public origin needed for the controlled test, using the framework's documented configuration.

Use Chrome DevTools to identify the failing layer

Open DevTools before reproducing the request. Enable preservation of the Network log when redirects or page navigation would otherwise clear useful evidence. Filter by the endpoint path and inspect both the intended request and any preceding OPTIONS request.

Start with the Console

Console messages often identify whether Chrome blocked mixed content, rejected a cross-origin response, encountered a permission issue, or failed at the network layer. Copy the complete message into your test notes. Do not reduce every browser-generated “blocked” message to CORS, because Chrome uses different enforcement systems.

Inspect the Network panel

Determine whether the intended request exists. If it does, record the request URL, method, status, initiator, request headers, and response headers. If an OPTIONS request appears first, inspect it independently. A failed preflight can prevent the intended request from ever being sent.

When no request appears, the browser may have stopped the operation before ordinary network dispatch, or the application code may not have initiated it. Check the Console and add temporary logging immediately before the request in the calling code.

Correlate browser evidence with application logs

Browser and server observations should agree. If Chrome reports a failed request but the server logs a successful response, a browser policy may be preventing script from reading that response. If the server has no request entry, look earlier in the chain: browser enforcement, DNS, connection establishment, tunnel status, or preflight failure.

For the tunnel path, verify three separate states:

• The selected Localtonet client is connected.
• The HTTP tunnel has been started and is running.
• The local application receives the forwarded request.

A tunnel configuration can exist without being active. That lifecycle distinction is important when a previously working public URL stops responding after a device restart or client disconnect.

Keep preflight and intended requests separate

An OPTIONS response must satisfy the browser's policy for the intended method and requested headers. A successful status alone is not always enough. Inspect the relevant cross-origin response headers and confirm that they match the actual initiating origin and request shape.

Avoid solving a narrow development problem by returning an unrestricted cross-origin policy everywhere. Configure only the origins, methods, headers, and credential behavior the application needs. If the application framework offers a documented CORS component, use it rather than creating inconsistent headers in multiple routes.

Expose the test service with least privilege

A public HTTPS tunnel is useful for remote browsers, mobile devices, webhooks, and compatibility testing, but it changes who can potentially reach the service. Treat the assigned address as public, even if it is shared only with a small test group.

Review how the application handles cookies and credentials at the public origin. Cookies scoped to localhost will not automatically belong to the tunnel hostname. Secure and same-site cookie behavior can also differ when the calling origin changes. Diagnose those differences explicitly rather than disabling browser protections.

Never place a Localtonet device token in frontend code. The browser only needs the assigned public service URL. The Localtonet client and account workflow handle the device identity used to run the tunnel.

Troubleshooting checklist

The public HTTPS URL does not load

First confirm that the local application still works on the configured target. Then confirm that the Localtonet client is connected and the tunnel has been started. Creating the tunnel record is not enough. Verify that the local IP address and port match the service that you tested directly.

If the client is running on another device, confirm that device can reach the target over the relevant network path. Do not assume that a service reachable from your workstation is also reachable from the machine running the Localtonet client.

The tunnel opens in a tab, but fetch still fails

This pattern usually directs attention toward browser policy rather than basic reachability. Look for an OPTIONS request and inspect the Console for a CORS message. Confirm that the application permits the exact initiating origin. The local URL and public tunnel URL are different origins, so a policy written only for the local development origin may need an explicit, narrow update.

The preflight succeeds, but the real request fails

Compare the intended request with the preflight declaration. Check application authorization, route support, request body parsing, and server logs. A preflight only determines whether the browser may attempt the request. It does not guarantee that the application's business logic will accept it.

The response is a redirect or unexpected HTML

Inspect the redirect chain and final URL. Authentication middleware may be redirecting API calls to a login page, or the application may be generating URLs based on assumptions about the original scheme and hostname. Fix the application's documented proxy or public-origin configuration rather than hardcoding a workaround into the browser test.

The request works without credentials but fails with them

Credentialed cross-origin requests involve additional CORS and cookie constraints. Verify that the frontend intentionally requests credentials, the server intentionally allows them for the exact origin, and the cookie attributes fit the public HTTPS context. Do not use a wildcard origin as a shortcut for a credentialed workflow.

The direct local test differs across Chrome installations

Compare browser versions, release channels, profiles, extensions, site permissions, and enterprise management. Because Local Network Access behavior evolves, a test result from one Chrome release should not be generalized to every user. Reproduce the matrix in the browser environment that matters for the deployment.

The browser reports a local-network issue even though CORS is configured

CORS configuration does not necessarily grant local-network permission. Treat the two boundaries separately. Capture the exact Chrome message, verify current Chrome Platform Status information, and check whether the initiating context meets current secure-context and permission requirements.

The tunnel test succeeds, but production architecture should remain private

Treat the tunnel result as diagnostic evidence, not an automatic architecture decision. You may decide to keep the service private and redesign the calling flow so that a trusted backend communicates with it, or use an approved private networking approach. Localtonet also provides VPN Manager for private mesh networking, but standard HTTP tunneling itself is not a VPN.

Frequently asked questions