In IPv6 Proxy Script, the authentication mode decides who can connect to your proxies. Choose random mode if you hand proxies out to different people or customers, fixed mode if you use them all yourself in one tool, and IP-protected mode if the address you connect from does not change. Public mode asks for no credentials at all, so keep it for short tests or for setups where access is restricted some other way.
You pick the mode during proxy setup, right after entering the starting port. It is a separate setting from refresh and rotating, which decide when the IPv6 address changes: authentication controls who gets in, refresh and rotating control the address traffic leaves from. We covered address changes in rotating vs refresh mode in IPv6 Proxy Script. If the script is not installed yet, follow the IPv6 Proxy Script installation guide first.
Which authentication modes does IPv6 Proxy Script offer?
The script has five options. They differ in what is checked when a client connects and what you enter in your application:
| Mode | Checked on connection | What you enter in the app |
|---|---|---|
| Random | A username and password unique to each port | IP, port and that port’s username and password |
| Fixed | One username and password shared by all ports | IP, port and the same username and password on every port |
| Public | No credential check | IPV4:PORT only |
| IP-protected | Port credentials and an allowlisted client IP | IP, port and that port’s username and password |
| IP-protected passwordless | An allowlisted client IP only | IP and port only |
The allowed IP is the public address of the machine that connects to the proxy, meaning the computer or server your application runs on. You reach the proxy through an IPv4 address and port, so this is an IPv4 address. Do not confuse it with the IPv6 address the target site sees.
What is the difference between random and fixed mode?
Both modes ask for a username and password on every connection. The difference is whether those credentials are shared across ports.
In random mode every port has its own credentials. If one line leaks, only that port is exposed. This helps when you split proxies up: give 50 ports to five teammates, ten each, and nobody can use someone else’s ports with their own password. The cost is admin work. You have to load the list into your application line by line, and tools that take a single username and password for the whole list make this mode awkward.
In fixed mode all ports share one username and password. Setup is quick in tools that take a proxy list with a single set of credentials, since only the port number differs from line to line. On the other hand, anyone who knows the credentials can use every port. If the password leaks, or you stop working with someone you shared the list with, you have to renew the credentials on all ports.
If you use the list alone and in one tool, fixed mode is enough. If you share it with several people or customers, pick random mode.
When should you use public mode, and what is the risk?
Public mode has no username or password; proxies come as IPV4:PORT only. It is convenient with tools that do not support proxy authentication or have trouble storing the password.
That is also where the risk comes from. Anyone who knows the server’s IPv4 address and port, or finds it with a port scan, can use the proxy. Scans looking for open proxies run on the internet all the time, and traffic through a port they find leaves from your IPv6 subnet. Abuse complaints caused by that traffic reach your hosting provider under your address, and the bandwidth comes out of your server.
Use public mode in two cases: for a connection test that lasts a few minutes, or when the server firewall opens the proxy ports to your own IP only. For tests, the script’s time-limited proxy option fits well; once the time is up the proxies stop working, so a port is never left open by accident. For permanent use, IP-protected passwordless mode covers the same need more cleanly.
How does IP-protected mode work, and when should you pick the passwordless variant?
In IP-protected mode the proxy checks two things: that the connection comes from an address you allowed, and that the port credentials are correct. An address that is not on the allowlist cannot connect even with the right username and password. A leaked list is useless on its own. Of the five modes, this one keeps access the tightest.
The passwordless variant checks the IP only. You do not enter a username or password in your application, and unauthorized connections are still refused. It suits bots running from a server with a static IP, browser automation, and tools that have no field for a proxy password.
The condition for this mode is that your connecting address stays the same. On home and mobile connections the IP can change when the modem restarts or on the carrier’s side. The moment it changes, the proxies stop working, because the new address is not on the allowlist. If you use the proxies from a server or VDS with a static IP, this does not happen.
To find the address to allow:
- Run this command on the machine that will use the proxies:
curl -4 https://api.ipify.org - The command prints the IPv4 address that machine uses on the internet. Enter it as the allowed IP during setup.
Which authentication mode should you choose for which job?
Two questions settle it: how many people will use the proxies, and does your connecting IP stay the same?
| Situation | Recommended mode | Why |
|---|---|---|
| You use the proxies yourself in one tool | Fixed | One set of credentials works on every port |
| You split ports among teammates or customers | Random | A leaked line does not affect other ports |
| You use the proxies from a server with a static IP | IP-protected | Even with a leaked list, an unlisted address cannot connect |
| Your tool has no proxy password field and your IP is static | IP-protected passwordless | No password needed, access stays restricted |
| You are running a connection test of a few minutes | Public, with a time-limited setup | Nothing to configure, and the proxies close when time runs out |
Authentication stops other people from using your proxies; it does not change what the target site allows. As the server owner you are responsible for the traffic that leaves through your proxies. Keep your request rate and volume within the target site’s terms of use.
How do you test the authentication setting?
After setup, two attempts show whether the setting works: one with the right credentials and one without any.
- Pick one line from your proxy list and put its details into the command.
- Try the HTTP proxy with the right credentials. The command should print an IPv6 address:
curl -s -x http://USERNAME:PASSWORD@IPV4:PORT https://api64.ipify.org; echo - Try the same port without credentials and read the status code:
In random, fixed and IP-protected mode you should see 407. This is the standard HTTP code a proxy returns when it requires authentication, defined in RFC 9110. In public mode, and in IP-protected passwordless mode from an allowed machine, a 200 is expected.curl -s -o /dev/null -w "%{http_code}\n" -x http://IPV4:PORT http://api64.ipify.org - For a SOCKS5 proxy, use this command with the right credentials:
SOCKS5 username and password login follows RFC 1929.curl -s --socks5-hostname IPV4:PORT -U USERNAME:PASSWORD https://api64.ipify.org; echo - Test the IP-protected modes from a machine that is not on the allowlist, for example a computer tethered to your phone’s mobile connection, using the same commands. The request should fail. If the connection is cut right away, the second command prints 000.
If the attempt with the right credentials returns an IPv4 address instead of IPv6, the problem is on the outbound side, not in authentication. Check that IPv6 is enabled on the server and that the subnet is set up correctly.
What are common authentication mistakes?
| Symptom | Likely cause | Fix |
|---|---|---|
| 407 even with the right password | The password is written inside the proxy URL and contains a special character such as @ or : | URL-encode the character (%40 for @), or use -U in curl and separate username and password fields in your app |
| Some ports connect, others return 407 | In random mode, the first line’s credentials were entered for every port | Enter each port with the username and password from its own line |
| Proxies that worked yesterday do not connect at all today | Your connecting IP changed while in IP-protected mode | Get the new address with curl -4 and set it as the allowed IP, or connect from a machine with a static IP |
| Unexpected traffic and bandwidth use on a public port | The port is open to everyone | Switch to IP-protected mode, or restrict the ports to your IP in the firewall |
| Credentials are right but the proxy does not respond | The server restarted and the proxy services were not started | Restart the proxies from the script menu |
The script puts the proxy list into an encrypted ZIP file and gives you a download link. Send the link and the ZIP password to the person who will use the proxies through separate channels; if both go in the same message, the encryption does little. If the link returns a 301 error, use the SFTP method in the 301 Moved Permanently error guide to get the list straight from the server.
All product features and licensing details are on the IPv6 Proxy Script page, and the installation and troubleshooting guides are in the IPv6 Proxy knowledge base.
Frequently asked questions
Does the authentication mode affect rotating or refresh?
No. The authentication mode decides who can connect to the proxy, while rotating and refresh decide when the outbound IPv6 address changes. You choose them separately.
Do the username and password change when refresh mode changes the IPv6?
No. Only the outward IPv6 address changes. The IPv4 address you connect to, the port and the credentials stay the same.
Do I enter an IPv6 address as the allowed IP in IP-protected mode?
You enter the address of the machine that connects to the proxy. Since you connect through IPV4:PORT, that is the IPv4 address the machine uses on the internet. The IPv6 address the target site sees does not go here.
Which mode should I use with a tool that does not support proxy passwords?
If the tool runs on a machine with a static IP, use IP-protected passwordless mode. Public mode works too, but the port stays open to anyone who knows it.