Require a Login on Both 3proxy HTTP and SOCKS Services
Configure 3proxy users, strong authentication, and service access rules for both HTTP and SOCKS5 clients.
Defining a user is not the whole 3proxy login configuration. The service also needs an authentication method and an access rule that uses it. The sequence matters because service settings apply as the configuration is processed.
A local-only example for two services is:
users alex:CL:replace_with_a_private_password
auth strong
allow alex
proxy -i127.0.0.1 -p3128
flush
allow alex
socks -i127.0.0.1 -p1080The configuration reference explains users, auth strong, and the service commands. CL stores this example password as cleartext. Protect the file and choose a supported credential-storage form appropriate for the deployment.
The client needs the right login exchange
The HTTP service expects HTTP proxy authentication. The SOCKS service needs a client supporting SOCKS5 username/password authentication. A SOCKS4 client cannot provide that exchange merely because it reaches the same listener port.
The word strong is an authentication-mode name, not a guarantee of encrypted transport. Protect the client-to-proxy hop when needed. HTTPS to the destination and encryption to the proxy remain separate decisions.
Loopback bindings limit this example to local access. For remote clients, choose an intended listener and network policy explicitly. A public wildcard listener is not a substitute for checking login behavior.
If one service prompts and another does not, inspect the settings before each service command, rules after any flush, and authentication caching. Changing a password cannot repair a service started under the wrong policy. Likewise, changing the daemon's operating-system account does not create a proxy user.