You remove proxychains from a command, launch it again, and still see the wrapper's startup message. Check the launch environment before looking for an application setting.

On Linux, LD_PRELOAD asks the dynamic linker to load specified shared objects ahead of ordinary libraries. Proxy wrappers can use that mechanism to intercept supported networking calls. If someone exported the variable in a shell, later child programs can inherit it even when their command lines contain no wrapper prefix.

A read-only first check in that shell is:

printf '%s\n' "$LD_PRELOAD"

Look for a proxy wrapper library, but preserve the possibility that the variable lists other deliberately loaded libraries too. Removing every entry blindly can disrupt a different tool.

Change the launcher, then relaunch the program

Clear the accidental proxy preload from the environment that launches the affected program. If a startup file or launcher exports it, correct that source as well. For Bash launches, follow the startup-file order. A fresh child of a clean shell is a different case from a child of an old terminal or IDE that still holds the variable.

Unsetting an environment variable does not unload a library from a process that already started with it. A running application may therefore keep the wrapper until restarted through the corrected launch path.

If the variable is absent, inspect other configured preload sources such as /etc/ld.so.preload and the actual launcher. The mechanism has limits: static executables, direct system calls and secure-execution restrictions can behave differently. With sudo, the wrapper order matters. An inherited preload explains unexpected interception; it is not evidence that every kind of network traffic uses the proxy.

Tënë sô zo