SOCKS5 and UDP
Port 7001 is a SOCKS5 proxy with a login and password, for TCP and for UDP. Use it for apps that are not web browsers, and for UDP, which the HTTP port cannot carry.
What port 7001 supports
| Part of SOCKS5 | On our gateway |
|---|---|
| Authentication | Username and password only. A client that offers no login gets “No authentication method was acceptable” |
| CONNECT (TCP) | Yes, to a host name or an IP address |
| UDP ASSOCIATE | Yes, on residential and mobile |
| BIND | No: reply 7, command not supported |
| Login keys | The same as on port 7000: -cc-, -st-, -city-, -isp-, -car-, -sid-, -ttl- |
| Traffic | Counted in GB like HTTP, both directions, UDP datagrams included |
Send host names rather than addresses, so the name is resolved at the exit and not on your machine. In curl and Python requests that is the socks5h:// scheme:
curl -x "socks5h://LOGIN-cc-us:[email protected]:7001" https://api.ipify.orgClients treat socks5:// differently; the SOCKS5 guide has a table of who resolves the name where.
HTTP or SOCKS5?
| What you run | Port |
|---|---|
| Websites in a browser, an antidetect profile or a scraper | HTTP, 7000. Browsers and libraries handle an HTTP proxy login, while Chromium-based browsers cannot send a SOCKS5 login at all |
| Apps with their own protocol over TCP, such as Telegram | SOCKS5, 7001 |
| UDP: DNS, QUIC, voice and video, games | SOCKS5, 7001, with a client that implements UDP ASSOCIATE |
| System-wide routing and tunnel apps | SOCKS5 when UDP has to go through the proxy too; whether the app relays UDP is in its setup guide |
How UDP goes through the gateway
- Your client opens a TCP connection to port 7001, logs in and sends UDP ASSOCIATE.
- The gateway answers with an address and a UDP port to send datagrams to.
- The client sends each datagram there with a short SOCKS5 header naming the destination. The gateway relays it through your exit and returns the replies the same way.
- The association ends when the TCP connection closes, so keep that connection open while you need UDP.
Rules for UDP on the gateway:
- Datagrams must come from the IP address that opened the TCP connection. Others are ignored.
- Fragmented datagrams are dropped, so send each one whole.
- Datagrams to mail ports or to sites blocked by default are dropped without a reply (default limits).
- Your network has to let outgoing UDP through to the gateway. Behind a firewall that passes only TCP, UDP ASSOCIATE succeeds and every datagram is lost.
- An association that carries no datagram in either direction for 10 minutes is closed. When it closes, open a new one: with the same sticky login it asks for the same exit while the session lasts.
Rotating or sticky for UDP
Use a sticky login. The UDP association and your TCP connections with the same key then ask for the same exit: in our test of 26 October 2026 the UDP exit matched the TCP exit in 11 of 12 sticky sessions. With a rotating login, every association and every TCP connection gets an exit of its own.
socks5h://LOGIN-cc-us-sid-udp1-ttl-30:[email protected]:7001Open one association per destination server: in the same test, each association answered only for the first server it was used with. The SOCKS5 guide lists clients that implement UDP ASSOCIATE and has a short Python test to run with your own login. The proxy tester also tries UDP ASSOCIATE on every SOCKS5 line and marks the lines where it was granted.
Regular browsers and curl send no UDP through SOCKS5, so their WebRTC and QUIC traffic never reaches port 7001. Some antidetect browsers and tunnel apps do relay UDP; the UDP line of each setup guide says which. WebRTC leaks covers what this means for browser profiles.
Questions
No. The bytes of every datagram count as traffic in GB, in both directions, like everything else.
Usually a firewall on your side that blocks outgoing UDP, a client that sends from another address than its TCP connection, or a destination closed by default. Test with a DNS query first, as in the SOCKS5 guide.
No. HTTP proxies carry TCP only; UDP needs port 7001.