> ## Documentation Index
> Fetch the complete documentation index at: https://help.miyaip.com/llms.txt
> Use this file to discover all available pages before exploring further.

# HTTP vs SOCKS5 proxies: protocols, DNS, and setup

> Compare HTTP and SOCKS5 proxy behavior, authentication, DNS resolution, and HTTPS tunneling, then verify the connection with curl.

Choose an HTTP proxy when the workload is web-only and the client expects an HTTP or HTTPS proxy setting. Choose SOCKS5 when a compatible client must carry non-HTTP TCP traffic or send destination hostnames to the proxy for resolution. For ordinary HTTPS traffic, either option can carry end-to-end TLS to the destination; test the real route before deciding on performance.

<Note>
  **Fast choice**: HTTP is usually the simpler fit for browsers, APIs, and web-only tools. SOCKS5 supports SOCKS-aware applications and mixed TCP protocols. Security and performance depend on end-to-end encryption, authentication, DNS mode, route quality, and operator policy. Neither protocol alone provides encryption, anonymity, or a universal speed advantage.
</Note>

## What each proxy does

For plain HTTP, an HTTP forward proxy can receive and forward HTTP messages. For HTTPS, a conventional proxy accepts CONNECT and creates a TCP tunnel; the client then establishes TLS with the destination through that tunnel.

SOCKS5 begins with method negotiation, then the client requests CONNECT, BIND, or UDP ASSOCIATE for an IPv4 address, IPv6 address, or domain name. It can relay HTTP, TLS, SSH, or another protocol when the application supports SOCKS.

## Data flow

```text theme={null}
Plain HTTP
Client -- HTTP request --> HTTP proxy -- HTTP request --> Origin

HTTPS through an HTTP proxy
Client -- CONNECT host:443 --> HTTP proxy --> Origin
Client ============== TLS through the tunnel ============= Origin

SOCKS5
Client -- method negotiation + target request --> SOCKS5 proxy
Client <============ TCP or supported UDP relay ==========> Target
```

## HTTP proxy, HTTPS destination, and TLS to the proxy are different

The words HTTP and HTTPS can describe different hops. An HTTP proxy can still tunnel an HTTPS destination with CONNECT. An HTTPS proxy endpoint adds TLS between the client and proxy, but the destination also needs HTTPS when the application payload must remain encrypted end to end.

| Path or term | Client to proxy | Proxy to destination | What is protected |
| - | - | - | - |
| HTTP proxy to an HTTP destination | Plain HTTP proxy protocol | Plain HTTP | No encryption is inherent |
| HTTP proxy to an HTTPS destination | HTTP CONNECT control, then a tunnel | TLS terminates at the destination | HTTPS payload is protected between client and destination |
| HTTPS proxy endpoint (TLS to proxy) | TLS protects the client-to-proxy hop | HTTP forwarding or CONNECT tunnel | Proxy credentials and control traffic are protected on the first hop; destination HTTPS is still required for end-to-end payload protection |
| SOCKS5 proxy to an HTTPS destination | SOCKS5 negotiation and relay | TLS terminates at the destination | HTTPS payload is protected end to end; SOCKS5 negotiation is not encrypted by the protocol itself |

## Side-by-side comparison

| Dimension | HTTP proxy | SOCKS5 proxy |
| - | - | - |
| Primary layer | HTTP-aware interface | General relay between application and transport |
| Typical traffic | HTTP and HTTPS via CONNECT | Multiple TCP protocols; optional UDP relay |
| DNS behavior | Depends on client and proxy mode | Client may send an IP or hostname |
| Authentication | HTTP proxy authentication, commonly 407 challenge | Method negotiation; username/password is optional |
| Application awareness | Can process plain HTTP messages | Does not define application-message parsing |
| Best fit | Web clients and HTTP-aware policy | Mixed protocols and explicit SOCKS-capable clients |
| Encryption | Not inherent; use HTTPS/TLS | Not inherent; use end-to-end secure protocols |

## Choose an HTTP proxy when

* The workload is primarily HTTP or HTTPS.
* The client exposes only HTTP/HTTPS proxy settings.
* You need HTTP-aware authentication, logging, filtering, caching, or request policy.
* A conventional CONNECT tunnel is sufficient for HTTPS traffic.

## Choose SOCKS5 when

* One proxy interface must relay several TCP application protocols.
* A compatible application requires SOCKS5 UDP ASSOCIATE.
* The client must send destination hostnames to the proxy for resolution.
* The application explicitly supports SOCKS5 or a compatible wrapper is available.

