TL；DR: Connecting Python to Gleam residential proxies does not require first retrieving and maintaining a list of IPs. A reliable sequence is to use Requests and an IP lookup endpoint to verify proxy authentication and the exit location, move credentials into environment variables, and then add sticky sessions, error classification, and limited retries.

Configuring residential proxies in Python is not complicated.

The issues that lead to repeated troubleshooting are usually not how to write requests.get(), but an incomplete proxy username, special characters in a password, or a session identifier accidentally changed during retries.

Some developers respond to their first failed request by changing SSL settings, switching request libraries, or adding threads, only to discover that the proxy port was simply incorrect.

A more reliable troubleshooting sequence is:

First prove that the proxy connection works, then add location settings, sessions, retries, and concurrency.

How Do You Run the First Proxy Test with Requests?

Install Requests first:

pip install requests

Then copy the complete proxy gateway, port, username, and password from the Gleam dashboard:

import requests

proxy_url = (
    "http://YOUR_USERNAME:YOUR_PASSWORD"
    "@tun-hk.ipgleam.net:10000"
)

proxies = {
    "http": proxy_url,
    "https": proxy_url,
}

response = requests.get(
    "https://api.ipify.org?format=json",
    proxies=proxies,
    timeout=(10, 30),
)

response.raise_for_status()
print(response.json())

If the connection succeeds, the returned address should be the proxy exit IP rather than the computer's or server's own public IP.

Avoid using the production target website for the very first test.

An IP lookup endpoint has a simple response structure and does not involve complex cookies, scripts, or multiple redirects. This makes it easier to distinguish proxy authentication and network connection problems from issues with the target website itself.

After the test passes, also verify that the returned IP's location matches the intended region. A working proxy connection with the wrong exit country is still not ready for production.

Why Can the Proxy URL Use http:// for an HTTPS Website?

This is a common question when configuring proxies for the first time.

An HTTPS target website does not necessarily require a proxy URL beginning with https://.

The client can establish a tunnel through an HTTP proxy and then access the HTTPS target. The proxy connection protocol and the target website's protocol are different concepts.

Follow the format generated by the Gleam dashboard and the client's requirements. Do not change the proxy protocol simply because the target URL starts with https://.

Changing the proxy URL from http:// to https:// without checking support may cause the client to use a different connection method to the gateway, resulting in handshake or connection errors.

What Is the Difference Between a Gleam Gateway and a Proxy Exit?

Gleam's current documentation provides gateways for different routes, for example:

Asia-Pacific gateway: tun-hk.ipgleam.net
Europe/Americas gateway: tun-us.ipgleam.net

The gateway determines where a request enters the Gleam proxy network, but it does not directly determine the final exit country.

Connecting to the Asia-Pacific gateway does not mean only Asian exits are available. Connecting to the Europe/Americas gateway does not guarantee a US exit either.

The target country or region is controlled by the location parameters in the proxy generator.

When selecting a gateway, test based on the application's deployment location, the target website's region, and actual connection latency. Do not infer the exit location solely from the gateway's domain name.

After configuration, verify the following in order:

1. Confirm that the request successfully passes through the proxy.
2. Confirm that the server's real public IP has been replaced.
3. Confirm that the exit country or city matches expectations.
4. Test repeatedly to check that sticky sessions are reasonably stable.
5. Only then access the production target website.

How Can You Keep Proxy Passwords Out of Source Code?

The hardcoded approach above is suitable for an initial local test, but not for direct use in a production project.

If the code is committed to GitHub, copied into a support ticket, or written in full to an error log, the username and password may be exposed as well.

A better approach is to store proxy information in environment variables:

export PROXY_HOST="tun-hk.ipgleam.net"
export PROXY_PORT="10000"
export PROXY_USERNAME="YOUR_COMPLETE_USERNAME"
export PROXY_PASSWORD="YOUR_PASSWORD"

Then read these variables in Python:

import os
from urllib.parse import quote

import requests

host = os.environ["PROXY_HOST"]
port = os.environ["PROXY_PORT"]
username = quote(os.environ["PROXY_USERNAME"], safe="")
password = quote(os.environ["PROXY_PASSWORD"], safe="")

proxy_url = f"http://{username}:{password}@{host}:{port}"

session = requests.Session()

session.proxies.update({
    "http": proxy_url,
    "https": proxy_url,
})

response = session.get(
    "https://api.ipify.org?format=json",
    timeout=(10, 30),
)

response.raise_for_status()
print(response.json())

quote() handles the username and password because characters such as @, :, and / have special meanings in URLs.

If the password contains these characters, directly joining the values may prevent an otherwise normal-looking proxy URL from being parsed correctly.

Even after moving credentials to environment variables, do not print the full proxy_url in logs. Environment variables keep credentials out of source code, but they cannot prevent passwords from leaking through logs, screenshots, or support emails.

Production projects can also use a secrets management system and restrict access to the service account running the tasks.

How Should Gleam Location and Sticky Session Parameters Be Used?

Gleam includes location and sticky session parameters in the complete proxy username.

The format in the documentation looks like this:

YOUR_USERNAME-A-US-T-10m-C-price001

This username indicates:

1. US is the target region.
2. 10m is the sticky session duration.
3. price001 is the identifier for this session.

For integration, copy the complete output from the proxy generator rather than manually assembling parameters in code without checking them.

A missing separator may cause authentication to fail immediately. An incorrect location code may still allow the application to connect, but the exit location may not match the task's requirements.

Another common problem is regenerating the session identifier after -C- for every request.

The user may believe a 10-minute sticky session is configured, while every request actually creates a new session, allowing the exit IP to change.

Why Should the Session Identifier Follow the Task?

