Quick Answer
cURL works with a proxy when you pass the proxy address to --proxy, or its shorter form, -x. Add --proxy-user when the proxy requires a username and password.
Replace the example hostname, port, username, and password with working proxy details. The command sends the HTTPS request through an HTTP proxy. cURL creates the required tunnel automatically.
Use https:// when the connection from cURL to the proxy must use Transport Layer Security (TLS). Use socks5h:// when a SOCKS5 proxy should resolve the destination hostname.
The examples use Bash and zsh syntax unless a section says otherwise. The executable remains lowercase: curl.
The examples follow the current cURL documentation for HTTP, HTTPS, and SOCKS5 proxies. Example hostnames remain placeholders because working credentials cannot be published.
Key Takeaways
- --proxy selects the proxy. The proxy URL should include its protocol, hostname, and port.
- The proxy protocol and destination protocol are separate. An HTTP proxy can carry an HTTPS request through a tunnel.
- An HTTPS proxy protects the proxy connection. cURL verifies the proxy certificate separately from the destination certificate.
- SOCKS5 has two name-resolution modes. socks5:// resolves locally, while socks5h:// sends the hostname to the proxy.
- Proxy authentication uses --proxy-user. The similar --user option sends credentials to the destination server instead.
- A successful command does not prove workload quality. Check the exit address, target response, latency, and content before relying on a proxy.
- Certificate checks should remain enabled. --insecure and --proxy-insecure belong in controlled diagnostics, not production commands.
Quick Comparison: cURL Proxy Formats
cURL proxy formats determine how cURL reaches the proxy and where SOCKS5 destination names are resolved.
| Proxy format | Connection from cURL to proxy | Destination name resolution | Common use |
|---|---|---|---|
| http://proxy.example.com:8080 | Plain HTTP | HTTP proxy normally resolves the destination | General web requests |
| https://proxy.example.com:8443 | TLS-encrypted HTTP | HTTPS proxy normally resolves the destination | Untrusted client-to-proxy networks |
| socks5://proxy.example.com:1080 | Plain SOCKS5 | cURL resolves the hostname locally | Applications that need local DNS behavior |
| socks5h://proxy.example.com:1080 | Plain SOCKS5 | Proxy resolves the hostname | Remote DNS and location-dependent resolution |
The destination URL still controls destination encryption. An https:// destination uses TLS even when the proxy URL begins with http:// or socks5h://.
What Is the Basic cURL Proxy Syntax?
cURL proxy syntax puts the proxy protocol, hostname, and port in --proxy, followed by the complete requested destination URL.
The shorter -x option does the same job:
According to the official cURL proxy documentation, cURL assumes an HTTP proxy when the scheme is missing. Writing the scheme and port explicitly makes the command easier to audit.
| Command part | Example | What it controls |
|---|---|---|
| Proxy scheme | http://, https://, or socks5h:// | Protocol used between cURL and the proxy |
| Proxy host | proxy.example.com | Proxy gateway or server |
| Proxy port | 8080 | Listening port on the proxy |
| Destination URL | https://example.com | Server and protocol cURL requests |
Do not change a proxy address from http:// to https:// merely because the destination uses HTTPS. The proxy scheme describes the proxy endpoint, not the website.
Do not rely on an implied port either. The HTTP proxy default is historically 1080, not 80. An HTTPS proxy without a port defaults to 443.
cURL also recognizes socks4:// and socks4a://. This guide stays with HTTP, HTTPS, and SOCKS5 because those formats cover the requested setups.
Check the installed build before using less common features:
The output lists the cURL version, TLS backend, protocols, and compiled features. An HTTPS proxy requires HTTPS-proxy in the feature list.
If you're using Proxidize, you don't need to construct the proxy endpoint manually. Create an access point in the dashboard, choose HTTP or SOCKS5, and copy the generated host, port, and authentication details into the commands below.
How Do You Use an HTTP Proxy With cURL?
HTTP proxy requests in cURL pass http://host:port to --proxy, followed by the destination URL and any required credentials.
For a plain HTTP destination, the proxy receives the HTTP request and returns the response. The proxy can read or change unencrypted traffic, so do not send private data to an HTTP destination.
The same HTTP proxy can carry an HTTPS destination:
cURL sends an HTTP CONNECT request to establish a tunnel. It then performs the destination TLS handshake inside that tunnel. The cURL HTTP proxy guide confirms that cURL uses this process automatically for HTTPS destinations.
Add credentials when the HTTP proxy requires them:
The HTTPS request then follows four stages:
- cURL connects to the HTTP proxy.
- cURL sends the configured proxy credentials when required.
- cURL asks the proxy to open a tunnel with CONNECT.
- cURL verifies the destination certificate and sends the encrypted request.
The proxy can see the requested destination host and connection metadata. Reading destination content would require TLS interception. That interception fails verification unless the client trusts the substitute certificate.
--proxytunnel is unnecessary for an ordinary HTTPS request. That option forces tunneling for protocols or situations where cURL would not select a tunnel automatically.
What Is the Difference Between an HTTP Proxy for HTTPS and an HTTPS Proxy?
HTTP proxies tunnel protected HTTPS destination traffic, while HTTPS proxies also encrypt the entire client-to-proxy connection.
The similar names describe different parts of the route. The destination scheme describes the final server. The proxy scheme describes the first connection from cURL to the proxy.
Proxy certificate trust and destination certificate trust are also independent. A successful first TLS handshake does not verify the second connection.
| Setup | Client-to-proxy connection | Proxy-to-destination handling | What remains exposed locally |
|---|---|---|---|
| HTTP proxy + HTTP destination | Plain HTTP | Proxy forwards plain HTTP | Request and response content |
| HTTP proxy + HTTPS destination | Plain HTTP control connection, then tunnel | Destination TLS passes through the tunnel | Proxy host, destination host, timing, and volume |
| HTTPS proxy + HTTP destination | TLS to the proxy | Proxy forwards plain HTTP onward | Destination-side HTTP content remains unencrypted |
| HTTPS proxy + HTTPS destination | TLS to the proxy, plus destination TLS in the tunnel | End-to-end destination TLS | Connection metadata at each relevant endpoint |
An HTTPS proxy does not convert an HTTP website into an HTTPS website. It only secures cURL's connection to the proxy. Use an HTTPS destination whenever the target supports it.
Best for: An HTTP proxy fits trusted networks and standard HTTPS tunneling. An HTTPS proxy fits cases where the client-to-proxy path also requires encryption.
How Do You Use an HTTPS Proxy With cURL?
HTTPS proxy requests pass an https:// URL to --proxy, plus credentials and a trusted proxy CA when either is required.
cURL opens a TLS connection to the proxy and verifies its certificate. For an HTTPS destination, cURL then creates a tunnel and verifies the destination certificate separately.
Private proxy infrastructure may use a certificate signed by an internal certificate authority (CA). Trust that CA for the proxy connection with --proxy-cacert:
The cURL certificate documentation separates proxy verification from destination verification. --proxy-cacert trusts a CA for the HTTPS proxy. --cacert performs the equivalent role for the destination.
--proxy-insecure skips proxy certificate verification. --insecure skips destination certificate verification. Both options remove an important identity check and should not appear in production scripts.
| Verification need | Correct option | Connection affected |
|---|---|---|
| Trust a private proxy CA | --proxy-cacert proxy-ca.pem | cURL to HTTPS proxy |
| Trust a private destination CA | --cacert destination-ca.pem | cURL to destination |
| Skip proxy verification temporarily | --proxy-insecure | cURL to HTTPS proxy |
| Skip destination verification temporarily | --insecure | cURL to destination |
A certificate error can belong to either TLS connection. Read the hostname in the error before changing a CA setting. Supplying a destination CA cannot repair an untrusted HTTPS proxy certificate.
How Do You Use a SOCKS5 Proxy With cURL?
SOCKS5 proxy requests use socks5h://host:port for proxy-side DNS, or socks5://host:port for local DNS resolution instead.
The h in socks5h:// means hostname resolution happens through the proxy. This behavior matters when local Domain Name System (DNS) results differ from the proxy region's results.
Use socks5:// for local name resolution:
cURL also provides dedicated SOCKS5 options. These two commands match the URL forms:
| cURL setting | Who resolves the destination name? | Main effect |
|---|---|---|
| socks5:// | Local cURL machine | Local resolver sees the lookup |
| --socks5 | Local cURL machine | Same behavior without a proxy URL scheme |
| socks5h:// | SOCKS5 proxy | Name resolution follows the proxy route |
| --socks5-hostname | SOCKS5 proxy | Same remote-resolution behavior |
The official SOCKS proxy guide documents this local-versus-proxy distinction. Remote resolution changes where the lookup occurs; it does not make DNS encrypted by itself.
cURL uses the SOCKS5 CONNECT command for these Transmission Control Protocol (TCP) transfers. Do not assume that cURL's SOCKS5 proxy mode supports arbitrary User Datagram Protocol traffic.
SOCKS5 is a relay protocol rather than an HTTP-aware proxy. It can carry an HTTPS connection, but the SOCKS5 connection itself is not encrypted. Destination TLS still protects the request and response after the tunnel is established.
Username-and-password SOCKS5 authentication still uses --proxy-user. If a build offers several SOCKS5 authentication methods, --socks5-basic explicitly selects username-and-password authentication.
How Do You Authenticate a Proxy in cURL?
Proxy authentication in cURL uses --proxy-user "username:password"; --user sends credentials to the destination instead.
Proxy authentication and destination authentication are separate. --proxy-user sends credentials to the proxy. --user sends credentials to the destination server.
| Requirement | cURL option | Recipient |
|---|---|---|
| Proxy username and password | --proxy-user or -U | Proxy server |
| Destination username and password | --user or -u | Destination server |
| Proxy chooses supported HTTP method | --proxy-anyauth | Proxy server |
| Specific HTTP proxy method | --proxy-basic, --proxy-digest, --proxy-negotiate, or --proxy-ntlm | Proxy server |
Basic is cURL's default method for HTTP proxy authentication. --proxy-anyauth asks the proxy which supported method to use, but that negotiation can add a round trip. The cURL proxy authentication guide explains the available methods.
Negotiate and NTLM availability depends on how cURL was built. Check curl --version before relying on either method in a deployment.
An HTTP proxy usually returns status 407 Proxy Authentication Required when credentials are missing or rejected. A failed HTTPS tunnel can report that status inside the CONNECT failure. SOCKS5 failures use the SOCKS handshake instead of an HTTP 407 response.
Credentials can also appear inside the proxy URL:
That format becomes hard to read when usernames or passwords contain reserved URL characters. Values inside a URL must be percent-encoded, such as %40 for @ and %3A for :. --proxy-user avoids that URL parsing problem.
Neither form is a secret store. Command arguments may enter shell history or appear briefly in process listings. Use a protected cURL configuration file, environment injection, or a secrets manager for unattended jobs.
How Do You Use Proxidize Proxies With cURL?
Proxidize proxy use with cURL starts with the generated scheme, hostname, port, credentials, and session settings from the dashboard.
Proxidize access points can use HTTP or SOCKS5, depending on the selected dashboard setting. Keep the generated scheme, host, port, and authentication format unchanged. The Proxidize residential proxy page shows its cURL connection format.
A basic setup follows five steps:
- Create or select the required access point.
- Choose HTTP or SOCKS5 for the client connection.
- Set the location, rotation, or sticky-session behavior required by the workload.
- Select username-and-password or IP-allowlist authentication.
- Copy the generated cURL details and test the intended destination.
A username-and-password command follows this pattern:
An IP-allowlisted access point does not need --proxy-user from an approved source address:
Do not replace the generated proxy scheme based on the destination URL. An HTTPS destination can work through the HTTP or SOCKS5 value supplied by the dashboard.
Use Proxidize Residential Proxies when you need location-targeted residential IPs for scraping, price monitoring, SEO monitoring, or other web-data workloads. Use Proxidize Mobile Proxies when the target or workflow specifically benefits from IPs associated with mobile networks.
The generated access-point settings control the route. cURL only supplies those settings to the proxy. If a requested city or session does not appear, inspect the dashboard configuration and generated credentials before changing cURL flags.
How Do You Set Proxy Environment Variables for cURL?
cURL reads proxy environment variables before a transfer, which removes repeated --proxy options from individual commands.
For Bash or zsh, set HTTPS_PROXY for HTTPS destination URLs:
The variable name refers to the destination scheme. The value determines the proxy protocol. Therefore, HTTPS_PROXY can correctly contain an http:// proxy URL.
Use lowercase http_proxy for HTTP destinations:
cURL accepts uppercase forms for most proxy variables, but http_proxy is deliberately lowercase-only. The official environment-variable guide explains that this exception prevents CGI header conflicts.
ALL_PROXY supplies a fallback for destination schemes without a more specific variable:
Windows PowerShell 5.1 aliases curl to Invoke-WebRequest; PowerShell 7 does not define that alias by default. Use curl.exe when you need the cURL executable:
An explicit --proxy normally overrides the matching proxy environment variable. Use an empty proxy value to disable environment proxies for one request:
| Variable | Applies to | Precedence note |
|---|---|---|
| http_proxy | HTTP destination URLs | Lowercase form only |
| HTTPS_PROXY or https_proxy | HTTPS destination URLs | Overrides ALL_PROXY for HTTPS |
| ALL_PROXY | Destination schemes without a specific variable | Fallback setting |
| NO_PROXY | Matching hosts or networks | Bypasses configured proxies |
Child processes inherit environment variables unless the shell clears them. Do not place long-lived proxy passwords in shared shell profiles. Inject secrets only into the process that needs them.
How Do You Bypass a Proxy for Selected Hosts?
Proxy bypass rules use NO_PROXY or --noproxy when localhost, internal networks, or selected destinations require direct connections.
A leading dot matches the named domain and its subdomains. The cURL bypass documentation says version 7.86.0 added Classless Inter-Domain Routing (CIDR) ranges, such as 192.168.0.0/16.
| Bypass value | Matches |
|---|---|
| localhost | That hostname and its subdomains |
| .example.com | The domain and its subdomains |
| 192.168.0.0/16 | Addresses in that CIDR range |
| * | Every destination |
The command-line equivalent is:
NO_PROXY can bypass a proxy even when the command includes --proxy. Use an empty --noproxy value when a script must ignore NO_PROXY and force the configured proxy:
Inspect inherited environment variables when a command unexpectedly connects directly. This problem appears often in containers, continuous integration workers, and corporate shells.
Test bypass rules with a harmless destination before deployment. A pattern that is too broad can send intended proxy traffic directly. A pattern that is too narrow can route internal hosts through an external proxy.
Bypass rules match the destination host or address, not the proxy host. They do not change the proxy scheme selected for other requests.
Document each bypass entry so future operators know why that destination needs a direct route.
How Do You Store Reusable cURL Proxy Settings?
cURL proxy settings belong in a protected configuration file when a script must reuse the same options with controlled access.
Create proxy.conf with one option per line:
On Linux or macOS, restrict the file before loading it explicitly:
-q must appear first. It prevents cURL from loading its normal default configuration file before the named file. This makes automated behavior easier to reproduce.
The cURL command-line manual permits long option names without leading dashes inside configuration files. Keep one option per physical line. Pass the destination on the command line when the same proxy settings serve several approved targets.
Do not place the word curl inside proxy.conf. The file contains options for cURL to load, not a shell command. Load it with curl -q --config proxy.conf "DESTINATION_URL".
File permissions reduce accidental access, but the password remains clear text. Do not commit the file to source control. A deployment secret manager is safer for shared infrastructure.
On Windows, protect the file with an appropriate access control list instead of chmod. Give access only to the account that runs the job.
Review the file whenever credentials, endpoints, timeouts, or authentication requirements change.
How Do You Send Headers Only to the Proxy?
Proxy-specific HTTP headers use --proxy-header; destination request headers remain under the ordinary --header option.
--proxy-header applies the first custom header to the HTTP proxy request. --header, or -H, applies the second header to the destination request.
| Header purpose | cURL option | Intended recipient |
|---|---|---|
| Provider-specific proxy header | --proxy-header | HTTP or HTTPS proxy |
| API content or request header | --header or -H | Destination server |
| Proxy username and password | --proxy-user | Proxy authentication layer |
This separation matters with HTTPS destinations. The proxy sees the initial CONNECT request, while the destination receives the HTTP request inside the encrypted tunnel. The cURL proxy-header guide documents the distinction.
Do not send an origin authorization token through --proxy-header. Likewise, do not send proxy credentials as an ordinary destination header.
cURL creates Proxy-Authorization from the selected authentication settings. Supplying that header manually can choose the wrong method or expose a reusable value in scripts. Let --proxy-user and the relevant authentication option build it.
--proxy-header @proxy-headers.txt can load several proxy headers from a file. Put one header on each line, restrict access to that file, and keep destination secrets in a separate header source.
Audit both header sets before enabling redirects or sending diagnostic logs outside the operating team.
How Do Proxy Sessions Affect cURL Requests?
Proxy sessions determine whether repeated cURL requests rotate exit addresses, keep one temporarily, or use a static exit.
cURL sends the proxy credentials and endpoint you provide. The proxy service decides whether those details map to a rotating, sticky, or static exit. Session parameters may appear in the username, hostname, or access-point configuration.
One cURL command can reuse connections during that process. Separate cURL executions do not create provider-side stickiness by themselves. Copy the provider's documented session format instead of inventing a parameter.
| Session behavior | Exit behavior | Suitable request pattern |
|---|---|---|
| Rotating | Provider may select another exit at its rotation boundary | Independent requests |
| Sticky | Provider tries to retain one exit for a defined session | Linked requests and workflows |
| Static | Same assigned exit remains available | Allowlisted or long-lived identities |
Cookies and proxy sessions solve different problems. A cookie file can preserve application state, while a sticky proxy session preserves route identity:
Protect cookie files because they may contain active session credentials. The guide to proxy sessions for AI agents explains when rotation, stickiness, and state need to move together.
A sticky label is not a lifetime guarantee. An exit can disappear because its upstream connection changes. Decide whether the application should restart a linked workflow or fail cleanly after that event.
How Do You Verify That cURL Is Using the Proxy?
cURL proxy verification checks the connected proxy, public exit address, real target response, and repeated-request behavior separately.
The Five-Check cURL Proxy Test is an original validation method for this guide. It prevents one changed IP address from being mistaken for complete success.
- Record the direct address. Call an IP service without the proxy.
- Record the proxied address. Repeat the request with the intended proxy settings.
- Inspect the connection. Confirm that cURL connects to the expected proxy host and port.
- Test the real destination. Validate its status, content, location, and required session behavior.
- Repeat under expected load. Measure failures and slower requests, not one successful attempt.
Start with a direct result:
Then compare the proxied result:
ipify returns the public address it sees. A changed, expected address supports the conclusion that the request used another route. It does not prove that the proxy works on every target.
Record connection and total time without printing the response body:
For proxied transfers, remote_ip normally identifies the connected proxy endpoint. A production check should also validate expected content because status 200 can still accompany the wrong page.
Target requirements change the correct proxy choice. The Amazon scraping proxy guide shows why network type, location, rotation, and response validation must match one authorized workload.
Which cURL Options Make Proxy Requests Safer in Scripts?
cURL script options should provide bounded timeouts, visible errors, HTTP failure handling, and preserved exit codes for the calling process.
| Option | What it does | Why it helps scripts |
|---|---|---|
| --silent | Hides progress output | Keeps logs readable |
| --show-error | Prints errors when silent mode is active | Preserves failure details |
| --fail-with-body | Fails on HTTP status 400 or higher and retains the body | Exposes API error details |
| --connect-timeout 10 | Limits the connection phase | Stops DNS, proxy, and TLS setup from hanging |
| --max-time 30 | Limits the full transfer | Gives the job a fixed upper bound |
--connect-timeout covers the connection phase, including required DNS, TCP, and TLS setup. --max-time covers the whole operation.
The cURL manual says --fail-with-body requires version 7.76.0 or newer. Older builds can use --fail, which discards the error response body.
Capture and preserve cURL's exit status when a shell script needs to stop:
Add retries only for classified transient failures. Repeating a rejected password, invalid certificate, or malformed request does not repair it. When retries are appropriate, cap them and record every attempt.
What Are the Most Common cURL Proxy Errors?
cURL proxy errors usually point to name resolution, connection, authentication, certificate, timeout, or handshake failures.
| Symptom | Likely cause | First check |
|---|---|---|
| Could not resolve proxy | Wrong proxy hostname or unavailable DNS | Verify the hostname and resolver |
| Failed to connect | Wrong port, firewall rule, or offline proxy | Test reachability to the proxy port |
| HTTP 407 | Missing or rejected proxy credentials | Confirm --proxy-user and the auth method |
| Failed CONNECT | Proxy policy, rejected destination port, authentication, or upstream failure | Read the returned status and proxy error message |
| Certificate verification error | Untrusted proxy CA or destination CA | Identify which TLS connection failed |
| Operation timed out | Slow proxy, blocked route, or short timeout | Separate connect time from total time |
| SOCKS handshake error | Wrong SOCKS mode, authentication, or server support | Confirm the scheme and proxy capabilities |
The cURL exit-code reference lists 5 for unresolved proxy names, 7 for connection failures, and 28 for timeouts. Code 35 indicates a TLS connection problem, and code 60 marks certificate verification failure.
Code 97 indicates a proxy handshake problem. The exact message still matters because one exit code can cover several causes.
Run curl --verbose for controlled debugging:
Verbose output can expose hostnames, headers, cookies, and authentication details. Redact logs before sharing them. Do not leave verbose mode enabled in ordinary production logging.
Which Proxy Type Should You Use With cURL?
Proxy type selection in cURL depends on network trust, destination DNS, location, session needs, and target behavior requirements.
Proxy protocol and proxy network type answer different questions. HTTP, HTTPS, and SOCKS5 describe how cURL reaches a proxy. Datacenter, residential, mobile, and internet service provider (ISP) describe where an exit address comes from.
A residential or mobile service can expose an HTTP or SOCKS5 endpoint. Choosing SOCKS5 does not turn a datacenter exit into a residential exit. Confirm both the connection protocol and the network source.
| Requirement | Practical starting point | Reason |
|---|---|---|
| Standard HTTPS website through a trusted network | HTTP proxy | cURL tunnels destination TLS automatically |
| Encrypted client-to-proxy connection | HTTPS proxy | Protects the first network leg with TLS |
| Proxy-side destination lookup | socks5h:// | Moves name resolution to the proxy |
| Local destination lookup | socks5:// | Keeps DNS behavior on the cURL machine |
| Global, location-sensitive web data | Managed residential proxy | Provides broader regional exit choices |
Protocol compatibility is only the first filter. A proxy can accept the cURL request and still return the wrong location, blocked page, or incomplete content.
Test the least complex option that meets the workload. Use controlled request rates, follow applicable laws and site terms, and stop when access is not authorized.
The detailed HTTP and SOCKS5 proxy comparison covers protocol selection beyond cURL syntax. Provider support still determines which modes are available on a specific endpoint.
Best for: HTTP proxies cover many web requests. HTTPS proxies protect an untrusted first hop. SOCKS5 fits workflows that need its routing or name-resolution behavior.
What Should You Remember About Using cURL With a Proxy?
cURL proxy commands work best when the proxy protocol, destination protocol, authentication, and validation method are treated separately.
- --proxy and -x select the proxy endpoint for a cURL transfer.
- An HTTP proxy carries an HTTPS destination through CONNECT without requiring --proxytunnel.
- An HTTPS proxy adds a separate TLS connection between cURL and the proxy.
- socks5h:// resolves destination names through the proxy, while socks5:// resolves them locally.
- --proxy-user authenticates to the proxy, while --user authenticates to the destination.
- NO_PROXY can bypass an explicit proxy, and --noproxy "" can force that proxy again.
- A route check should be followed by target-content, location, session, latency, and failure-rate checks.
Frequently asked questions
Pass the proxy URL to --proxy, or -x, and put the destination URL last. Add --proxy-user "username:password" when authentication is required. Include the proxy scheme and port explicitly so cURL uses the intended HTTP, HTTPS, or SOCKS5 behavior. Quote values containing shell-sensitive characters.
Yes. cURL sends CONNECT to the HTTP proxy and establishes a tunnel to the HTTPS destination. The destination TLS session runs through that tunnel. The proxy sees connection metadata and the requested host. Valid end-to-end TLS protects destination content from ordinary proxy inspection.
socks5:// makes cURL resolve the destination hostname on the local machine before contacting the proxy. socks5h:// sends the hostname to the SOCKS5 proxy for resolution. Use socks5h:// when remote DNS behavior or proxy-region resolution matters. This avoids relying on the local resolver.
Use --proxy-user "username:password", or -U, with the proxy command. This option authenticates to the proxy rather than the destination. Avoid exposing long-lived secrets in shell history. Protected configuration files, injected environment values, or a secrets manager are safer for unattended jobs. Rotate credentials after suspected exposure.
Check NO_PROXY, --noproxy, and inherited shell variables first. A matching NO_PROXY entry can bypass even an explicit --proxy setting. Also confirm that the environment variable matches the destination scheme. Use curl --verbose in a controlled test to inspect the actual connection. An empty --proxy disables environment proxy use.
Compare a direct public address with a proxied result, then test the real destination. Verify its status, expected content, location, session behavior, and response times. A changed address confirms only that one request followed another route; it does not prove reliable target access.
No, not in production. For an HTTPS proxy signed by a private CA, use --proxy-cacert with the correct CA certificate. Use --cacert for a private destination CA. --proxy-insecure and --insecure disable identity verification and can hide interception or configuration mistakes. Correct the trust chain instead.