Connection refused to local node on port 8546.
ProjectID 32e7c04c-c58a-41a6-9e8c-320a473294f7
The machine my services are running on is trying to connect to a local node on port 8546, used for WebSocket connections to Ethereum nodes.
Six of my servers with different providers crashed at the same time while their redundant servers are ok:
Could someone please help me?
12 Replies
Project ID:
32e7c04c-c58a-41a6-9e8c-320a473294f7why is your app trying to connect to itself?
Why 60% of my servers start wanting to connect to themselves, I don't know.
How do I know this?
that would be a code issue
It has been running for two years, 40% of the other servers are still working and the local setup is perfect but with the websocket if a connection is not persistent it becomes a problem.
i dont really know what to tell you here sorry, this isnt an issue with railway, please debug your code
Hey there @Yannick - I am checking to see if it's an issue with our services.
@Yannick did you check https://stackoverflow.com/a/10646218
Stack Overflow
ECONNREFUSED error with node.js that does not occur in other clients
I'm making an http request with the node.js client, and I get an ECONNREFUSED error. When I make what appears to be the same request with my browser or curl(1), it works just fine
Here's the node
The fact is the code works on Heroku and on other slot on Railway. So that's quite weird
@yanina-amatore @Angelo check https://stackoverflow.com/questions/72390154/econnrefused-when-making-a-request-to-localhost-using-fetch-in-node-js
Stack Overflow
ECONNREFUSED when making a request to localhost using fetch in Node.js
I'm getting some strange behaviour in Node when making a request to locally running server.
I have a local server listening on port 4000. When using node-fetch (or any other Node fetch implementati...
We have this message "Looks like your app is listening on 127.0.0.1. You may need to listen on 0.0.0.0 instead."
What I understood it might there is an issue with ipv4/ip 127.0.0.1 vs 0.0.0.0 / geth node through ethersJs
It's not easy to understand the issue. Maybe it could be fix from Railway I don't know maybe change the
/etc/hosts config or in our side to force the ws to listen 0.0.0.0 (not easy to do),
@Yannick try to change :
to
or better "0.0.0.0" as global var HOST set "0.0.0.0" on Railway and "127.0.0.1" on other providers
Ok it does not working.
We tried to change the start with HOST:0.0.0.0 npm run start
It does not working as well@Brody @Angelo The reproduced error found that the container did not communicate with the database as if the environment variables were not read.
I actually have a loop in the code which inserts into the database the events it receives at regular intervals.
Building an image launched with Nixpacks (in a local setup) for my monitor works if all the variables are known. An error in the environment variables of the external postgres v15 database causes the same error as in the Railway logs.
The database identifiers are the same as the running services and the database metrics are ok.
Where are you in your investigation?
I placed the environment variables of my service which did not work one of those which worked and it worked.
I placed the environment variables of my working service in one of the non-working ones and it didn't work.
My last manipulation was to deploy four other services in the project as I usually do and the applications respond well.
Why do my other six services remain blocked while when I carry out the same deployments in the same project it succeeds?