Troubleshooting proxy requests

Start with the smallest reproducible request from the same machine or container as the failing application. Separate proxy connectivity from destination behavior before changing retry logic.

Run a controlled preflight

curl --verbose --show-error --fail-with-body \
  --connect-timeout 15 \
  --max-time 45 \
  --proxy 'https://proxy.packetstream.io:31111' \
  --proxy-user "${PACKETSTREAM_USER}:${PACKETSTREAM_AUTH_KEY}" \
  'https://ipinfo.io' \
  --output /tmp/packetstream-ipinfo.json

Verbose output can contain operational details. Review and sanitize it before sharing. Never paste credentials or a complete authenticated proxy URL into a ticket.

Measure success rate and latency

To test more than one request, use ProxySampler, an open-source command-line tool. It reads PACKETSTREAM_USER and PACKETSTREAM_AUTH_KEY from the environment, opens a new connection for each request, and reports the success rate, latency percentiles, and errors without printing the auth key:

go install github.com/packetstream/proxysampler@latest
proxysampler --country US --count 20 --check-exit

--check-exit looks up each exit IP with ipinfo.io and fails requests that exit outside the requested country. IP databases can misplace an address, so confirm a mismatch with a second source before reporting it. Add --session LABEL to check that a sticky session keeps one exit IP, and --protocol http or --protocol socks5 to test the other endpoints. The exit status is non-zero when a request fails, so the command also suits scheduled checks.

Authentication fails

Check that:

• the username is the PacketStream proxy username;
• the password is the dashboard auth key, including any intended modifiers;
• the credentials do not contain accidental whitespace or line breaks;
• the proxy scheme and port are paired correctly;
• the application is sending proxy authentication rather than destination authentication;
• your balance is not empty. With SOCKS5, an empty balance fails like a wrong password. HTTP and HTTPS return 502 Proxy Error (no funds available) instead. Check your balance.

Do not retry an authentication failure. Stop the job and correct the configuration.

The connection fails before authentication

Verify the endpoint:

HTTPS  https://proxy.packetstream.io:31111
SOCKS5 socks5h://proxy.packetstream.io:31113
HTTP   http://proxy.packetstream.io:31112

Then check outbound firewall rules, VPN or corporate-proxy interference, and whether the client supports the selected proxy protocol.

An HTTPS destination does not prove that a library supports an HTTPS proxy. Some clients support only a plain HTTP proxy with a tunnel to an HTTPS destination. Use SOCKS5 when it is the best supported secure option for that client, or choose a client with HTTPS proxy support.

TLS or certificate errors

Do not disable certificate verification in production. Confirm:

• the client is using the correct scheme and port;
• the runtime trust store is current;
• a corporate inspection proxy is not replacing certificates;
• the library actually supports TLS to an HTTPS proxy;
• the error occurs when contacting the proxy rather than the destination.

Test the same endpoint with a current cURL build to separate system trust problems from application-library behavior.

Rotation appears to return the same exit

Automatic rotation selects an exit for each new proxy connection. Many clients reuse connections. Inspect the client’s connection-pool behavior before assuming rotation failed.

For a simple comparison, run several separate cURL processes, or proxysampler --count 10 --check-exit to count unique exit IPs. Do not treat uniqueness in a small sample as a contract.

A sticky session fails

A sticky session fails when the Packeter providing its IP disconnects. PacketStream does not move the label to another IP. HTTP and HTTPS requests return 502 Proxy Error (sticky session IP is offline); SOCKS5 requests get the general failure reply (0x01).

New connections on the label keep failing until the same IP comes back online or 60 minutes pass without a successful connection. After that, the label expires and the next connection gets a new IP.

• If the workflow can wait for the same IP, retry with backoff and a limit.
• If it cannot wait, choose a new session label and restart from a safe checkpoint.

Do not retry a failed label in a tight loop.

A sticky label keeps its IP while it opens a successful new connection at least every 60 minutes. It is not a permanent static IP, because the Packeter can go offline.

A country-targeted request fails

Confirm the password suffix uses an ISO two-letter code, such as:

AUTH_KEY_country-US

When no exit is available in the requested country, the request fails instead of using another country. Keep that condition separate from authentication and destination failures, and use bounded backoff if retrying availability.

If the request succeeds but an IP database reports a surprising city or region, remember that sub-country IP geography is approximate. Country is the supported targeting boundary.

Requests time out

Use separate limits for:

• connecting to the proxy;
• waiting for the destination;
• completing the whole request or browser workflow;
• all retries combined.

Retry only failures that are plausibly transient. Use exponential backoff with jitter, cap attempts, and keep writes idempotent. Authentication errors, deterministic parser failures, and unsupported configurations should fail immediately.

What to send support

Include:

• timestamp and timezone;
• proxy protocol and port;
• client, library, and version;
• runtime operating system or container image;
• requested country, if any;
• whether the request used automatic rotation or a sticky session;
• destination hostname when you are permitted to share it;
• a sanitized error and minimal reproduction.

Do not include the auth key, full authenticated proxy URL, destination account credentials, cookies, or unrelated collected data. Contact PacketStream support when the controlled preflight still fails.