Running a VPN and a mobile proxy on the same machine

A customer sent me a screenshot of an address check showing a country neither of us had anything to do with. He was in Europe. My lines are in Singapore. The page said a third place, with no reason to be in this story.

He had been at it for two days before writing to me. He had reinstalled his browser, rotated the line twice, changed the port, and started drafting a refund request.

The answer took four minutes once I asked the right question: what else is running on that machine? A personal vpn client. Installed months earlier, set to start with the operating system, doing exactly what it was built to do.

I run the farm those addresses come from, real SIM cards on Singapore networks, and my support inbox lands on my own phone, so I watch how this failure arrives. It arrives as a proxy problem, every single time, and it almost never is one.

I am not here to argue vpn versus proxy. This is about what happens when both are switched on at once on the same computer, an extremely common situation almost nobody has thought through.

They sit at different layers

A vpn works on routes. It creates a virtual network interface and rewrites the operating system’s idea of where packets go, so traffic that used to head for your ordinary connection heads into the tunnel instead. It operates below your applications. Your browser does not consent to it and does not know about it.

A proxy works inside a connection. Your application opens a socket to the proxy, asks it to reach a destination, and the proxy makes that second connection on your behalf. It is a conversation your application chooses to have.

So the two do not conflict in the way people assume. When both are on, the usual result is that your application connects to the proxy, and that connection travels through the vpn tunnel to get there. Read that again. Your traffic still exits at my modem in Singapore, and it arrives at my gateway from the vpn’s exit address instead of from your home connection.

What that actually changes

Two things, and one of them costs money.

The first is what your provider sees. I keep one line per connection with the source address the request arrived from, and when a vpn is in the path that field holds the vpn exit rather than anything to do with you. That is fine, arguably a small privacy win. It also means that when you tell me your line is misbehaving and I go looking for your connections, I am matching on a source address that changed three times since yesterday.

The second, the expensive one, is allowlist authentication. If you authenticate to a proxy by registering the address you connect from, and a vpn sits in front of that connection, you have registered the vpn’s exit. Those exits are shared, they change when you pick a different city, and a lot of clients quietly reconnect to a different server when the first one is busy. Your access works, then it fails, then it works again, and nothing in your own setup changed. The address you were being judged on was never yours.

I have had two customers hit that in the same month. Both were convinced my gateway was flaking.

The third effect is name resolution. A vpn client normally takes over your resolver as part of connecting, because lookups escaping to your home provider are the exact thing it is sold to prevent. So your lookups leave through the tunnel while your requests leave through my modem. The target never sees any of that, since it only ever meets the carrier address. It is still enough to make a leak test read strangely and send somebody down another two hour hole chasing a leak that was never there.

The arrangement that works

The everyday case: a split tunnel vpn, or a full tunnel one without a strict blocking rule, plus a proxy configured in your tool. Traffic goes from your application into the tunnel, comes out at the vpn exit, crosses to my gateway, and leaves through the modem onto the carrier network.

It works. It is slower than it needs to be, because you have added a full round trip through another country before the request even starts, on top of a mobile latency cost you did not need to double. The target at the far end sees the carrier address and nothing else. The vpn stopped mattering the moment the packets reached my gateway.

If that is your situation and the latency is acceptable, there is nothing to fix. Just know it is happening.

The kill switch produces silence

A full tunnel vpn with a kill switch is a firewall rule. It says the machine may send traffic out of the tunnel interface and out of nothing else. That is the whole feature, and a good one: it stops your real address escaping when the tunnel drops.

If the vpn is disconnected, reconnecting, or unhappy for any reason, your connection to my gateway is therefore blocked at the operating system before it goes anywhere. Your tool reports a connection timeout. No error anywhere mentions a vpn, because from your application’s point of view the network simply refused to carry the packet.

That is the signature. Everything times out at once, including things that have nothing to do with a proxy, and a browser you have not proxied at all sits there loading nothing. When a whole machine goes quiet rather than one tool, look at the vpn before you look at anything else.

Split tunnels are where the confusion lives

Split tunnelling lets you list which applications use the vpn and which use the ordinary connection. It sounds like control and behaves like a trap.

The trap is that the list is per application, and your setup usually involves several. Your browser might be on the list while the automation framework driving it is not, or the other way around. A python script and the interpreter it runs under may be treated as one entry or as none. A container gets its own network stack, so a rule written for a program on your desktop has no opinion about what happens inside it.

You end up with part of your traffic in the tunnel and part of it out, and the results look random. One job works, an identical job in a different runner does not, and nothing you can see explains the difference.

My customer with the mystery country was in this state, except worse. His client had not installed a normal default route. It had installed two half routes, each covering half the address space, which between them beat an existing default route without ever replacing it. His routing table still showed his ordinary gateway sitting there looking correct, and none of his traffic was using it. That technique is genuinely popular among vpn clients, and it makes the routing table read as if nothing has happened.

The other direction, briefly

People ask about running the vpn inside the proxy rather than the other way round. It mostly does not work, and the reason is protocol. The common tunnel protocols run over udp, and an http proxy carries tcp connections, the whole shape of a connect request. Nothing there can carry your tunnel, so the vpn either fails to connect or falls back to a tcp mode slow enough to make you regret it.

A corporate vpn is a different animal, usually arriving with a forced internal proxy and an egress policy on top. On a company laptop, start there instead of here.

Five minutes of diagnosis

Three steps, in order.

First, the routing table. You are looking for an interface you did not expect, and specifically for routes covering half the address space each, the pattern that hides in plain sight. If a tunnel interface carries the default path, everything else in your debugging happens on top of that.

Second, find out what address arrives at the proxy, the step people skip. Ask your provider what source address your connections come from, or check your account if the provider exposes it. An address you do not recognise is your answer, found without touching anything else.

Third, turn things off one at a time and repeat one identical request. Proxy off, vpn on. Proxy on, vpn off. Both on. Write down the exit address each time. Four lines of notes and the picture resolves itself, because only one variable moves per run. That third step feels too simple to bother with, and it is the one that ends the argument.

What I tell people to do

My honest position is that a personal vpn and proxy work belong on separate machines, and the reason is bookkeeping rather than anything technical. Once both are running you lose the ability to reason about where any given packet is going, and every subsequent problem takes twice as long to think about.

If the machine is for account work or scraping, take the vpn off it and keep a separate machine or a virtual machine for the browsing you wanted the vpn for. The separation costs almost nothing and removes an entire category of two day mystery.

If you genuinely need both, pin the vpn to one server rather than letting the client choose, authenticate to the proxy with credentials instead of an allowlist, and write down which applications are in the split tunnel list so future you can read it.

The afternoon I lost to my own machine

I once debugged a line for most of an afternoon that was behaving perfectly. I was testing from a machine I had used the previous week for something unrelated, and I had left a tunnel client running on it. My requests were reaching the gateway from an address that did not match anything in my head, my own connection records looked wrong to me, and I went hunting through the proxy software for a bug that was never there.

The thing that eventually caught it was the same check I now give every customer: ask one page what address it sees, with the proxy switched off. It came back as a country I had not been in. I had spent four hours on my own software because I had not spent thirty seconds on my own machine.

If you want Singapore carrier lines to point all of this at, real SIMs with sticky ports and dns routed through the tunnel, everything is at Singapore Mobile Proxy.

Get new guides and videos first — join the Telegram channel.