Join my community / free newsletter — sign up here

Use a VPS as a Proxy Server with SSH Tunneling

Illustrated infographic summarizing: Use a VPS as a Proxy Server with SSH Tunneling

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:9090 starts a local dynamic forward and makes SSH act as a SOCKS proxy on port 9090.
  • localhost keeps the proxy bound to your own machine, rather than exposing it to other devices on your network.
  • -N tells 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.com

That --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-vps

ExitOnForwardFailure 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, AllowTcpForwarding is yes by default, but some hardened images or team baselines disable it.
  • Your local app must be configured for SOCKS5, not HTTP proxy mode.
  • If port 9090 is already in use, choose another local port such as 1080 or 19090.

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.

Sources

Last modified
2026-06-01

Tags