Use a VPS as a Proxy Server with SSH Tunneling

By Greg Nowak. Last updated 2026-10-08.

A vendor needs one IP address to allowlist. An agency needs to test a client site from a consistent network. An operations lead needs occasional access to a restricted dashboard. If you already have a VPS, an SSH tunnel can be a practical way to handle these jobs without installing a separate proxy service.

SSH dynamic forwarding creates a SOCKS proxy on your computer. Applications configured to use it connect through the VPS, so their destination sees the VPS’s outgoing IP. Other applications keep their usual connection. This is a useful tool for a defined task, provided someone owns the setup and knows how to check it.

When is a VPS proxy the right choice?

Start with the access requirement. For allowlisting, confirm that your hosting provider keeps the public IP assigned or offers a reserved address. Record that address with the vendor; a server rebuild should not quietly remove your team’s access.

These are design choices, rather than a rule that every team needs heavier infrastructure. A small setup is reasonable when its scope and maintenance are clear. SSH dynamic forwarding handles outgoing TCP connections; it does not publish your laptop as an inbound callback endpoint or route every network protocol.

Start the SSH tunnel

You need an OpenSSH client, a VPS you are authorised to use, and a working SSH account. Use a personal, non-root account with SSH key authentication. On first connection, verify the server’s host-key fingerprint through a trusted channel, such as your provider’s console.

ssh -N -D localhost:9090 -o ExitOnForwardFailure=yes [email protected]

Replace the username and hostname. -D localhost:9090 creates the local SOCKS listener; -N skips the remote shell. Binding to localhost keeps it local to your computer. Leave this terminal open; a quiet session is normal. Press Ctrl+C to stop it. The OpenSSH command manual documents these options.

You do not need to open port 9090 on the VPS firewall: that listener is on your computer. The VPS needs to accept your SSH connection and reach the intended destination. Add -C for compression only if testing shows a benefit on a slow link.

Route the application, then verify the result

Set your application’s proxy type to SOCKS5, host to localhost, and port to 9090. Do not put these values into an HTTP proxy field. In Firefox, open its connection settings and choose manual proxy configuration; Mozilla’s connection settings guide covers the controls and proxy exceptions. A separate browser profile helps keep client testing away from everyday browsing.

For a command-line check, run:

curl --socks5-hostname localhost:9090 https://example.com

According to the curl manual, --socks5-hostname asks the proxy to resolve the destination hostname; --socks5 resolves it locally. Browser DNS behaviour needs its own check: this curl setting does not configure your browser.

A successful response proves that request worked through the proxy, provided no proxy bypass rule applied. To confirm the outgoing IP, use a trusted IP-check endpoint or inspect access logs on a destination you control. Then test the actual vendor dashboard or API. Check proxy bypass rules if the observed address is unexpected.

Make repeated use easier

Add a named entry to ~/.ssh/config:

Host grn-proxy-vps
    HostName your-vps.example
    User youruser
    DynamicForward localhost:9090
    ExitOnForwardFailure yes
    ServerAliveInterval 30
    ServerAliveCountMax 3

Start it with ssh -N grn-proxy-vps. Once tested, ssh -f -N grn-proxy-vps starts it in the background. Record how your team identifies and stops that process.

ExitOnForwardFailure exits if forwarding cannot be set up, such as when the local port is occupied. It does not check destination reachability. The alive settings disconnect an unresponsive SSH session after roughly 90 seconds; they do not reconnect it. These distinctions are documented in the SSH client configuration manual.

If SSH connects but the site does not load

Check the local port, application settings and destination connectivity first. If 9090 is occupied, choose another port in both SSH and the application. Add -v to the SSH command to see connection diagnostics.

Ask the VPS administrator to check forwarding policy. AllowTcpForwarding defaults to yes, but account-specific rules can restrict it. DisableForwarding overrides forwarding settings, and PermitOpen can restrict destinations. The SSH server configuration manual explains these controls. Review the intended account’s policy before changing server-wide settings.

Give the team a workflow they can maintain

Keep using HTTPS: SSH encrypts the laptop-to-VPS leg, while protection beyond the VPS depends on the application protocol. A VPS address also may be treated differently from a residential connection, so test the service you actually need.

For recurring work, document the owner, authorised users, vendor allowlists, start and stop instructions, and a working verification request. Remove access when people leave and assign responsibility for VPS updates. If daily operations depend on this route, decide what happens when the laptop sleeps or the server is unavailable.

Greg can help assess the access requirement, choose an appropriate setup, and document it for the people who will run it. If your team is juggling vendor restrictions or undocumented tunnels, talk to Greg about a maintainable access workflow.

Related on GrN.dk

• NGINX Can Read JSON Before Routing—Should It Handle Your AI API?
• OpenAI Computer Use: Browser Agents Need Credentials, Not Demos
• Before You Buy a GPU: Test Your Team’s Local AI Workload

Need help with this kind of work?

Talk to Greg about your team’s access setup Get in touch with Greg.

Sources

• OpenSSH ssh(1) manual
• OpenSSH ssh_config(5) manual
• OpenSSH sshd_config(5) manual
• curl manual: --socks5-hostname
• Mozilla: Connection settings in Firefox