A practical server-side setup order for a self-hosted proxy IP: verify SSH access first, change the port and switch to key authentication, apply basic hardening, install the proxy service and open its port, then connect and verify from the client.
When you buy a cloud server to use as a proxy, the main difficulty is rarely basic connectivity. More often, it is the order in which the server side is prepared. Get the order right and the client usually connects on the first try; get it wrong and you will keep jumping back to the terminal to change settings.
This guide focuses only on the server side: the first login, tightening access, starting the proxy service, opening ports, connecting from the client, and troubleshooting layer by layer if the connection fails.
First login: verify access before anything else
After the instance is created, first sign in through the provider's web terminal in the console instead of relying on a local tool immediately. The goal at this stage is simply to confirm that the machine is running and the network is reachable.
Once inside, switch to root by running sudo -i and pressing Enter. When the prompt changes from $ to #, privilege escalation has succeeded. Perform the remaining steps under this identity.
Write down four pieces of information while you are there: the public IP, login username (root by default on Linux), password, and SSH port (22 by default). These are the four values the client needs, and a connection will fail if any one is missing.
Change the default port, then switch to key-based login
Port 22 is scanned countless times every day, and credential-stuffing attempts are routine. Changing the port does not make the server inherently stronger, but it filters out most automated noise.
The change is made in /etc/ssh/sshd_config. Open it with vi, press i to enter edit mode, change the PermitRootLogin and PasswordAuthentication lines to yes, then press Esc and enter :wq to save and exit. If the provider supports key-based login, a more robust approach is to add your local public key to the server's authorized_keys and then change PasswordAuthentication to no so that only keys are accepted.
Do not close the current session immediately after changing the configuration. Open a second terminal window first, log in once with the new port and authentication method, confirm that it works, and only then close the old window. Otherwise, a configuration mistake can lock you out and force you to recover through the provider console.
The SSH port is set on the Port line. After changing it, restart the SSH service so the configuration takes effect. On Debian and Ubuntu systems, you can run /etc/init.d/ssh restart.
Apply basic hardening on the first day
Beyond changing the port and using keys, two small tasks are worth finishing on day one. First, set a sufficiently long random password for root with passwd root instead of using a guessable combination. Second, disable services and ports you do not need. The less software that is exposed, the smaller the attack surface; the system firewall should allow only ports that are actually required.
If the server will be used for only a few fixed source locations over the long term, restrict source addresses to those locations in the security group. That is much safer than opening access to the entire internet.
Install the proxy service and configure authentication
Once server initialization is complete, move on to the proxy itself.
One option is to use an SSH tunnel directly. Nothing extra has to be installed on the server; the client uses the system's built-in SSH service for forwarding, with the same server account credentials. It is convenient, but performance is average and high concurrency becomes difficult, so it fits temporary use or a small number of accounts.
The other option is to install a dedicated proxy service. It can usually be installed with one command, after which you configure the authentication method and listening port yourself. Remember to enable it at boot; otherwise, one server restart will take the proxy offline.
There are three common authentication levels, in increasing order of security: username and password are easiest, but a leak effectively gives away the proxy; password plus a source-IP allowlist is sufficient for everyday use; key or certificate authentication is the strongest, although it takes more setup and is worthwhile for accounts that will run long term.
Open the port in two separate places
This is the point where people get stuck most often. The proxy service's listening port must be allowed both in the system firewall and in the provider's security group. The two are independent, and opening only one of them is not enough.
Another easy-to-miss setting is the service's listening address. Some services bind only to 127.0.0.1 by default. If a local test on the server works but remote access does not, this is often the reason. Change the listening address to the server's private address or 0.0.0.0.
Connect from the local client
Create a new environment in your environment-management tool and select the actual proxy type. If you are using an SSH tunnel, enter the server's public IP as the address, the SSH port as the port, and the server username and password as the credentials. Then run the connection test.
A successful test only proves that the path is reachable. Open the environment and verify three more things: the exit IP should match the server's public IP; DNS should also go through the proxy, because local DNS resolution can reveal a region that does not match the exit IP; and the time zone and language should match the exit region. Only after all three checks pass is the environment ready to use.
As the number of accounts grows, keep the mapping between environments and exit nodes fixed so that several accounts do not share one environment. Tools such as PurpleMark can bind a separate exit to each account, which is more reliable than maintaining a manual mapping table.
If it will not connect, troubleshoot from the outside inward
Start with the outermost layer: is the security group open, and is the system firewall open? Confirm both before going deeper.
Next, check the service itself: is the process still running, especially after a server restart? Is the listening address bound only to the local host?
Then check the authentication layer: is the username or password wrong, and are the key-file permissions too broad? SSHD will reject a key when its permissions are incorrect. Only after that should you check the client side: did you enter the public IP or accidentally use the private IP? That mix-up is especially common.
Following this order usually identifies the failing layer within two or three passes instead of repeatedly reinstalling the service.
Wrap-up
Preparing the server side takes less than half an hour, but it determines how much maintenance the machine will need over the next few months. Tighten access, open the right ports, and configure authentication clearly; after that, the remaining work is routine maintenance.
