PowerShell: web request failed
Documentation: Microsoft Learn
Separate HTTP status errors from DNS, proxy, TLS and timeout failures when a PowerShell web request fails.
What it means
The HTTP call did not produce a usable response. It may have died before any bytes moved, during the TLS handshake, or after the server answered with a 4xx or 5xx status. PowerShell 7 throws on those status codes while Windows PowerShell 5.1 wraps them in a WebException.
Likely causes
- The server answered 401 or 403 because a token or header was absent, wrong, or expired
- TLS negotiation failed because the client offered a protocol version the server no longer accepts
- The certificate chain does not validate, often an inspecting proxy re-signing traffic with its own root
- A proxy is required on this network and was never configured for the session
- The request timed out, or the host name does not resolve
Check
Run these checks before changing anything.
What these checks establish
A DNS or TLS failure may occur before an HTTP response exists, so Response or StatusCode can be absent. An HTTP 401, 403, 404, 429 or 5xx response instead indicates that an HTTP endpoint responded.
Fix
Separate name resolution, TCP, TLS and HTTP status. Preserve the response details when available without logging credentials. A server may reject HEAD while supporting GET, so use the method specified by the API. Check platform TLS configuration and approved proxy settings when evidence points there; do not disable certificate validation or alter protocol settings for every HTTP error.
Verify: Repeat the intended API operation, verify its status and required response fields, and confirm retries do not duplicate a state-changing request.