## DNS behavior matters

SOCKS5 does not automatically guarantee remote DNS. The client can resolve locally and send an IP, or send a hostname for proxy-side resolution. In curl, socks5:// resolves locally while socks5h:// sends the hostname through the proxy.

```bash theme={null}
# HTTP proxy; curl uses CONNECT for this HTTPS URL
curl --proxy http://proxy.example:8080 https://example.com/

# SOCKS5 with local destination DNS
curl --proxy socks5://proxy.example:1080 https://example.com/

# SOCKS5 with hostname sent to the proxy
curl --proxy socks5h://proxy.example:1080 https://example.com/
```

## Verify protocol, DNS, and exit IP

Confirm the protocol and port assigned to your endpoint. HTTP and SOCKS5 ports on the same host may differ. These commands contain placeholders; load your own credentials from a secret manager or your current terminal.

<Steps>
  <Step title="Prepare connection variables">
    Check `curl --version`. On Windows, call `curl.exe` to avoid another command with the same name. Replace the placeholders with dashboard fields. Set both ports only if your endpoint supports both protocols.

    <CodeGroup>
      ```bash Bash theme={null}
      export PROXY_HOST="YOUR_PROXY_HOST"
      export HTTP_PROXY_PORT="YOUR_HTTP_PROXY_PORT"
      export SOCKS5_PROXY_PORT="YOUR_SOCKS5_PROXY_PORT"
      export PROXY_USER="YOUR_PROXY_USER"
      export PROXY_PASSWORD="YOUR_PROXY_PASSWORD"
      ```

      ```powershell PowerShell theme={null}
      $env:PROXY_HOST = "YOUR_PROXY_HOST"
      $env:HTTP_PROXY_PORT = "YOUR_HTTP_PROXY_PORT"
      $env:SOCKS5_PROXY_PORT = "YOUR_SOCKS5_PROXY_PORT"
      $env:PROXY_USER = "YOUR_PROXY_USER"
      $env:PROXY_PASSWORD = "YOUR_PROXY_PASSWORD"
      ```
    </CodeGroup>

    The credentials above are placeholders. Load real values from a secret manager or enter them interactively in the current terminal. Keep them out of shared scripts, repositories, and logs.
  </Step>

  <Step title="Record a direct baseline">
    Query the exit without an explicit proxy. `--noproxy "*"` disables curl's proxy path. It does not bypass a system VPN or transparent forwarding, so check other network tools first.

    ```bash theme={null}
    curl --fail --show-error --silent --noproxy "*" \
      --connect-timeout 10 --max-time 30 https://api.ipify.org
    ```
  </Step>

  <Step title="Test supported protocols">
    These commands use Bash. In PowerShell, use `curl.exe`, `$env:VARIABLE_NAME`, and put each command on one line. `--noproxy ""` prevents `NO_PROXY` from excluding the target; PowerShell 7.3 or newer preserves this empty argument.

    ```bash theme={null}
    # HTTP proxy to an HTTPS destination through CONNECT
    curl --fail --show-error --silent --noproxy "" \
      --connect-timeout 10 --max-time 30 \
      --proxy "http://${PROXY_HOST}:${HTTP_PROXY_PORT}" \
      --proxy-user "${PROXY_USER}:${PROXY_PASSWORD}" \
      --output /dev/null --write-out "status=%{http_code} total=%{time_total}s\n" \
      https://example.com/

    # SOCKS5: resolve destination DNS on the client
    curl --fail --show-error --silent --noproxy "" \
      --connect-timeout 10 --max-time 30 \
      --proxy "socks5://${PROXY_HOST}:${SOCKS5_PROXY_PORT}" \
      --proxy-user "${PROXY_USER}:${PROXY_PASSWORD}" \
      --output /dev/null --write-out "status=%{http_code} total=%{time_total}s\n" \
      https://example.com/

    # SOCKS5H: resolve destination DNS on the proxy
    curl --fail --show-error --silent --noproxy "" \
      --connect-timeout 10 --max-time 30 \
      --proxy "socks5h://${PROXY_HOST}:${SOCKS5_PROXY_PORT}" \
      --proxy-user "${PROXY_USER}:${PROXY_PASSWORD}" \
      --output /dev/null --write-out "status=%{http_code} total=%{time_total}s\n" \
      https://example.com/
    ```

    On Windows, replace `/dev/null` with `NUL`. A successful request should return the destination's normal HTTP status. `total` measures this request only; one observation cannot rank protocol speed. If a command fails, check its exit code and the troubleshooting table below.
  </Step>

  <Step title="Check DNS mode and the actual exit">
    Add `--verbose` to the SOCKS5 and SOCKS5H commands to observe local resolution versus passing a hostname to the proxy. Log wording varies by curl version. A single log line does not prove that all DNS traffic uses the proxy. Remove credentials and complete authentication strings before sharing logs.

    Change the successful proxy command's destination to `https://api.ipify.org`, remove `--output` and `--write-out`, and read the exit IP. Compare it with the direct baseline and the dashboard's **Exit IP**, keeping the connection host separate from the final exit. For continuity checks, use the [static proxy Python verification guide](/developers/static-proxy).
  </Step>

  <Step title="Repeat the same workload and record results">
    Keep the target, network, time window, concurrency, and DNS mode consistent when comparing protocols. Record sample size, successful requests, latency variation, and errors. Clear username and password variables from the current terminal when finished.
  </Step>
