At the end of this Invoke-WebRequest PowerShell proxy guide, you will know:
- What Invoke-WebRequest is
- How to use it on Windows, macOS, and Linux.PowerShellis
- What you need to know before using a proxy in PowerShell.
- How to specify an HTTP proxy in Invoke-WebRequest.
- How to deal with HTTPS and SOCKS proxies.
- Tips and tricks to use proxies in PowerShell like a pro.
- Which type of proxy you should choose.
Let’s dive in!
What Is PowerShell Invoke-WebRequest?
Invoke-WebRequest is a PowerShell cmdlet for sending HTTP, HTTPS, and FTP requests to web servers and web services. By default, it automatically parses the response produced by the server and returns collections of forms, links, images, or other significant HTML elements.
Usually, it is used for accessing REST APIs, downloading files from the web, or interacting with web services. This is the basic syntax of an Invoke-WebRequest request:
Invoke-WebRequest [-Uri] <Uri> [-Method <WebRequestMethod>] [-Headers <IDictionary>] [-Body <Object>]
The key parameters to remember are:
- -Uri: The URI of the web resource to which the request is sent.
- -Method: The HTTP method to use for the request (e.g., GET, POST, PUT, DELETE). Invoke-WebRequest sends GET requests by default.
- -Headers: The additional HTTP headers to include in the request.
- -Body: The body of the request to send to the server.
As you can see, the only required argument is <Uri>. Thus, in short, the simplest syntax to perform a GET request to a given URI is:
Invoke-WebRequest <Uri>
This cmdlet was introduced in PowerShell 3.0, in 2012.
Installing Invoke-WebRequest
To use Invoke-WebRequest, you need PowerShell. So, let’s learn how to install PowerShell and get access to the Invoke-WebRequest cmdlet!
Windows
First, you need to understand that Windows PowerShell and PowerShell are two different things. Windows PowerShell is the version of PowerShell that ships with Windows, and its latest version is 5.1. Windows Powershell provides the Invoke-WebRequest cmdlet. This means that if are on a modern Windows release, you are ready to go! For older versions, follow the official PowerShell installation guide.
At the same time, some features of Invoke-WebRequest are only available starting with PowerShell 7.x. For more details on how to install it, follow the official migration guide from Windows PowerShell 5.1 to PowerShell 7. Note that PowerShell 7.x installs to a new directory and runs side-by-side with Windows PowerShell 5.1.
You can verify the current version of PowerShell installed on your Windows machine with this command:
$PSVersionTable
On PowerShell 7.x, that should print something similar to:
PSVersion 7.4.1
PSEdition Core
GitCommitId 7.4.1
OS Microsoft Windows 10.0.22631
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
macOS and Linux
PowerShell 7.x can be installed on both macOS and Linux. However, it does not make much sense to install the entire PowerShell ecosystem in an OS just to access the Invoke-WebRequest cmdlet. Instead, you should use curl. This library comes preinstalled with macOS and most Linux distributions, offering the same capabilities as Invoke-WebRequest. Learn more in our curl proxy guide.
Prerequisites to Get Started with a Proxy in PowerShell
A proxy acts as an intermediary between a client and the destination server. It intercepts your requests, forwards them to the server, receives the responses from the server, and sends them back to you. This way, the destination server will see the requests as coming from the IP and location of the chosen proxy server and not from you.
To get started using a PowerShell proxy with Invoke-WebRequest, you need to understand what a proxy server URL looks like.
This is the URL of a PowerShell Invoke-WebRequest proxy:
<PROTOCOL>://[<USERNAME>:<PASSWORD>]@<HOST>[:<PORT>]
That consists of:
- <PROTOCOL>: The protocol to use to connect to the proxy server.
- <HOST>: The IP address or URL of the proxy server’s hostname.
- <PORT>: The port number the proxy server listens to.
- <USERNAME>: The optional username to specify when proxy authentication is required.
- <PASSWORD>: The optional password to specify when proxy authentication is required.
Note that the <PROTOCOL>:// part of the URL is required by Invoke-WebRequest. If you omit it, the request will fail with the following error:
Invoke-WebRequest : This operation is not supported for a relative URI.
As for proxy protocols, the most popular ones are HTTP, HTTPS, and SOCKS. Invoke-WebRequest in PowerShell 5.1 only supports HTTP while in PowerShell 7.x it also supports HTTPS and SOCKS.
Time to retrieve a valid HTTP proxy!
You can find one for free online, as below:
Protocol: HTTP; IP Address: 190.6.23.219; Port: 999
Compose that information to obtain the following proxy URL:
http://190.6.23.219:999
Warning
Opting for free proxies is okay for learning purposes, but you cannot rely on them in real-world scenarios. Free proxies are unreliable, error-prone, slow, data-greedy, and short-lived. Do not use them!
The solution? Premium proxies from Bright Data, the best provider in the market. Subscribe and try our reliable proxies for free.
Bright Data’s proxies are protected by authentication so that only trusted users can access them. Now, suppose the protocol is HTTP, host is 45.103.203.109, port is 9571, and the pair of credentials is admin-4521 and rUuH3tJqf. In this case, the Invoke-WebRequest proxy URL would be:
http://admin-4521:@rUuH3tJqf45.103.203.109:9571
How to Specify an HTTP Proxy in Invoke-WebRequest
Before getting started, launch the command below in PowerShell:
Invoke-WebRequest "https://httpbin.org/ip"
That should print something like:
StatusCode : 200
StatusDescription : OK
Content : {
"origin": "194.34.233.12"
}
RawContent : HTTP/1.1 200 OK
Connection: keep-alive
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Content-Length: 32
Content-Type: application/json
Date: Thu, 01 Feb 2024 10:46:14 GMT...
Forms : {}
Headers : {[Connection, keep-alive], [Access-Control-Allow-Origin, *], [Access-Control-Allow-Credentials,
true], [Content-Length, 32]...}
Images : {}
InputFields : {}
Links : {}
ParsedHtml : mshtml.HTMLDocumentClass
RawContentLength : 32
Focus on the Content field. That will contain your IP.
Why? Because the /ip endpoint from the HTTPBin project returns the origin IP of the request. In other words, it returns the IP address of the machine that performed the request. In this case, that is your machine’s IP.
If you want to access only the Content field, you can do it with:
$response = Invoke-WebRequest "https://httpbin.org/ip"
$response.Content
This would print:
{
"origin": "194.34.233.12"
}
If you route that request through a proxy, you should see the IP address of the proxy server and not yours. Calling that endpoint is therefore a good test to verify that the specified PowerShell Invoke-WebRequest proxy is working as expected.
There are a couple of ways to set a PowerShell proxy in Invoke-WebRequest. Find out more in the step-by-step guided sections below!
Using a Command Line Option
Invoke-WebRequest offers the -Proxy flag to specify a proxy URL for your request.
So, the syntax to use Invoke-WebRequest with a proxy server becomes:
Invoke-WebRequest -Proxy "<PROTOCOL>://[<USERNAME>:<PASSWORD>]@<HOST>[:<PORT>]" <Uri>
If you now execute this PowerShell command:
Invoke-WebRequest -Proxy "http://190.6.23.219:999" "https://httpbin.org/ip"
Invoke-WebRequest -Uri "http://httpbin.org/ip" -Proxy "http://brd.superproxy.io:22225" -ProxyCredential (New-Object System.Management.Automation.PSCredential("brd-customer-CUSTOMER_ID-zone-ZONE’S_NAME", ("ZONE’S_PASSWORD" | ConvertTo-SecureString -AsPlainText -Force)))
The result should be:
StatusCode : 200
StatusDescription : OK
Content : {
"origin": "190.6.23.219"
}
RawContent : HTTP/1.1 200 OK
Connection: keep-alive
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Content-Length: 31
Content-Type: application/json
Date: Thu, 01 Feb 2024 12:36:56 GMT...
Forms : {}
Headers : {[Connection, keep-alive], [Access-Control-Allow-Origin, *], [Access-Control-Allow-Credentials,
true], [Content-Length, 31]...}
Images : {}
InputFields : {}
Links : {}
ParsedHtml : mshtml.HTMLDocumentClass
RawContentLength : 31
Notice that the origin in Content matches the proxy server IP. This proves that the target server sees the request as coming from the proxy, as expected. Awesome!
Note: Do not forget that free proxies are short-lived! By the time you read this guide, it is unlikely that the above server is still alive. In case of an error, replace it with a fresh proxy.
Using Environment Variables
Since PowerShell 7.0, Invoke-WebRequest supports proxy configuration via environment variables.
Thus, another way to use a PowerShell proxy in Invoke-WebRequest is by setting the following two envs:
- HTTP_PROXY:The URL of the proxy server to use in case of HTTP requests.
- HTTPS_PROXY: The URL of the proxy server to use in case of HTTPS requests.
On Windows, you can set the two environment variables with this PowerShell syntax:
$env:HTTP_PROXY = "<PROTOCOL>://[<USERNAME>:<PASSWORD>]@<HOST>[:<PORT>]"
$env:HTTPS_PROXY = "<PROTOCOL>://[<USERNAME>:<PASSWORD>]@<HOST>[:<PORT>]"
In our example, the commands will become:
$env:HTTP_PROXY = "http://190.6.23.219:999"
$env:HTTPS_PROXY = "http://190.6.23.219:999"
On macOS and Linux, you need to use the syntax below:
export HTTP_PROXY="<PROTOCOL>://[<USERNAME>:<PASSWORD>]@<HOST>[:<PORT>]"
export HTTPS_PROXY="<PROTOCOL>://[<USERNAME>:<PASSWORD>]@<HOST>[:<PORT>]"
So, the two commands will be:
export http_proxy="http://190.6.23.219:999"
export https_proxy="http://190.6.23.219:999"
From now on, every Invoke-WebRequest request will go through the specified proxies without having to add the -Proxy option. After setting the envs, launch the command below:
Invoke-WebRequest "https://httpbin.org/ip"
You will get the same result as before:
StatusCode : 200
StatusDescription : OK
Content : {
"origin": "190.6.23.219"
}
RawContent : HTTP/1.1 200 OK
Connection: keep-alive
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Content-Length: 31
Content-Type: application/json
Date: Thu, 01 Feb 2024 12:36:56 GMT...
Forms : {}
Headers : {[Connection, keep-alive], [Access-Control-Allow-Origin, *], [Access-Control-Allow-Credentials,
true], [Content-Length, 31]...}
Images : {}
InputFields : {}
Links : {}
ParsedHtml : mshtml.HTMLDocumentClass
RawContentLength : 31
To turn off the Invoke-WebRequest proxies, unset the environment variables with:
$env:HTTP_PROXY = ""
$env:HTTPS_PROXY = ""
Or on macOS and Linux:
unset HTTP_PROXY
unset HTTPS_PROXY
Invoke-WebRequest will go back to its standard behavior, and https://httpbin.org/ip will now expose your IP.
How To Use HTTPS and SOCKS Proxies in PowerShell
If you need to use an HTTPS or SOCKS proxy, you must upgrade to version 7.x+ of PowerShell. Otherwise, Invoke-WebRequest will fail with:
Invoke-WebRequest : The ServicePointManager does not support proxies with the https scheme.
Or in the case of a SOCKS proxy:
Invoke-WebRequest : The ServicePointManager does not support proxies with the socks scheme.
When dealing with HTTPS or SOCKS proxies in PowerShell 7.x, the Invoke-WebRequest command structure remains the same:
Invoke-WebRequest -Proxy "<PROTOCOL>://[<USERNAME>:<PASSWORD>]@<HOST>[:<PORT>]" <Uri>
What changes is that <PROTOCOL> will be https, socks4, socks4a, socks5, or socks5a, instead of http.
If you try to invoke a request with a proxy involving a protocol other than those mentioned above, you will get this error:
Invoke-WebRequest: Only the 'http', 'https', 'socks4', 'socks4a' and 'socks5' schemes are allowed for proxies.
Thus, a complete example of an Invoke-WebRequest SOCKS proxy request is:
Invoke-WebRequest -Proxy "socks5://94.14.109.54:3567" "http://httpbin.org/ip"
As you can expect, the result will be:
StatusCode : 200
StatusDescription : OK
Content : {
"origin": "94.14.109.54"
}
RawContent : HTTP/1.1 200 OK
Connection: keep-alive
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Content-Length: 31
Content-Type: application/json
Date: Thu, 01 Feb 2024 12:47:56 GMT...
Forms : {}
Headers : {[Connection, keep-alive], [Access-Control-Allow-Origin, *], [Access-Control-Allow-Credentials,
true], [Content-Length, 31]...}
Images : {}
InputFields : {}
Links : {}
ParsedHtml : mshtml.HTMLDocumentClass
RawContentLength : 31
Tips and Tricks You Need to Know
See some useful tricks and valuable tips for dealing with a PowerShell Invoke-WebRequest proxy like a pro.
Ignore the PowerShell Proxy Configuration
If you want to prevent Invoke-WebRequest from using the configured PowerShell proxy read from the environment variables, you can use the -NoProxy option as follows:
Invoke-WebRequest -NoProxy <Uri>
This instructs Invoke-WebRequest to contact <Uri> without using a proxy.
To verify that this approach works, set up a proxy in the envs and run:
Invoke-WebRequest -NoProxy "https://httpbin.org/ip"
The resulting origin will contain your IP, not that of the proxy server.
Avoid SSL Certificate Errors
When using HTTP proxies, your requests may fail because of SSL certificate errors. To avoid that, specify the -SkipCertificateCheck option:
Invoke-WebRequest -SkipCertificateCheck -Proxy "<PROTOCOL>://[<USERNAME>:<PASSWORD>]@<HOST>[:<PORT>]" <Uri>
-SkipCertificateCheck helps you avoid certificate errors by allowing insecure server connections. Keep in mind that using this parameter is not secure. Set it only when dealing with known hosts.
For example, you can contact HTTPBin through a proxy while bypassing SSL issues with:
Invoke-WebRequest -SkipCertificateCheck -Proxy "http://190.6.23.219:999" "https://httpbin.org/ip"
Which PowerShell Proxy Should You Use?
The answer to this question changes based on what you want to achieve with your Invoke-WebRequest request. To find the right PowerShell proxy for your needs, take a look at the different types of proxies available:
- Datacenter proxies: They are fast and cheap, but can be easily detected and blocked by sites because of their identifiable IP ranges.
- Residential proxies: They offer rotating genuine IP addresses from real devices in specific locations. This means they can guarantee a high level of anonymity. Residential proxies are perfect for accessing sites that rely on geo-restriction blocks or to avoid anti-bot measures.
- ISP proxies: They are secure, fast, and highly reliable as they provide static IPs from devices registered with ISPs. ISP proxies are also called residential static proxies and are a perfect solution for SEO monitoring and market research.
- Mobile proxies: They provide IPs from real mobile devices for a high level of anonymity. They are useful for accessing applications, sites, or content specifically designed for mobile devices.
This was just a brief summary, but you can read more in our guide to proxy IP types.
Conclusion
In this PowerShell proxy guide, you learned what Invoke-WebRequest is, how it works, and how to use it with an HTTP/HTTPS/SOCKS proxy. As it turned out, you cannot rely on proxies from free providers. Therefore, the only decision to be made is which proxy provider you should adopt. Save time and energy and go directly for the best on the market, Bright Data.
Bright Data controls the best proxy servers in the world, serving Fortune 500 companies and over 20,000 customers. Its worldwide proxy network involves:
- Datacenter proxies – Over 770,000 datacenter IPs.
- Residential proxies – Over 72M residential IPs in more than 195 countries.
- ISP proxies – Over 700,000 ISP IPs.
- Mobile proxies – Over 7M mobile IPs.
Overall, that is one of the largest and most reliable scraping-oriented proxy networks on the market.
No credit card required