Personal website of Aurélien Vermylen

Some strange problems when configuring Chrome on Chrome OS to use a SOCKS5 proxy

Some technical post regarding the setup of a SOCKS5 ssh proxy on a chromebook that got me losing a lot of time…


I’m currently working on a chromebook and trying to keep all computation power and specific software off the chromebook and on a remote server. Long story short, but in that process I installed re6st, which is a kind of ipv6 network on top of the more usual ipv4 networks users are usually connected-to by their ISP. The thing seems to basically open some network tunnels and route all the traffic through that. This is nice, as behind even a quite restricted NAT-router, you can set up a static ipv6 IP.


The problem is that you of course need to be part of some network with some central routing node, so you can’t just set up the end-node version on your server and hope that everything works. So Nexedi, the firm that developed the thing and runs a network with it, offers a free trial on their “GrandeNet”. However, when you subscribe to that, you don’t get optimised routing from outside the network, and all your connections get routed through some central node in China…

Set up a proxy

This is why I needed to proxy my internet traffic from my chromebook through some Nexedi server, which is on the GrandeNet and optimised, so does have fast access to my server. The easiest way to set up a proxy like that on a chromebook (without going through enormous pains like installing crouton, is to use ssh -D since ssh is available on chromeos.

So there I go, I ssh -D towards my Nexedi server (just a small, cheap virtual one), and then came the pain… Now there was a SOCKS5 service listening on localhost:<myportnumber> all right, which would proxy to my server and all what was needed now is to get chrome to use that proxy.

You have two ways of configuring proxies in chromeos: - Manually: which offers you HTTP, HTTPS, FTP and SOCKS (but sadly, SOCKS4, which doesn’t support ipv6…) - With a .pac script.

So here I go, I’m on a chromebook, so the only write folder I have is /home/chromeos/user/Downloads, so I create a file proxy.pac there with:

function FindProxyForURL(url, host)
  return "SOCKS5<myportnumber>";

I put the link to that file: file:///home/chromeos/user/Downloads/proxy.pac in the configuration screen of the wifi connection, I go to, and am still in Brussels instead of Paris (where the Nexedi server is)…

So it doesn’t work.

Debugging, debugging, debugging, debugging…

Luckily, chrome’s tools are quite advanced, and I go to chrome://net-internals/#proxy, where I see:

Effective proxy settings

Use DIRECT connections.

Original proxy settings

PAC script: file:///home/chromeos/user/Downloads/proxy.pac

So for some reason, chrome overrides my .pac script…

In the Events menu (chrome://net-internals/#events), I see an error: ERR_ACCESS_DENIED on the GET request to the pac script…

So I check in chrome itself the url file:///home/chromeos/user/Downloads/proxy.pac, and there’s no problem there, it correctly returns my .pac script. MADNESS!!

So after two hours or so of googling, I start realizing that the process that tries to access the .pac script might not have any rights on my Downloads folder (although chrome has, because I see the file when I navigate to the URL)! That is VERY counterintuitive, but that seemed to be the case… And indeed, when I just put the .pac script on some of my public servers and pointed to that, everything worked…