|
| 1 | +--- |
| 2 | +title: Troubleshoot HTTP 0 Responses and Blocked Calls |
| 3 | +description: Diagnose and fix Power Apps and Power Automate calls that fail and return HTTP 0, proxy errors such as 403 or 502, or canceled requests. |
| 4 | +ms.reviewer: jelopezf, v-shaywood |
| 5 | +ms.date: 06/04/2026 |
| 6 | +ms.custom: sap:Connections\Connection errors |
| 7 | +--- |
| 8 | + |
| 9 | +# Troubleshoot HTTP 0 responses and other blocked calls in Power Apps |
| 10 | + |
| 11 | +_Applies to:_ Power Apps, Power Automate |
| 12 | + |
| 13 | +## Summary |
| 14 | + |
| 15 | +This article helps you investigate Power Apps and Power Automate calls that don't reach the service or that return an error from an intermediary device. Typical failures include an HTTP status of `0`, a proxy-issued status such as `403`, `407`, `502`, or `503`, and a request that's marked as `(failed)` or `(canceled)`. Learn how to tell whether the failure originates on the client side or in the network path, capture the right diagnostics, and work with your network team on a fix. |
| 16 | + |
| 17 | +## Symptoms |
| 18 | + |
| 19 | +A connector or web request fails before the Power Platform service can return a successful response. The failure is often intermittent and creates one of the following conditions: |
| 20 | + |
| 21 | +- An HTTP status code of `0` in the Power Apps [Live Monitor](/power-apps/maker/monitor-overview) tool, in flow run history, or in browser developer tools. The response typically contains no body, no headers, and no meaningful error message. |
| 22 | +- A request that has a displayed status of `(failed)` or `(canceled)` on the **Network** tab of browser developer tools. |
| 23 | +- An HTTP status that's returned by an intermediary device (for example, a Zscaler, Netskope, or corporate proxy block page) instead of by Power Platform. For example: |
| 24 | + |
| 25 | + - `403 Forbidden` |
| 26 | + - `407 Proxy Authentication Required` |
| 27 | + - `502 Bad Gateway` |
| 28 | + - `503 Service Unavailable` |
| 29 | + |
| 30 | +- Custom code that uses `fetch` or `XMLHttpRequest` and receives `status: 0` or a generic network error. |
| 31 | + |
| 32 | +All these symptoms share a common root pattern: The request is blocked or altered between the client device and the Power Platform service instead of being processed and rejected by the service itself. |
| 33 | + |
| 34 | +## Cause |
| 35 | + |
| 36 | +An HTTP status of `0` isn't an actual response from the server. It means that the browser or client never received a response from the remote endpoint. This condition usually occurs because the request was blocked, dropped, or terminated before it could complete a round trip. Proxy-issued statuses such as `403` or `407` mean something similar: An intermediary device intercepted the request and returned its own response instead of forwarding the request to Power Platform. |
| 37 | + |
| 38 | +Common causes include: |
| 39 | + |
| 40 | +- Transient network outages or unstable device connectivity (for example, Wi-Fi drops, VPN disconnections, or cellular handoffs) |
| 41 | +- Corporate proxies, firewalls, or SSL/TLS inspection devices that terminate, throttle, or silently drop the connection |
| 42 | +- Network appliances that rewrite or strip [CORS](https://developer.mozilla.org/docs/Web/HTTP/CORS) headers (for example, changing `Access-Control-Allow-Origin` to a restrictive value) and cause browser-side failures before the network call finishes |
| 43 | +- DNS resolution failures or DNS-based filtering that blocks the Power Platform service endpoint |
| 44 | +- Secure web gateway or zero-trust products (such as Zscaler or Netskope) that intercept Power Platform traffic and block it, rewrite it, or return a custom error page |
| 45 | +- Browser extensions (ad blockers, privacy tools) or local antivirus software that cancel the request before it's sent |
| 46 | +- Browser local-network protections that treat proxied traffic as local-resource access and block the request |
| 47 | +- The user navigating away, closing the tab, or putting the device to sleep before the request finishes |
| 48 | + |
| 49 | +> [!NOTE] |
| 50 | +> These failures originate on the client side or within your network path, not on the Power Platform service. Resolution usually requires coordination with your network administrator to identify why the request is blocked, redirected, or losing connectivity. |
| 51 | +
|
| 52 | +## Determine the source of the problem |
| 53 | + |
| 54 | +### Verify that the request reaches the network |
| 55 | + |
| 56 | +Use your browser's developer tools to inspect the failing call: |
| 57 | + |
| 58 | +1. In the browser, press <kbd>F12</kbd> to open developer tools, and select the **Network** tab. |
| 59 | +1. Reproduce the issue in the app or flow. |
| 60 | +1. Locate the failing request. Look for responses that match one or more of the following indicators: |
| 61 | + |
| 62 | + - Status `0`, `(failed)`, or `(canceled)` |
| 63 | + - A `403`, `407`, or `502` response that doesn't resemble a Power Platform response |
| 64 | + |
| 65 | +1. Select the request, and examine the **Headers** section. Closely examine the **Remote Address** field. Also, review the response body for any indication that the request came from a proxy or security appliance instead of the service. |
| 66 | + |
| 67 | +For "4*xx*" and "5*xx*" responses, inspect response headers for Power Platform service markers such as `x-ms-correlation-id` or `x-ms-request-id` (with GUID values): |
| 68 | + |
| 69 | +- If at least one valid `x-ms-*` request/correlation header is present, the request likely reached the service and was rejected there. |
| 70 | +- If these headers are missing, and the response resembles a proxy or gateway page, an intermediary network device likely generated the response. |
| 71 | + |
| 72 | +If you engage Microsoft Support, include any `x-ms-correlation-id` or `x-ms-request-id` values that you captured. These identifiers help correlate the request with service telemetry. |
| 73 | + |
| 74 | +The **Remote Address** field is one of the clearest signals: |
| 75 | + |
| 76 | +- If the field shows an IP address and port (for example, `192.0.2.10:443`), the request reached a remote server. The failure is then more likely a TLS, CORS, or service-side issue. |
| 77 | +- If the field shows **only a port** (such as `:443` or `:80`) together with **no IP address**, the connection was blocked, intercepted, or short-circuited before it left the device or local network. That strongly suggests that a proxy, firewall, DNS filter, or security agent (such as Zscaler) is handling the request locally instead of forwarding it. The same pattern often appears alongside a proxy-issued `403` or `407` response. |
| 78 | + |
| 79 | + :::image type="content" source="media/troubleshoot-http-0-responses/remote-address-no-ip.png" alt-text="Screenshot of a failed network request in browser developer tools showing the Remote Address field that includes only a port and no IP address."::: |
| 80 | + |
| 81 | +Capture an [HAR file](/azure/azure-portal/capture-browser-trace) of the session so that you can share it with your network team. |
| 82 | + |
| 83 | +### Rule out device and connectivity problems |
| 84 | + |
| 85 | +Before you engage your network team, rule out basic device and connectivity problems: |
| 86 | + |
| 87 | +- Reproduce the problem on a different network (for example, a mobile hotspot) to check whether the problem follows the user, the device, or the corporate network. |
| 88 | +- Try a different browser, or use an InPrivate or Incognito window by having extensions disabled. |
| 89 | +- Verify that the device has a stable connection and isn't suspending Wi-Fi for power management. |
| 90 | +- Test from a different device on the same network to isolate device-specific problems. |
| 91 | + |
| 92 | +If the call succeeds on an alternative network but fails on the corporate network, the problem is almost certainly in the corporate network path. |
| 93 | + |
| 94 | +If failures affect users in only specific regions, also consider DNS response-size filtering by intermediary devices. Some Power Platform host name chains produce larger DNS answers (for example, because of CNAME expansion and geographic routing). Devices that enforce older DNS size assumptions from [RFC 1035](https://www.rfc-editor.org/rfc/rfc1035.txt) can block responses that are valid under [RFC 6891](https://www.rfc-editor.org/rfc/rfc6891.txt). The result is region-specific app load or connector failures. |
| 95 | + |
| 96 | +### Work with your network administrator |
| 97 | + |
| 98 | +The evidence might point to the corporate network. For example, you might notice missing remote IP, or that failures occur only on the corporate network, or that other users are affected. In these cases, engage your network administrator. Share the following information: |
| 99 | + |
| 100 | +- The HAR file that you captured earlier |
| 101 | +- The exact URLs of the failing requests (host name and path) |
| 102 | +- The approximate time, user, and device where the issue occurred |
| 103 | + |
| 104 | +Ask your network team to verify the following conditions: |
| 105 | + |
| 106 | +- All required Power Platform endpoints are allowed end-to-end through proxies, firewalls, and SSL inspection devices. The authoritative list of host names and IP ranges is at [Power Platform URLs and IP address ranges](/power-platform/admin/online-requirements). |
| 107 | +- DNS resolves Power Platform endpoints correctly. |
| 108 | +- Allowlist rules cover dynamic host names and subdomains. Power Platform requests can use long, environment-specific host names under service domains instead of a single fixed host. A rule that allows only a previously observed subdomain can fail at the next routing change, even though no app logic changed. |
| 109 | +- CORS headers returned by Power Platform are preserved end-to-end. Header rewrite or removal can cause browser-level failures (including HTTP status `0`), even if endpoint allow-listing is otherwise correct. |
| 110 | +- Inspection devices support larger DNS responses and EDNS behavior. This condition is especially important if failures are concentrated by region or office location. |
| 111 | +- Secure all allowlist Power Platform host names in web gateways (Zscaler, Netskope, or similar), and protect them from SSL/TLS inspection. SSL inspection is a frequent root cause of HTTP `0` responses and unexpected `403` or `502` errors. The inspection device can break long-lived or chunked connections that the connector runtime relies on. It can also return its own block page if a policy match occurs. |
| 112 | + |
| 113 | +If you suspect browser local-network protections, review the relevant browser guidance. For Chromium, see [Private Network Access: introducing preflights](https://developer.chrome.com/blog/private-network-access-preflight). |
| 114 | + |
| 115 | +### Collect additional diagnostics |
| 116 | + |
| 117 | +If the issue persists after the network team verifies the configuration: |
| 118 | + |
| 119 | +- Capture a network trace (for example, with [Wireshark](https://www.wireshark.org/) or `pktmon` on Windows) during a failing call. |
| 120 | +- Use the Power Apps Live Monitor tool to verify whether the failure is consistent across requests or limited to specific connectors. |
| 121 | +- Review HAR entries for proxy-identifying headers such as `Via`. |
| 122 | +- Look for protocol downgrade patterns, such as `HTTP/1.1` responses where you expect modern `HTTP/2`. Connector traffic should use modern HTTP. Therefore, repeated downgrades often indicate intermediary inspection or proxy fallback, and they can affect reliability and performance. |
| 123 | +- If a browser local-network access prompt appears, or if it appears that access was denied, collect that detail for the network team. Some proxy designs that use nonroutable or private address ranges can trigger local-network protections and block requests. |
| 124 | +- Note whether the failures correlate with specific times of day, specific users, specific geographic locations, or specific connectors. This information often helps your network team pinpoint the device or policy that's responsible. |
| 125 | + |
| 126 | +## Solution |
| 127 | + |
| 128 | +Your IT or network team usually makes most fixes. Share the HAR file and proxy logs that you captured, and then apply one or more of the following changes: |
| 129 | + |
| 130 | +- Allow the [Power Platform URLs and IP address ranges](/power-platform/admin/online-requirements) through all proxies, firewalls, and DNS filters. |
| 131 | +- Bypass SSL/TLS inspection for Power Platform host names on Zscaler, Netskope, or similar gateways. |
| 132 | +- Stabilize device connectivity (Wi-Fi, VPN, cellular) for affected users. |
| 133 | +- Review and reconfigure browser extensions or endpoint security products that cancel or rewrite requests to Power Platform endpoints. |
| 134 | + |
| 135 | +If the problems continue after you make these changes, collect updated traces, and continue to troubleshoot together with your networking and security teams. |
| 136 | + |
| 137 | +## Related content |
| 138 | + |
| 139 | +- [Troubleshoot broken connections in Microsoft Power Platform](../../power-automate/connections/troubleshoot-broken-connections.md) |
| 140 | +- [Managed connectors outbound IP addresses](/connectors/common/outbound-ip-addresses) |
| 141 | + |
| 142 | +[!INCLUDE [Third-party information disclaimer](../../../../includes/third-party-information-disclaimer.md)] |
0 commit comments