What is the difference between SOCKS5 and SOCKS5 with authentication?

Plain SOCKS5 lets any client connect without proving identity (NO_AUTH mode). SOCKS5 with authentication requires the client to complete a username/password exchange defined in RFC 1929 before any traffic flows. The wire protocol is identical — only the method negotiation result changes. On Nodetonet, authentication is always enforced when credentials are configured.

Why does my SOCKS5 client ignore the username and password I set?

The most common reason is a library that offers NO_AUTH in the greeting alongside USER_PASS. If the server also accepts NO_AUTH, it picks the easier option and your credentials are never requested. The fix is to test with a deliberately wrong password — if the connection still succeeds, your server is not enforcing auth. See the debugging section of this post for per-language hints.

Is SOCKS5 authentication encrypted?

No. RFC 1929 specifies that the username and password are sent in cleartext. If the network path between your client and the proxy server is untrusted, wrap the connection in TLS (or use an HTTP proxy with HTTPS). In practice, most Nodetonet connections run over dedicated or already-encrypted links, so this is rarely a concern.

Can I use multiple usernames on one SOCKS5 proxy endpoint?

Yes, through Nodetonet's proxy clients feature. You create multiple credential sets on a single tunnel and each gets its own quota, thread limit, IP allow-list and domain restrictions. The username in the RFC 1929 handshake selects which client is active for that session. See the proxy clients guide for setup instructions.

How do I add a sticky session to a SOCKS5 proxy?

Append a session tag to your username: for example change u8x2 to u8x2-session-abc123. All connections using that tagged username will exit from the same device for the session TTL. You can also combine a session tag with geo modifiers in the same username string.

What happens if I send the wrong SOCKS5 password on Nodetonet?

The edge node responds with RFC 1929 status 01 01 (non-zero = failure) and immediately closes the TCP connection. Your client will see a connection error such as "SOCKS5 authentication failed". Failed attempts are logged in the proxy audit trail, which you can review in your panel.

Does SOCKS5 auth work the same way on rotating and sticky proxies?

Yes. The RFC 1929 handshake is identical regardless of the rotation mode. What changes is how the proxy selects the exit device after auth succeeds: rotating picks a new device each connection, sticky pins to one for the session TTL. Auth is always the first step, before any routing decision is made.

Can SOCKS5 proxies on Nodetonet carry non-web traffic?

Yes. SOCKS5 is a general TCP proxy protocol — it can tunnel any TCP connection: database clients, game servers, custom tools, SSH, and more. Unlike HTTP proxies, SOCKS5 does not interpret or rewrite the payload, making it suitable for protocols that do not speak HTTP. UDP support depends on the proxy configuration.

SOCKS5 with authentication — how it actually works and why libraries get it wrong

SOCKS5 has a well-earned reputation as the proxy protocol that handles everything — raw TCP, UDP, any application, any target. But its authentication layer is a separate sub-protocol with its own RFC, its own wire format, and a long history of client libraries quietly breaking it. Set credentials on a proxy server, and a surprising number of popular libraries will still connect without actually sending those credentials, because they negotiate no-auth instead.

TL;DR: SOCKS5 auth is a two-round handshake defined in RFC 1929. To stay secure, the server must refuse the no-auth fallback whenever credentials are configured — something Nodetonet does by default. This post walks every byte of the handshake, explains exactly how Nodetonet enforces it, and shows you how to verify your own client library is not silently bypassing auth.

Why SOCKS5 auth is its own little world

When most people say "SOCKS5 with a username and password" they imagine it works like HTTP Basic auth — credentials in the header, done. SOCKS5 works nothing like that. The protocol separates method negotiation (which auth type to use) from credential exchange (the actual username and password), and it does so in two distinct, sequential handshakes before any traffic flows. Both are specified at the byte level, and a single wrong octet will close the connection.

Understanding the handshake is not just academic. The most common real-world failure mode — where a scraper runs for days without credentials and the operator never notices — is caused directly by method negotiation going wrong. See the SOCKS5 proxy glossary entry for a higher-level overview, and read on here for the wire detail.

The two-stage SOCKS5 handshake, byte by byte

Stage 1 — method negotiation

Every SOCKS5 connection starts with a greeting from the client. The client sends a list of auth methods it is willing to use:

05 02 00 02
^  ^  ^  ^
|  |  |  +-- method 2: USERNAME/PASSWORD (0x02)
|  |  +----- method 1: NO_AUTH (0x00)
|  +-------- number of methods offered
+----------- SOCKS version (5)

