👍
I have the same problem with google-chrome

try opening a shell, enter:

export LD_PRELOAD=/path/to/libproxychains4.so
chromium-browser --user-data-dir=/tmp/chromium

Same problem. Ubuntu 15.04 x64

anyone tried what i said above ?

Yes, i tried. The same result.

we need to figure out what chromium does that is incompatible with proxychains.
a start would be if someone that has it installed can paste the output of "strace -f chromium" (while connecting to a single random site and then closing the browser - dont do it with several tabs open as that will heavily bloat strace's output)

Here's what chromium does with proxychains:
http://pastebin.com/beDyp3P5
Normal chromium is too big to pastebin

thanks for the strace output.
now we know that chromium uses a perl wrapper that searches for plugins and then starts the real binary:

execve("/usr/lib/chromium/chromium", ["/usr/lib/chromium/chromium", "--ppapi-flash-path=/usr/lib/Pepp"..., "--ppapi-flash-version=20.0.0.195"], [/* 43 vars */]) = 0

additionally we see that pulseaudio is used which does its own (eventually incompatible?) dlsym() tricks

open("/usr/lib/pulseaudio/libjson-c.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/libjson-c.so.2", O_RDONLY|O_CLOEXEC) = 11

if the problem is due to one of the above findings, it may help to try to

1. start chromium directly without the perl wrapper
2. disable pulseaudio (or recompile chromium without pulseaudio support, if feasible)

I think it might be a problem with proxychains, as anything chromium based (including opera, chrome, vivaldi, chromium, &tc) gives a

nanosleep({0, 2000001}, NULL) = 0

after a while with strace

to find out for sure we need a voluntary who can test chromium with

• pulseaudio globally deactivated
• chromium launched directly without perl wrapper

and someone who can build chromium without support for pulseaudio,

and/or somebody who knows/reads chromium code to find out if its doing something weird
like doing the connect syscall directly or using raw sockets etc

i fixed a related problem a few days ago. you may wanna check out latest git and report if the problem still exists.

Tested with Chrome, but still doesn't work.

+1

Unsolved still.

well, then i suppose someone should attach his debugger and find out why.
i won't be that someone because chromium sources are > 2GB and compiling it from source takes hours.

@sashage Which tool do you use for running a proxy locally?

I use Shadowsocks (https://github.com/shadowsocks/shadowsocks-libev)

it's unlikely we'll ever get the chromium sandbox compatible with proxychains.
however there's a way to get proxychains working with chromium and that is running proxychains4 on a HTTP or SOCKS proxy like tinyproxy or microsocks (see comment #45 (comment)) and then putting the http server adress into chromium's network config or using a SOCKS server via the trick mentioned in #45 (comment). in such scenario proxychains can route the connections of the proxy server software over your chain of proxies.

Original proxychains v3/v4.3 works with chrome based apps... i think it's probably because of this feature (fixes programs that do dns-lookups in child processes like irssi. to achieve this, support for compilation without pthreads was sacrified.) added in 4.3... need to debug further to see what's going on

This feature should be optional anyway

EDIT: indeed i was right this is what get chromium in trouble 25afe98

EDIT II: use v4.3 https://github.com/rofl0r/proxychains-ng/tree/v4.3 if needed to make it work with chromium

EDIT III: temporary solution v4.3 with CVE-2015-3887 patch https://github.com/Intika-Linux-Network/Proxychains-NG

EDIT : indeed i was right this is what get chromium in trouble 25afe98

interesting find. thanks for digging.

Original proxychains works with chrome based apps https://github.com/haad/proxychains

that's not original at all. please do not link to that abomination any more. instead link to the v4.3 tag in this repo.

This feature should be optional anyway

that's a bold statement for someone who never contributed code to this project, even though i agree that it would be nice to have a switch to toggle it. but it will be a lot of work to do it.
in all fairness it's not proxychains-ng's fault that chrome goes out of its way to make it hard to hook to its processes by using all kinds of sandboxing features.

that's why i generally suggest that people use proxychains-ng to proxify a local socks or http proxy like microsocks or tinyproxy, and put that local proxy's ip into the browser's proxy settings, which is totally reliable.

that's a bold statement for someone who never contributed code to this project, even though i agree that it would be nice to have a switch to toggle it. but it will be a lot of work to do it.

Indeed it's kind a lot i trayed yesterday to make it optional, but i abandoned after 1h... i will see what i can do if i have the time.

that's why i generally suggest that people use proxychains-ng to proxify a local socks or http proxy like microsocks or tinyproxy, and put that local proxy's ip into the browser's proxy settings, which is totally reliable

Yes agree chrome and similar have a proxy setting, in this case proxychains-ng would be useful to make sure there is no leak.

do not link to that abomination

Proxychains is melted with all the dev that worked on the project i thought @haad was netcreature-from-sourceforge the original developer i did not dig deeper to check who is who

Note for newcomer: netcreature is the original developer (v3) @rofl0r took over providing v4.x (ng version) and @haad contributed to the code...

It's funny to compare those 2 files https://github.com/rofl0r/proxychains-ng/blob/master/AUTHORS and https://github.com/haad/proxychains/blob/master/AUTHORS

On its repo:

@haad: localnet, bugfixes, macos x support, bsd support, packaging

And here

@haad: collecting patches from px forum and putting it into a repo

loooool

Indeed it's kind a lot i trayed yesterday to make it optional, but i abandoned after 1h... i will see what i can do if i have the time.

a "traditional mode" basically would need to use the old proxyresolv script (which depends on dig for TCP-based DNS resolution but it could be changed to use eitherdig or drill - the latter is a modern replacement which has much less cruft), and would be incapable of resolving .onion hosts when used with tor (and would be much slower).

a "traditional mode" basically would need to use the old proxyresolv script (which depends on dig for TCP-based DNS resolution

i've implemented this now: 2ab6319

additionally i've implemented another new remote DNS mode which should fix issues with crapware like chromium forever: 7fe8139

please test!

a "traditional mode" basically would need to use the old proxyresolv script (which depends on dig for TCP-based DNS resolution

i've implemented this now: 2ab6319

additionally i've implemented another new remote DNS mode which should fix issues with crapware like chromium forever: 7fe8139

please test!

Confirmed this method works for discord (which is based on React and the Electron framework).

This also works for Google Chrome

My setup

• OS: Ubuntu Desktop 20.04.1 with 5.11.0-27-generic
• Discord: 0.0.15 downloaded from the website
• Chrome: 92.0.4515.159 (Official Build)
• proxychains4
  • commit: 1015efa (latest commit at the time of writing)
  • compilation config: default (only ./configure)

Edit: sample systemd service file for the dns daemon

[Unit]
Description=DNS daemon for proxychains4
After=network-online.target nss-lookup.target
Wants=network-online.target

[Service]
User=nobody
CapabilityBoundingSet=CAP_NET_BINDING_SERVICE
AmbientCapabilities=CAP_NET_BINDING_SERVICE
NoNewPrivileges=true
ExecStart=/path/to/proxychains4-daemon
Restart=on-failure

[Install]
WantedBy=multi-user.target

Hi, I meet similar errors too. When I try to use proxychains4 for chrome on WSL2 in Win11 like this:

pc google-chrome

where pc means proxychains4 -q -f ~/proxychains4.conf, I got this error:

[1207/152542.626460:ERROR:file_io_posix.cc(144)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or directory (2)
[1207/152542.626506:ERROR:file_io_posix.cc(144)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or directory (2)
[1]    1854 trace trap  proxychains4 -q -f ~/proxychains4.conf google-chrome

Hi, I meet similar errors too.

s/meet/encounter/. you can meet a person, but not a thing. it seems all chinese dicts get that wrong.

When I try to use proxychains4 for chrome on WSL2 in Win11 like this:

1. use proxy_dns_daemon mode
2. WSL isn't offcially supported, if it works it's by chance.

since @nickchen120235 confirmed that proxy_dns_daemon fixes the issue, i'm taking the opportunity to close this.

@arpitjindal97 Your solution will not chain proxies, unless you use a proxy with an upstream proxy, for example with mitmproxy.
Anyway, Chromium works with proxychains using the proxy_dns_daemon option in the configuration file (we need to use proxychains4, not proxychains3 and start proxychains4-daemon).
If you have both proxychains4 and proxychains3 installed, you need to use the correct config file, for example:
proxychains -f /etc/proxychains4.conf chromium