DEV Community

98IP Proxy
98IP Proxy

Posted on

Debugging curl Proxy Authentication Without Leaking Credentials

#devops

A 407 Proxy Authentication Required response is a useful routing checkpoint. It normally means the client reached a proxy, but the proxy did not accept a usable authentication result. Treat it separately from destination responses such as 401, 403, or 429.

Start with one controlled request

Remove rotation, concurrency, retries, and application wrappers. Supply credentials through protected variables rather than a credential-bearing URL.

curl --verbose \  --proxy "$PROXY_ENDPOINT" \  --proxy-user "$PROXY_USERNAME:$PROXY_PASSWORD" \  https://en.98ip.com/
Enter fullscreen mode Exit fullscreen mode

Before sharing any output, redact Proxy-Authorization, cookies, tokens, session identifiers, and URLs containing credentials.

Diagnose the correct layer

Work through the request in this order:

  1. Endpoint — confirm proxy hostname, port, and product endpoint.
  2. Protocol — verify that the proxy scheme matches the service.
  3. Credential scope — check account, zone, region, and session syntax.
  4. Authentication method — confirm what the client offered and the proxy accepts.
  5. Tunnel — determine whether HTTPS CONNECT completed.
  6. Destination — diagnose the target only after a tunnel exists.

A proxy-generated 407 belongs to the authentication layer. A destination-generated 403 or 429 after a successful tunnel belongs to the target layer. Rotating proxy credentials will not fix a destination policy.

Check effective configuration

Conflicting environment variables are a common source of surprises:

env | grep -iE '^(http|https|all|no)_proxy=' | sed -E 's#(//)[^@]+@#\1***:***@#'
Enter fullscreen mode Exit fullscreen mode

Even sanitized output should be handled carefully. Prefer reporting whether variables are present and which setting won rather than printing their raw values.

When a request works locally but fails in CI, check:

  • protected secrets unavailable to forked jobs;
  • trailing spaces or newlines in injected variables;
  • a different runner egress IP;
  • an IP allowlist that covers local traffic but not CI;
  • uppercase and lowercase proxy variables with different values;
  • a shell or workflow step that expands the secret incorrectly.

Read a verbose trace safely

A useful trace can show the proxy connection, authentication challenge, CONNECT tunnel, TLS negotiation, and final destination response. The useful incident record includes curl version, operating system, runner region, non-secret endpoint label, status code, and timing phase.

Never attach a raw verbose log to a public issue. Redact authorization headers, cookies, tokens, full session strings, internal hostnames, and sensitive response bodies.

Avoid retry amplification

Authentication failures are usually deterministic. Retrying the same rejected credential adds noise and may trigger account protection. Disable broad retries while diagnosing 407.

After the root cause is fixed, restore bounded retries only for transient network failures. Use exponential backoff, jitter, a maximum attempt count, and a total timeout budget.

Decision checklist

  • Cannot connect: inspect DNS, firewall, endpoint, protocol, and port.
  • 407 from proxy: inspect credential format, secret status, product scope, allowlist, and authentication method.
  • Tunnel succeeds, TLS fails: inspect certificate trust, hostname handling, interception policy, and clock.
  • Destination returns 403/429: inspect request behavior, authorization, rate, and destination terms.

Compliance and disclosure

Use proxy-assisted automation only for systems and data you are authorized to access. Respect destination terms, rate limits, privacy requirements, and data-retention rules.

I work with 98IP. English service information: https://en.98ip.com/?k=dev

Top comments (0)