</Steps>

## Troubleshooting protocol, port, and authentication errors

| Symptom | Likely cause | Check and fix |
| - | - | - |
| HTTP 407 Proxy Authentication Required | Missing, rejected, or incorrectly encoded credentials | Confirm the assigned username and password; quote the proxy URL and percent-encode reserved characters instead of printing credentials in logs |
| Connection refused or timeout immediately | Wrong proxy port, wrong protocol scheme, firewall, or unreachable endpoint | Confirm the provider-assigned host, port, and protocol; test TCP reachability without repeatedly rotating endpoints |
| Unsupported proxy syntax or option | The client build lacks SOCKS support or uses different settings | Run curl --version and check the client documentation; upgrade or use a supported HTTP proxy mode |
| socks5h works but socks5 fails | The local resolver cannot resolve the destination or DNS is blocked | Check the local resolver; use proxy-side DNS deliberately when policy permits it |
| TLS certificate error | Destination certificate issue or unexpected TLS interception | Inspect the certificate chain and proxy policy; do not hide the problem with --insecure |

## Security considerations

* A proxy is not encryption. Use HTTPS, SSH, or another end-to-end secure protocol.
* RFC 1929 username/password authentication does not encrypt the password by itself.
* Local DNS can expose destination queries outside the proxy path; remote DNS transfers that visibility to the proxy operator.
* Restrict CONNECT targets, SOCKS relay destinations, credentials, and network access.
* Do not confuse a normal CONNECT tunnel with an explicitly governed TLS-interception proxy.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Is SOCKS5 safer or more anonymous than HTTP?">
    Not by protocol name alone. End-to-end encryption, DNS mode, authentication, logging, client behavior, and operator trust determine the security outcome.
  </Accordion>

  <Accordion title="Can an HTTP proxy handle HTTPS?">
    Yes. A conventional HTTP proxy uses CONNECT to create a TCP tunnel, then TLS runs between the client and destination through it.
  </Accordion>

  <Accordion title="Can SOCKS5 carry HTTP and HTTPS?">
    Yes, when the client supports SOCKS5. The proxy relays the connection without needing to interpret HTTP.
  </Accordion>

  <Accordion title="Does SOCKS5 always prevent DNS leaks?">
    No. The client may resolve locally. Use an explicit proxy-side DNS mode such as socks5h in curl and verify deployed behavior.
  </Accordion>

  <Accordion title="Does an HTTP proxy support UDP?">
    Do not assume it. Classic CONNECT is TCP. CONNECT-UDP is a separate extension that requires compatible client and proxy support.
  </Accordion>

  <Accordion title="Which proxy is faster?">
    There is no universal winner. Benchmark the real route, concurrency, connection reuse, DNS mode, and protocol mix.
  </Accordion>
</AccordionGroup>

## Sources

* [RFC 1928 — SOCKS Protocol Version 5](https://www.rfc-editor.org/rfc/rfc1928.html)
* [RFC 1929 — Username/Password Authentication for SOCKS V5](https://www.rfc-editor.org/rfc/rfc1929.html)
* [RFC 9110 — HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110.html)
* [RFC 9298 — Proxying UDP in HTTP](https://www.rfc-editor.org/rfc/rfc9298.html)

[MiyaIP original guide: HTTP vs SOCKS5 proxies](https://miyaip.com/blog/http-proxy-vs-socks5-proxy).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.