Diagnose Proxychains LD_PRELOAD Failures
Diagnose LD_PRELOAD failures and interception limits before assuming an application used the configured proxy.
The program starts, but the terminal says a proxychains library could not be preloaded. Treat that as a failed setup step, not a harmless warning to ignore while checking the exit IP.
Proxychains-ng relies on a loaded library to intercept relevant calls. If that library is missing, incompatible, or not loaded in the process, the program can run without the interception you expected.
Match the library to the process
Check the package's actual library location and the executable's architecture. An old answer hard-coding a 32-bit path is not a general repair for a 64-bit program. Do not add an unverified preload setting globally to every shell session.
The Linux dynamic-loader manual explains library search and secure-execution restrictions. Some process-launch circumstances deliberately ignore or restrict preload settings. A static executable also does not become dynamically interceptable merely because an environment variable is set.
The project README documents the wrapper's supported model. Applications with their own networking implementation, separate helper processes, or already running instances can introduce other limits even when the initial library loads.
A native proxy setting in the application can be a clearer option when available. It uses the application's intended network interface rather than assuming every connection can be captured externally.
For a failed wrapper setup, stop and identify what actually launched. A process exit status alone may show that the application ran, not that its traffic followed the proxy. Keep library loading, intercepted calls, and the observed outward connection as separate pieces of evidence.