Fix "Missing dependencies for SOCKS support" in Requests, pip and HTTPX

Missing dependencies for SOCKS support means Requests was given a SOCKS proxy URL, such as socks5:// or socks5h://, and could not import socks, the module that PySocks installs, in the Python that is running. Requests raises it before opening any connection, so the proxy has not been contacted yet.

The proxy URL doesn't have to be in your code: Requests also takes it from ALL_PROXY or all_proxy in the environment. And pip runs on its own bundled copy of Requests, so with that variable set, pip install pysocks stops with the same message.

The results below were recorded on 5 October 2026 with Requests 2.34.2, HTTPX 0.28.1, pip 26.2.1, PySocks 1.7.1 and socksio 1.0.0 on Python 3.13.5 and 3.14.4, with a fresh virtual environment for each case. Both Pythons gave the same results.

Fix 1: install PySocks into the Python that runs your code

python -m pip install "requests[socks]"

The extra adds one package, PySocks, whose importable module is named socks. Installing pysocks by name works too. Use python -m pip, not a bare pip: it installs into the interpreter that the python command starts, while a bare pip can belong to another environment. In the lab, with pip on PATH pointing at a second virtual environment, pip install "requests[socks]" printed Successfully installed PySocks-1.7.1 and the script kept raising the same error.

Check the running interpreter:

python -c "import socks, sys; print(sys.executable, socks.__file__)"

It prints the interpreter and the file that import socks resolved to, which should be socks.py inside that interpreter's site-packages. ModuleNotFoundError: No module named 'socks' means PySocks is missing from this Python.

Fix 2: you never set a proxy

When you pass no proxies, Requests builds them from the environment. Its documentation names http_proxy, https_proxy, no_proxy and all_proxy, plus the uppercase variants. List what your process inherits:

env | grep -i _proxy

In the lab, a script with no proxy in its code raised the error with only ALL_PROXY=socks5://127.0.0.1:1080 set, and again with only lowercase all_proxy. HTTP_PROXY holding a socks5:// URL did the same. Requests issue #3516 is this case: the reporter's environment contained all_proxy, and the code broke on upgrading to Requests 2.11, where a maintainer says support for all_proxy began.

If you want the SOCKS proxy, apply fix 1. If you don't, remove the variable where it is set, such as a shell profile or a container image. Four details from the lab:

• An empty value counts as unset. ALL_PROXY= gave a direct request and status 200.
• Lowercase wins. With all_proxy set and ALL_PROXY emptied, the error remained. Emptying all_proxy removed it even with ALL_PROXY still set. Clear both.
• ALL_PROXY is a fallback. With HTTP_PROXY also set to an HTTP proxy, a request to an http:// URL tried that proxy and never touched the SOCKS code.
• Code can opt out. session.trust_env = False returned 200 with ALL_PROXY still set, and so did adding the host to NO_PROXY.

Proxy environment variables lists which variables each client reads, and the Python Requests proxy guide covers trust_env.

Fix 3: pip fails with Missing dependencies for SOCKS support

pip downloads through a vendored copy of Requests and reads the same variables. With all_proxy or ALL_PROXY set to a SOCKS URL, in a new virtual environment:

$ python -m pip install "requests[socks]"
WARNING: There was an error checking the latest version of pip.
ERROR: Could not install packages due to an OSError: Missing dependencies for SOCKS support.

pip download and pip index versions ended in a traceback instead, with pip._vendor.requests.exceptions.InvalidSchema: Missing dependencies for SOCKS support. as its last line. Clear the variables for that one command:

ALL_PROXY= all_proxy= python -m pip install "requests[socks]"

env -u ALL_PROXY -u all_proxy in front of the command worked as well. Clearing only ALL_PROXY did not, because all_proxy was still set.

Then decide whether the variable should stay exported. With PySocks installed, Requests used the proxy from ALL_PROXY and returned 200 through the lab's SOCKS server. pip did not: pip 26.2.1 stopped with TypeError: PoolKey.__new__() got an unexpected keyword argument 'key_proxy_ssl_context', while pip 25.1.1 installed a package through the same proxy. On pip 26.2.1, keep clearing the variable for pip commands, or set the proxy only for the program that needs it.

Fix 4: AttributeError: module 'socks' has no attribute 'PROXY_TYPE_SOCKS5'

Here import socks found something, but not PySocks. Python searches the script's directory first, or the current directory for python -c and python -m, and adds site-packages last, so a file or folder of yours named socks wins. The check from fix 1 shows what was imported:

Rename the file or folder. In the last row, a plain folder named socks turned the missing-dependency error into the AttributeError, so after renaming it you still need fix 1.

HTTPX: Using SOCKS proxy, but the 'socksio' package is not installed

HTTPX has its own SOCKS dependency. Without it, HTTPX 0.28.1 raises:

ImportError: Using SOCKS proxy, but the 'socksio' package is not installed. Make sure to install httpx using `pip install httpx[socks]`.

python -m pip install "httpx[socks]"

That installed socksio 1.0.0, and the same request returned 200 through the proxy. The other fixes carry over:

• The error appears with proxy="socks5://..." in code and with only ALL_PROXY or all_proxy in the environment. It is raised when the client is built: under ALL_PROXY, httpx.Client() with no arguments failed before any request.
• An empty ALL_PROXY and trust_env=False each gave a direct 200.
• The two libraries are not interchangeable. HTTPX with only PySocks installed still raised the ImportError, and Requests with only socksio still raised InvalidSchema.

To check the import, replace socks with socksio in the command from fix 1. The HTTPX async proxy guide has a complete client setup.

After it imports: choose socks5:// or socks5h:// on purpose

A different error now is progress: with PySocks installed and nothing listening on the proxy port, Requests raised ConnectionError with Connection refused, a network problem.

The scheme is the next decision. In Requests, socks5:// resolves the hostname on your machine and socks5h:// sends it to the proxy, while HTTPX sends the hostname with both. socks5 vs socks5h: what six clients actually send has the logged results for each client, and HTTP vs SOCKS5 proxies helps if you are still choosing a protocol.

How this was tested

On Ubuntu 26.04.1, with everything on 127.0.0.1: python -m http.server as the target and a small SOCKS5 relay that logs every request it receives. Each of the 47 cases ran on both Pythons in a fresh virtual environment, an otherwise empty working directory and an empty home directory, with no proxy variables except the ones named in that case. No proxy account was used; the only outbound traffic was pip talking to PyPI. In every failing case the relay logged no connection.

The lab archive contains the runner, the SOCKS5 relay, the README and the recorded results.

Not tested: macOS and Windows, SOCKS4 and authenticated SOCKS proxies, older releases of Requests and HTTPX, and installers other than pip.

ipvolt is a proxy service for developers that isn't open yet; join the early-access list for one email when it opens.