👍
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.

with chromium/inox works

but its slow as hell

use the below command:

chromium --proxy-server="socks5://127.0.0.1:9050"

I can't find a solution to solve the problem. And I wonder why the command "proxychains google-chrome" can't work.
But I find a way to make it work.

proxychains bash
google-chrome

Linux/Debian sid amd64.

Chromium based tested (x64):

• Google Chrome Stable/Beta/Canary (I don't use Chromium).
• Vivaldi Snapshot & Stable.
• Opera Stable.
• Yandex Beta.

Doing proxychains4 google-chrome|opera|vivaldi|yandex-browser (Chromium based) just work here. I don't need to do any tricks like LD_PRELOAD or weird need BASH mentioned above.
I'm not sure why.

What's on me;

• I build proxychains-ng from git pull. No sources changed. Except the address & port in main config after.
• PulseAudio in used.
• I point the app directly to where app was installed. EX: /opt/google/chrome/google-chrome.
  I make own (stupid) DASH wrapper script for this.
• The only Chromium flag I use is --disk-cache-dir=[where's the folder]
• I use SSH tunnel through socks5 not TOR.
• My Debian system started from its net-install iso. Read: A mess up distro.

Only when using rofi, Google Chrome sometime stuck on its startup.
On use, entire (any) browsers sometime hang for awhile, no errors.
When it's (most of time) working, rendering/fetching speed, just normal.

Edited: typos

Have a chromium crash

command line output:

  user@debian:~$ proxychains4 /usr/bin/chromium
[proxychains] config file found: /etc/proxychains.conf
[proxychains] preloading /usr/lib/libproxychains4.so
[proxychains] DLL init: proxychains-ng 4.12-git-2-g46647be
[proxychains] DLL init: proxychains-ng 4.12-git-2-g46647be
[proxychains] DLL init: proxychains-ng 4.12-git-2-g46647be
[proxychains] DLL init: proxychains-ng 4.12-git-2-g46647be
[proxychains] DLL init: proxychains-ng 4.12-git-2-g46647be
[proxychains] DLL init: proxychains-ng 4.12-git-2-g46647be
[1:1:1029/162914.121982:FATAL:sandbox_linux.cc(180)] Check failed: sandbox::Credentials::MoveToNewUserNS(). 
#0 0x585908e8bfbe <unknown>
#1 0x585908ea061b <unknown>
#2 0x5859076be4bd <unknown>
#3 0x58590829b2d6 <unknown>
#4 0x585908aece36 <unknown>
#5 0x585908aee123 <unknown>
#6 0x585908aecb30 <unknown>
#7 0x5859075f4910 ChromeMain
#8 0x7fba8f641b45 __libc_start_main
#9 0x5859075f4789 <unknown>

Received signal 6
#0 0x585908e8baab <unknown>
#1 0x7fba96692890 <unknown>
#2 0x7fba8f655067 gsignal
#3 0x7fba8f656448 abort
#4 0x585908e8aa22 <unknown>
#5 0x585908ea0940 <unknown>
#6 0x5859076be4bd <unknown>
#7 0x58590829b2d6 <unknown>
#8 0x585908aece36 <unknown>
#9 0x585908aee123 <unknown>
#10 0x585908aecb30 <unknown>
#11 0x5859075f4910 ChromeMain
#12 0x7fba8f641b45 __libc_start_main
#13 0x5859075f4789 <unknown>
  r8: ffff97f659b0e2d8  r9: ffff97f659b0e2c8 r10: 0000000000000008 r11: 0000000000000202
 r12: 000017f50e2dfa80 r13: 000017f50e34d240 r14: 00007ffeb47c2d88 r15: 00007ffeb47c2d78
  di: 0000000000000001  si: 0000000000000001  bp: 000017f50e2e9000  bx: 0000000000000000
  dx: 0000000000000006  ax: 0000000000000000  cx: 00007fba8f655067  sp: 00007ffeb47c22a8
  ip: 00007fba8f655067 efl: 0000000000000202 cgf: 002b000000000033 erf: 0000000000000000
 trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]
[1999:1999:1029/162914.126396:FATAL:zygote_host_impl_linux.cc(196)] Check failed: ReceiveFixedMessage(fds[0], kZygoteHelloMessage, sizeof(kZygoteHelloMessage), &real_pid). 
#0 0x5556f6cc2fbe <unknown>
#1 0x5556f6cd761b <unknown>
#2 0x5556f64b2605 <unknown>
#3 0x5556f64b165e <unknown>
#4 0x5556f64b1c4e <unknown>
#5 0x5556f61437ec <unknown>
#6 0x5556f614c54a <unknown>
#7 0x5556f6142e7c <unknown>
#8 0x5556f6925123 <unknown>
#9 0x5556f6923b30 <unknown>
#10 0x5556f542b910 ChromeMain
#11 0x7e5e5b115b45 __libc_start_main
#12 0x5556f542b789 <unknown>

Aborted
user@debian:~$ 

Google suggests it's a sandboxing thing... but I don't wanna disable sandbox. Any hope that proxychains-ng will be made work with chromium's sandbox ?

3 years passed, any joy?

a bit late, but maybe this helps for this particular problem:
I use a workaround for chrome, which is technically not proxychains, but accomplishing the same effect:

I created the following script, which I use to proxy all traffic in chrome:

#!/bin/bash
function _start-with-proxy() {
	export SOCKS_SERVER=127.0.0.1:1080
        export SOCKS_VERSION=5
        chromium %U --user-data-dir="/home/[USER]/.chromium profiles/[PROFILEDIR]"
}
_start-with-proxy

I don't use flash, so I don't know if flash may bypass the proxy. DNS requests seem to get routed through the proxy though.

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

i'd recommend my own creation microsocks or tinyproxy (HTTP proxy, which can even forward requests to other SOCKS/HTTP proxies)

@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.