Suppose a price monitoring task needs to perform the following sequence:

1. Open a product listing.
2. Select a category.
3. Enter a product detail page.
4. Check the delivery page.
5. Read the stock status.

These steps belong to the same business workflow and should use the same complete proxy username and session identifier.

The next independent product task can create a new session identifier.

This helps preserve the access environment for the current workflow without keeping large numbers of unrelated tasks on the same exit indefinitely.

When a failure occurs, decide whether to retain the original session based on the business objective.

If a read timeout occurs and the current workflow needs to continue, it is usually appropriate to retain the session. If the workflow has been abandoned and the application will start again, a new session can be created, but the change should be logged.

A sticky session is not a permanently fixed IP. Session expiry, network changes, or adjustments to proxy resources may still change the exit, so the application must continue checking important page state.

How Should Python Proxy Request Retries Be Configured?

Proxy authentication failures, gateway connection timeouts, and target website read timeouts should not all be handled in the same way.

The following code retains the necessary error classification without making the logic overly complicated:

import os
import time
from urllib.parse import quote

import requests


def build_proxy_url():
    username = quote(os.environ["PROXY_USERNAME"], safe="")
    password = quote(os.environ["PROXY_PASSWORD"], safe="")
    host = os.environ["PROXY_HOST"]
    port = os.environ["PROXY_PORT"]

    return f"http://{username}:{password}@{host}:{port}"


session = requests.Session()

proxy_url = build_proxy_url()

session.proxies.update({
    "http": proxy_url,
    "https": proxy_url,
})


def fetch(url, max_attempts=3):
    retryable_statuses = {429, 500, 502, 503, 504}

    for attempt in range(1, max_attempts + 1):
        try:
            response = session.get(
                url,
                timeout=(10, 30),
                allow_redirects=True,
            )

            if response.status_code == 407:
                raise RuntimeError(
                    "Proxy authentication failed; check the username, password, or IP allowlist"
                )

            if response.status_code in retryable_statuses:
                if attempt == max_attempts:
                    response.raise_for_status()

                time.sleep(attempt * 2)
                continue

            response.raise_for_status()
            return response

        except requests.exceptions.ProxyError as error:
            raise RuntimeError(
                "Proxy connection or authentication failed; automatic retries stopped"
            ) from error

        except requests.exceptions.ConnectTimeout:
            error_type = "Proxy gateway connection timed out"

        except requests.exceptions.ReadTimeout:
            error_type = "Target website read timed out"

        except requests.exceptions.ConnectionError:
            error_type = "Network connection error"

        if attempt == max_attempts:
            raise RuntimeError(
                f"{error_type}; maximum retry attempts reached"
            )

        time.sleep(attempt * 2)

    raise RuntimeError("Request did not complete")


result = fetch("https://api.ipify.org?format=json")
print(result.json())

The most important aspect of this code is not the three-attempt limit, but that it does not blindly retry every error.

HTTP 407 usually indicates that proxy authentication failed. Invalid credentials do not fix themselves after a few seconds, so the application should stop making requests and check the configuration.

Connection timeouts, read timeouts, and some temporary server errors can be retried a limited number of times. A clear limit is essential; otherwise, a single fault can become ongoing proxy data consumption.

Production projects can also add randomized delays to avoid having many tasks retry simultaneously.

How Should You Choose Between Username/Password Authentication and IP Allowlisting?

Gleam supports both username/password authentication and allowlisting a fixed public IP.

For an application deployed on a server with a fixed public IP, IP allowlisting is an option. The client does not need to send a proxy password, but the allowlist must be updated if the server's public IP changes.

Username/password authentication is better suited to cloud servers, multiple devices, or environments with changing public exit IPs. Location and session parameters can also be configured through the complete username.

Neither method is universally better. The choice mainly depends on deployment stability and whether the application needs to change locations and sessions dynamically.

Why Should You Not Immediately Increase Concurrency After Connecting?

A successful IP lookup only proves that basic authentication and network connectivity work.

Before increasing concurrency, run a sample of real tasks to confirm:

1. Whether the exit location is correct.
2. Whether sticky sessions behave as expected.
3. Whether production target pages are accessible.
4. Whether redirects keep the task in the target market.
5. Whether retries retain the correct session.
6. How much data an average task consumes.
7. Whether success rates and latency change significantly as concurrency increases.

Running a few dozen real tasks before gradually increasing concurrency makes troubleshooting easier than starting with hundreds of threads.

More threads cannot fix incorrect authentication, location parameters, or session logic. They only make the same errors recur faster.

Frequently Asked Questions

What does HTTP 407 returned by Requests mean?

HTTP 407 usually indicates that proxy authentication failed. Check the complete username, password, authentication method, and, if using allowlisting, whether the server's public IP is authorized.

Why does the proxy URL still use http:// when accessing an HTTPS website?

The client can establish a tunnel through an HTTP proxy and then access the HTTPS target. The proxy connection protocol and target website protocol do not have to be identical.

Why does the IP still change after a retry when a sticky session is configured?

First check whether the retry code generated a new session identifier and whether the sticky session duration has expired. Sticky sessions are not permanently fixed IPs; network or resource changes can also change the exit.

Can Requests and Playwright use the same Gleam proxy?

Yes, but their configuration methods differ. Both require the correct proxy gateway, port, complete username, and password.

Can I print the complete proxy URL in logs for troubleshooting?

This is not recommended. A complete proxy URL usually contains the username and password. Logs should retain only the gateway, port, and masked account or session identifiers.

Does Gleam automatically parse web pages and return structured data?

No. Gleam provides residential proxy exits, location targeting, and session control. Web requests, field parsing, data cleaning, and storage are still handled by the user's application.