The question is quite simple , I have only basic Idea of RPC but none of IPC.

AFAIK, if I connect to ethereum node via ipc then the my geth should be running on same machine. and If I connect via RPC then my geth could run on any remote machine.Is there anything else I should know.

Also if I enable RPC over geth, does this means any one can connect to my node or there is any way I can restrict some specific IP's that can connect to my node. Is --rpc addr can help in some way?

  • I did some linings and get ether in my local ethereum wallet. But if I check online my account balance is 0,00. Why? Did somone know that? – Igor Nemo Jan 18 at 13:43
up vote 31 down vote accepted

IPC or Inter-process Communications generally works on your local computers. In the Ethereum space, IPC normally involves geth creating a IPC pipe (which is represented by the file $HOME/.ethereum/geth.ipc) on your computer's local filesystem.

Other processes on the same computer can then use the IPC file to create bi-directional communications with geth.

RPC or Remote Procedure Calls generally works across different computers. In the Ethereum space, RPC normally refers to the RPC endpoint localhost:8545 or or

If you use localhost:8545 or for your RPC endpoint, other process ONLY on the local computer can communicate via this RPC endpoint, as localhost and is only accessible from the local computer.

If you use a non-local IP address like, any other computer on your network can access this RPC endpoint.

If your internet connection forwards traffic from your internet IP address to your computer's IP address then any computer from the internet can access your RPC endpoint by connecting to {your internet IP address}:8545.

As documented in How to reduce the chances of your Ethereum wallet getting hacked?, the user Patrick forwarded his internet IP address traffic for port 8545 to his computer's non-local IP address (e.g. instead of When Patrick unlocked his account to transfer some funds, an attacker from the internet was able to execute geth JSON-RPC commands to steal Patrick's ethers.

So if you do enable RPC over geth, enable it using --rpcaddr if you only want it accessible from your local computer. If you enable it using your network IP address (e.g., all computers from your network will be able to access geth's RPC endpoint. If you then have your internet modem forwarding traffic for port 8545 from the internet to your computer's, anyone from the internet will be able to access geth's RPC endpoint.

So, don't specify the --rpcaddr parameter and it will default to which is only accessible from your local computer, and if you want to access RPC from other computers on your local network, make sure that your internet connection does not forward internet traffic to your geth machine.

Responding to additional question

The best way to check if your local machine is listening for communications outside your local computer space is to perform the following:

Iota:backup user$ netstat -an  | grep LISTEN
tcp4       0      0         *.*                    LISTEN     
tcp46      0      0  *.30303                *.*                    LISTEN     
tcp4       0      0         *.*                    LISTEN     
tcp4       0      0         *.*                    LISTEN     

In the above table, you can see that the ports 8545 (geth), 8181 (my local web server) and 6379 (Redis NoSQL database) are only accessible from my local machine. Port 30303 however is accessible from outside my local machine. As my ADSL router forwards traffic from port 30303 to my local computer, the world can access my local computer via port 30303.

IPC and RPC are not necessarily the same in terms of accessibility. If you have an IPC connection accessible, programs on your local computer may have access to the program listening on the IPC file. But your web browser will not have access to this file as web browsers generally do not connect via IPC.

If you have a RPC connection accessible from your local machine, your web browser running locally on your machine will have access to your RPC connection. The parameter --rpccorsdomain is meant to restrict access from your web browser from domains other than what you specified, but any (malicious) program running on your computer can just ignore this request (it is just a polite request and not a restriction) and access your RPC port anyway.

  • 1
    Thank You so much the perfect answer. I have a doubt, if I specify the --rpcaddr localhost , then practically is there no difference between IPC and RPC in this case? bcoz in both the cases only processes on my local machine can communicate to geth, so ipc and rpc seems to be same in this case. – Prashant Prabhakar Singh Dec 14 '16 at 9:40
  • And also If I use --rpcaddr , then exposing personal over rpc will also not be vulnerable because only the process on my machine can connect to geth. Or is there any other scenario that I overlooked? – Prashant Prabhakar Singh Dec 14 '16 at 9:56
  • 2
    See update in answer above. If you use --rpcaddr and your computer has been compromised, any program running on your computer can access to this endpoint. But this is the same over IPC. So if your computer has been compromised, IPC will give the same access as RPC and both will be vulnerable. Security is unfortunately difficult. – The Officious BokkyPooBah Dec 14 '16 at 10:07
  • Is geth attach some form of IPC? – Omkar Khair Jun 7 '17 at 9:59
  • It seems geth.ipc is not a permanent file but a socket and does not exist as a file. At least not on my macOS file system. I have looked everywhere /T/geth.ipc, /chaindata/geth.ipc etc including invisible files and it does not exist. I am currently running geth. Can anyone confirm that this file actually does not reside on the filesystem? – tymac Apr 13 at 3:54

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.