The server reads the list, picks exactly one method it accepts, and replies with two bytes:

05 02      -- "I choose USERNAME/PASSWORD"
05 00      -- "I choose NO_AUTH" (if that is all you offered, or all I support)
05 FF      -- "None of your methods are acceptable — bye"

If the server responds with FF, the connection is closed immediately. If it responds with 02, the client must proceed to the credential exchange. If it responds with 00 — and the client offered 00 in the greeting — the connection continues without any credential check. That is the silent-fallback trap.

Stage 2 — RFC 1929 credential sub-negotiation

When the server selects method 0x02, the client sends a separate auth packet defined entirely by RFC 1929 (not the base SOCKS5 RFC):

01 <ulen> <username bytes> <plen> <password bytes>
^
+-- subnegotiation version (always 0x01)

The server validates the credentials and responds:

01 00      -- auth success
01 01      -- auth failure (any non-zero byte means reject)

A non-zero status byte means the server closes the connection. Only after a 01 00 success does the client send the actual CONNECT, BIND or UDP_ASSOCIATE request. This means credential validation happens before any proxied traffic flows — which is correct by design.

The full flow in one view

Step	Who sends	What it carries	Purpose
1	Client	Greeting: version + method list	Propose auth methods
2	Server	Version + chosen method	Select method (or reject)
3	Client	RFC 1929 auth packet	Send username + password
4	Server	RFC 1929 response	Accept or reject credentials
5	Client	CONNECT / BIND / UDP request	Open the actual proxy tunnel
6	Server	SOCKS5 reply (0x00 = OK)	Confirm tunnel open

Steps 3 and 4 are entirely absent when the server selects NO_AUTH. The danger is that a library might present the greeting as 05 02 00 02 (offering both methods) but the server chooses 00 — the credentials are never sent and the tunnel opens anyway.

How Nodetonet enforces authentication

When you create a SOCKS5 proxy in your Nodetonet panel, a unique username:password pair is generated automatically. The edge node listening on the assigned port applies the following rules on every fresh TCP connection:

The edge only advertises method 0x02 (USERNAME/PASSWORD) in its server-selection reply. It never selects 0x00 when credentials are configured, so a fallback client gets 05 FF and a clean connection error rather than a silent free pass.
The credential check is constant-time to prevent timing-based username enumeration.
The check is scoped to that single proxy — credentials from one proxy cannot authenticate another.
Failed attempts are counted and visible in your proxy audit log, making credential-spraying attacks easy to spot.

Per-client credentials (proxy clients)

If you have configured proxy clients on a single tunnel — multiple credential sets so you can hand each customer their own username/password — the username in the RFC 1929 packet determines which client is matched. From that point on, that client's individual quota, thread limit, IP allow-list and domain restrictions apply for the entire session. This means one SOCKS5 endpoint can serve dozens of different customers with fully isolated controls.

SOCKS5 credentials are transmitted in cleartext on the wire — that is specified by RFC 1929, not a Nodetonet choice. If the path from your client to the edge server crosses an untrusted network, wrap the connection in TLS at the application layer, or use our HTTP/HTTPS proxy option which supports end-to-end encryption. For most use cases the edge is reached over a dedicated or already-encrypted link, so the cleartext nature of SOCKS5 auth is rarely a practical issue.

The silent-fallback pitfall — and how to detect it

The most dangerous scenario is not a connection error — it is a connection that succeeds but runs without auth. This happens when the client library offers both NO_AUTH and USER_PASS in its greeting, the server (misconfigured or too permissive) selects NO_AUTH, and the library proceeds happily. Your scraper appears to work, but no credentials were validated.

Common offenders by language

Python requests[socks] + PySocks < 1.7 — silently drops credentials for certain target URL schemes. Upgrade PySocks and verify with a scheme that triggers the bug.
Node.js socks-proxy-agent — if you construct the agent via a URL string and also set userId to an empty string in the options object, the options field wins and the effective username becomes empty. The library still connects if the server allows empty-username auth.
Go golang.org/x/net/proxy — when the Auth struct pointer is nil, it dials without any auth method offered and succeeds if the server permits NO_AUTH. No warning is emitted.
PHP cURL + CURLOPT_PROXYTYPE CURLPROXY_SOCKS5 — cURL's SOCKS5 (without the _HOSTNAMERESOLUTION variant) has historically had edge cases where auth was not forwarded for HTTPS targets.

