If you need a stable outgoing IP for testing, vendor allowlisting, or one-off admin access, a VPS can double as a lightweight proxy. For most teams, the cleanest approach is not to install a public proxy daemon at all. It is to use SSH dynamic port forwarding, which creates a local SOCKS proxy on your machine and sends traffic through the VPS over an encrypted SSH session.
That distinction matters. A browser or CLI tool connects to localhost:9090 on your laptop. SSH carries the traffic to the VPS, and the destination site sees the VPS IP. This is usually the fastest way to check a site from a known egress IP, reach an IP-restricted admin panel, or reproduce a client issue tied to geography or network policy.
When a VPS proxy is a good fit
Use this pattern when you need a fixed IP address for vendor allowlists, staging access, callback testing, or temporary traffic routing for QA and debugging. It is also useful for agency teams doing client review work from a known location without standing up heavier infrastructure.
Do not treat it as a shared company-wide network layer. A single SSH tunnel is excellent for targeted operational work, but it is not a substitute for managed remote access, zero-trust controls, or a proper VPN if multiple people or systems depend on it every day.
The simplest current setup
The old one-line examples for this topic are usually overpacked. A current, readable default looks like this:
ssh -N -D localhost:9090 [email protected]What it does:
-D localhost:9090starts a local dynamic forward and makes SSH act as a SOCKS proxy on port 9090.localhostkeeps the proxy bound to your own machine, rather than exposing it to other devices on your network.-Ntells SSH not to run a remote shell, because you only want the tunnel.
If you are on a slower connection, you can add -C for compression, but current OpenSSH documentation notes that compression mainly helps on slow links and can slow down fast ones. In other words: do not add it by habit.
How to use the proxy
In your browser or tool, set a SOCKS5 proxy to localhost on port 9090. For command-line testing, curl is a useful quick check:
curl --socks5-hostname localhost:9090 https://example.comThat --socks5-hostname detail is worth knowing. It tells curl to let the proxy resolve the hostname, which is often what you want when you are testing routing or DNS behavior through the VPS, not just the outgoing IP.
Make it reliable enough for repeated work
If you use this more than once, stop retyping the long command and put it in ~/.ssh/config:
Host grn-proxy-vps
HostName your-vps.example
User youruser
DynamicForward localhost:9090
ExitOnForwardFailure yes
ServerAliveInterval 30
Then start it with:
ssh -N grn-proxy-vpsExitOnForwardFailure yes matters because it prevents a false-positive connected state when the forwarding itself failed. ServerAliveInterval 30 helps long-running tunnels notice broken connections instead of hanging indefinitely.
Common failure points
If the tunnel connects but traffic does not pass, check the boring pieces first:
- The VPS must accept SSH from your IP and user account.
- The SSH server must allow TCP forwarding. In OpenSSH,
AllowTcpForwardingisyesby default, but some hardened images or team baselines disable it. - Your local app must be configured for SOCKS5, not HTTP proxy mode.
- If port
9090is already in use, choose another local port such as1080or19090.
If you want the tunnel in the background, use a fail-fast version like this:
ssh -f -N -D localhost:9090 -o ExitOnForwardFailure=yes [email protected]Operational limits to keep in mind
A VPS proxy is practical, but it is not magic. The destination service will see the VPS IP, not your office IP. That is good for allowlisting and reproducible testing, but it also means you are presenting as a data-center network, which some services treat differently from normal end-user traffic.
You should also keep responsibility clear internally. This setup routes traffic through infrastructure you control, so logging, retention, access control, and credentials still need to match your security expectations. For agency teams, that usually means one user account per person, SSH keys instead of passwords, and a short written note explaining when this route should and should not be used.
When to bring in help
If the requirement is one person needing a stable IP for admin work, an SSH tunnel is usually enough. If the requirement is multiple staff, multiple vendors, audit needs, fallback, and repeatability, treat it as an access design problem instead of a proxy shortcut. That is where a short engagement can save time: deciding whether you need SSH tunneling, a managed bastion, a VPN, or something more structured.
If you want a VPS proxy setup that is documented, repeatable, and safe for your team to use without guesswork, Greg can help turn the quick fix into an operationally sane workflow.
Need help with this kind of work?
Need a stable-IP access setup your team can actually run? Greg can help design and document it. Get in touch with Greg.
