<p>If you make only outbound connections it won't matter what ports you use. Your client will be able to fully participate in the network without any issues.</p>

CC BY-SA 3.0
2011-10-07T22:31:35.690Z
So, if my app can start a connection with another client stating that my address has port :80, it will receive response on port :80?
ThePiachu
CC BY-SA 3.0
2011-10-07T22:33:47.170Z
When you connect to a client, you will receive responses on the connection you just made to that client. The Bitcoin network uses persistent TCP connections that remain active so long as both nodes continue running.
David Schwartz
CC BY-SA 3.0
2011-10-07T22:34:47.260Z
Btw, I think you used an unnecessary "and". Can't edit your post, since I would need to change at least 6 characters ;).
ThePiachu
CC BY-SA 3.0
2011-10-07T22:36:12.003Z
Thanks. I changed the structure of that sentence after writing it and didn't complete the change.
David Schwartz
CC BY-SA 3.0
2011-10-07T22:27:24.733Z
2011-10-07T22:35:51.893Z
2011-10-07T22:35:51.893Z
David Schwartz
<p>Nodes on the network which are not running on the default ports (8333 for the main network, 18333 for testnet) will be avoided by the reference client in order to not cause disruption to other services. Otherwise should somebody advertise a fake node running on another applications port, other nodes in the network could cause a denial of service attack as they attempt to connect to it fruitlessly. </p>

<p>A code snippet from the Bitcoin Core client, showing that nodes will ignore non-standard ports unless they are very desperate to find somebody they can connect to:</p>

<pre><code>// do not allow non-default ports, unless after 50 invalid addresses selected already
if (addr.GetPort() != Params().GetDefaultPort() &amp;&amp; nTries &lt; 50)
continue;
</code></pre>

<p>If you want to actively support the network with incoming connections you should not be changing the "port" setting of the bitcoin daemon if at all possible. </p>

CC BY-SA 3.0
2014-11-18T12:14:35.023Z
It's trivial to block Bitcoin traffic anyway, so it's not a huge limit in any real sense. Other people can make networking layers that attempt to solve this, rather than being part of the core daemon. If you have multiple nodes behind one external IP, only have one listen and all the others connect to it.
foley
CC BY-SA 3.0
2014-10-28T05:41:24.567Z
Never knew this. But that's quite a limitation. Doesn't that make blocking Bitcoin traffic *much* easier? (if governments or so would want that) And how do I go about running multiple full nodes within one LAN, behind the same IP? (e.g. at my office building)
Maǳi Koǌo
CC BY-SA 3.0
2014-10-28T05:33:57.287Z
2014-10-28T05:33:57.287Z
foley
<p>Beware that -addnode ignores -port setting</p>

<p>For example, both node1 and node2 have a -port=14444</p>

<p>node1> bitcoin-cli addnode node2 add</p>

<p>2018-08-11 02:07:04 connect() to node2:18444 failed after select(): Connection refused (111)</p>

<p>The fix is to include the port in the host name
node1> bitcoin-cli addnode node2:14444 add</p>

CC BY-SA 4.0
2018-08-11T02:49:13.653Z
2018-08-13T22:46:14.267Z
2018-08-13T22:46:14.267Z
Systemsplanet
<p>I'm writing a Bitcoin web app that is to be deployed on an external server over which I have no control. I probably won't have access to standard Bitcoin port (8333). Will this cause a problem when connecting to standard Bitcoin clients, or can they handle communicating with a non-standard port number? Are there any Bitcoin-related applications that also use other ports to communicate (like a pool or the like)?</p>

CC BY-SA 3.0
2011-10-07T21:44:19.000Z
In what way(s) does the web app have to interact with the Bitcoin network? Will the Bitcoin client be running on the machine running the web app?
David Schwartz
CC BY-SA 3.0
2011-10-07T22:23:07.567Z
I intend to write my own Bitcoin client for the web app, so I hope to be able to fully interact with the Bitcoin network. Alternatively, I might want to run just a pool in the web app. So, there is no problem with client customization as long as the network can also handle that.
ThePiachu
<bitcoin-core><protocol><p2p><port>
Bitcoin communication with non-standard ports
ThePiachu
# Bitcoin communication with non-standard ports

(Asked by: username_0 on 2011-10-07)

I'm writing a Bitcoin web app that is to be deployed on an external server over which I have no control. I probably won't have access to standard Bitcoin port (8333). Will this cause a problem when connecting to standard Bitcoin clients, or can they handle communicating with a non-standard port number? Are there any Bitcoin-related applications that also use other ports to communicate (like a pool or the like)?

**Tags:** bitcoin-core, protocol, p2p, port

> **Comments:**
> **username_1**: In what way(s) does the web app have to interact with the Bitcoin network? Will the Bitcoin client be running on the machine running the web app?  
> **username_0**: I intend to write my own Bitcoin client for the web app, so I hope to be able to fully interact with the Bitcoin network. Alternatively, I might want to run just a pool in the web app. So, there is no problem with client customization as long as the network can also handle that.  

---

## 3 answers

### Answer by username_1 on 2011-10-07. Score: 3 | Accepted answer

If you make only outbound connections it won't matter what ports you use. Your client will be able to fully participate in the network without any issues.

> **Comments:**
> **username_0**: So, if my app can start a connection with another client stating that my address has port :80, it will receive response on port :80?  
> **username_1**: When you connect to a client, you will receive responses on the connection you just made to that client. The Bitcoin network uses persistent TCP connections that remain active so long as both nodes continue running.  
> **username_0**: Btw, I think you used an unnecessary "and". Can't edit your post, since I would need to change at least 6 characters ;).  
> **username_1**: Thanks. I changed the structure of that sentence after writing it and didn't complete the change.  

---

### Answer by username_2 on 2014-10-28. Score: 2

Nodes on the network which are not running on the default ports (8333 for the main network, 18333 for testnet) will be avoided by the reference client in order to not cause disruption to other services. Otherwise should somebody advertise a fake node running on another applications port, other nodes in the network could cause a denial of service attack as they attempt to connect to it fruitlessly.

A code snippet from the Bitcoin Core client, showing that nodes will ignore non-standard ports unless they are very desperate to find somebody they can connect to:

```
// do not allow non-default ports, unless after 50 invalid addresses selected already
if (addr.GetPort() != Params().GetDefaultPort() && nTries < 50)
continue;

```

If you want to actively support the network with incoming connections you should not be changing the "port" setting of the bitcoin daemon if at all possible.

> **Comments:**
> **username_3**: Never knew this. But that's quite a limitation. Doesn't that make blocking Bitcoin traffic *much* easier? (if governments or so would want that) And how do I go about running multiple full nodes within one LAN, behind the same IP? (e.g. at my office building)  
> **username_2**: It's trivial to block Bitcoin traffic anyway, so it's not a huge limit in any real sense. Other people can make networking layers that attempt to solve this, rather than being part of the core daemon. If you have multiple nodes behind one external IP, only have one listen and all the others connect to it.  

---

### Answer by username_4 on 2018-08-11. Score: 0

Beware that -addnode ignores -port setting

For example, both node1 and node2 have a -port=14444

node1> bitcoin-cli addnode node2 add

2018-08-11 02:07:04 connect() to node2:18444 failed after select(): Connection refused (111)

The fix is to include the port in the host name
node1> bitcoin-cli addnode node2:14444 add


---