The one-line proof

The definitive test: send a request with deliberately wrong credentials. If your proxy server is correctly enforcing auth, this must fail:

curl --socks5 user:WRONGPASSWORD@sub42.nodetonet.com:48888 https://api.ipify.org
# Expected: curl: (7) Unable to receive initial SOCKS5 response
#           OR: SOCKS5 authentication failed

If the request succeeds with wrong credentials, your server is accepting NO_AUTH. Fix: confirm the server is in credential-required mode and that the client is not offering 0x00 as a fallback method. You can verify what IP emerged with the What is my IP tool.

Quick-start snippets — correct auth in four languages

In every snippet below, replace u8x2 / p7q1 with the credentials from your proxy panel and adjust the host/port to match your assigned endpoint.

# curl — plain SOCKS5 with user/pass
curl --socks5 u8x2:p7q1@sub42.nodetonet.com:48888 https://api.ipify.org

# curl — resolve hostname through the proxy (avoids local DNS leak)
curl --socks5-hostname u8x2:p7q1@sub42.nodetonet.com:48888 https://api.ipify.org

# Python — requests + PySocks (pip install requests[socks])
import requests

proxies = {
    "http":  "socks5h://u8x2:p7q1@sub42.nodetonet.com:48888",
    "https": "socks5h://u8x2:p7q1@sub42.nodetonet.com:48888",
}
# socks5h = resolve hostnames through the proxy (recommended)
r = requests.get("https://api.ipify.org", proxies=proxies, timeout=15)
print(r.text)

// Node.js — socks-proxy-agent (npm install socks-proxy-agent)
import { SocksProxyAgent } from 'socks-proxy-agent';
import https from 'https';

const agent = new SocksProxyAgent('socks5://u8x2:p7q1@sub42.nodetonet.com:48888');
https.get('https://api.ipify.org', { agent }, (res) => {
  res.on('data', (d) => process.stdout.write(d));
});

// Go — golang.org/x/net/proxy
package main

import (
    "fmt"
    "io"
    "net/http"
    "golang.org/x/net/proxy"
)

func main() {
    auth := &proxy.Auth{User: "u8x2", Password: "p7q1"}
    dialer, _ := proxy.SOCKS5("tcp", "sub42.nodetonet.com:48888", auth, proxy.Direct)
    transport := &http.Transport{Dial: dialer.Dial}
    client := &http.Client{Transport: transport}
    resp, _ := client.Get("https://api.ipify.org")
    body, _ := io.ReadAll(resp.Body)
    fmt.Println(string(body))
}

SOCKS5 auth with Nodetonet advanced features

Sticky sessions

On a rotating proxy, you get a different exit IP on every new connection. If you need the same IP for a whole login or checkout flow — a sticky session — append a session ID to the username: u8x2-session-abc123. The proxy routes all connections with that session tag through the same device for the session TTL. This works identically over SOCKS5 and HTTP.

Geo-targeting via username modifiers

You can combine auth credentials with geo-targeting modifiers in the same username string — for example u8x2-country-tr-session-1 routes through a Turkish mobile IP with a pinned session. No endpoint change needed. For location-specific options see Turkey, Istanbul, Turkcell and similar pages.

Using SOCKS5 for TCP fingerprint spoofing

Because SOCKS5 forwards raw TCP rather than rewriting the HTTP layer, Nodetonet can also apply TCP/IP fingerprint spoofing at the edge — changing the OS-level TCP parameters seen by the target. This is invisible to the client application and adds another layer of trust beyond just the IP address.

Choosing between HTTP and SOCKS5 on Nodetonet

Nodetonet serves both protocols from the same device pool, so this is a per-use-case choice rather than a platform limitation. See the full breakdown in HTTP vs SOCKS5 — which to pick. As a quick guide:

Use HTTP/HTTPS for browsers, Playwright/Puppeteer, most scrapers — the library ecosystem is more mature and URL-based config is universal.
Use SOCKS5 for non-HTTP traffic (custom TCP tools, game clients, database connections through a proxy), or when you need the proxy to forward raw bytes without any HTTP wrapping.
Both support username/password auth in the same format; the RFC 1929 handshake described in this post applies to SOCKS5. For HTTP proxies, credentials travel in the Proxy-Authorization: Basic header.

If you want to see SOCKS5 proxies alongside your full proxy list and manage client credentials, visit the SOCKS5 and HTTP proxies feature page or create a free account.