One website needs a different proxy from the rest of your HTTPS requests. Requests can express that choice in the proxy dictionary itself:

routes = {
    "https://reports.example": "http://reports-proxy.example:8080",
    "https": "http://default-proxy.example:8080",
}
response = requests.get(
    "https://reports.example/monthly",
    proxies=routes,
    timeout=(5, 20),
)
response.raise_for_status()

The hostname-specific key wins for that destination. Another HTTPS hostname uses the scheme-wide entry. The values describe the proxy connection, so an HTTPS destination can correctly map to an HTTP proxy URL. When these are permitted public-site routes without proxy accounts, the HTTP proxy list can supply candidates for those values; keep each destination rule explicit.

Match a hostname, not a resource URL

In Requests 2.32.5, the specific key is built from the destination scheme and parsed hostname. It does not contain the path, query or port.

Adding /monthly to the dictionary key will not restrict the rule to that path. Likewise, https://reports.example:8443 is not a port-specific key recognized by this selector. The hostname rule also applies when the destination URL uses another port.

There is no wildcard expansion in this lookup. A rule for reports.example does not automatically cover a subdomain. Use an explicit routing decision outside this simple dictionary when the policy needs path, port or suffix matching.

Know which fallback comes next

The implementation checks keys in this order: scheme://hostname, scheme, all://hostname, then all. A scheme-wide HTTPS entry therefore takes precedence over an all-schemes hostname entry. Put a scheme-specific hostname rule first in your design when that is the intended exception.

Also account for how your Session merges defaults and environment-derived settings. Passing these two explicit entries with the request makes their intended routes clear, but does not define a policy for every other destination scheme.

A redirect can introduce another hostname, and proxy selection is relevant to that new destination too. Read the rule as a decision about each URL being requested, rather than a permanent route attached to the first page.

Related articles