I can run curl in the n8n container to connect to google, but I cannot access it correctly in the ui node
this is my error message
this docker logs
this exec n8n containerd sh curl
Not sure if any of this will be the answer, but here are some observations that might help you isolate where things are going wrong.
Based on the port you have configured for your proxy server (10808, part of which is 1080), I’m guessing that might be a SOCKS proxy. It could be that when n8n tries to use this proxy as an http/s proxy, it isn’t working because the proxy type is mismatched.
Internally, n8n uses Axios for most outbound connections. The Axios module, not n8n itself, is what recognizes and uses the http_proxy and/or https_proxy environment variables (see comments in the example Axios config re: environment variables). When you run curl it is running in the OS/Container that is also running n8n, so the environment variables curl recognizes, and how it uses them, will be different (not an apples-to-apples comparison) than what’s happening within the n8n node.js/Axios process.
There are 3 nested network environments interacting (Windows 11, Ubuntu VM, and Docker). The resolution of IP addresses (DNS) and routing of traffic between them may be aggravating the end result.
One thing you could try, to isolate whether n8n will work with your env-var configuration, is to temporarily run a different (http) proxy (side-by-side with n8n, within the same Docker environment) and point the n8n env vars to it instead. This will eliminate the “unknowns” related to networking in the Ubuntu VM or Windows, and eliminate the possibility that v2rayN is the wrong proxy type. If you get that working, add the other elements back in one-by-one until something breaks.
What I did to make http and https proxies work, is I looked at the docker-entrypoint.sh, there is an interesting part towards the end where it says that If the directory /opt/custom-certificates exists, it will run:
echo "Trusting custom certificates from /opt/custom-certificates."
export NODE_OPTIONS="--use-openssl-ca $NODE_OPTIONS"
export SSL_CERT_DIR=/opt/custom-certificates
c_rehash /opt/custom-certificates
Then I set http_proxy, https_proxy and no_proxy envs pointing to the proxy - I use mitmproxy for my proxy, so I mounted the mitmproxy certificate to that folder and everything just started to work.
You can also see this mentioned (somewhat) in here - for a different reason, but it works nonetheless - all web requests from n8n now go through the proxy.
I have been troubleshooting for a long time using this cascading proxy method, but I can’t pinpoint the problem. So I decided to use a more violent solution, which is to install the v2ray proxy directly on Ubuntu, turn on the tun and global proxy network access modes, so that all browser request traffic can be accessed through v2ray. However, through this operation method, I can think of a more precise problem. The command and browser operation methods in the operating system are not the same. The access mode may be caused by this method. The proxy cannot be used correctly, but I don’t know how to debug it.
I think this proxy access error is not caused by the proxy settings of Docker, but more likely by the different network usage methods of the browser and the command line interface.
The simplest solution is to install v2ray proxy on the Ubuntu virtual machine and set up tun and global proxy and then run the n8n container directly
this my run code
this my v2ray
1 Like
But this leads to another problem. When I deploy n8n using a server system without GUI, I set up httpsproxy and httpproxy and the proxy failure problem occurs again. This problem may be too deep in the network level. I don’t know how to solve it.