<p>The rest interface uses the RPC options for setup. You can use the <code>-rpcbind</code> option to bind the interface to a different address and port, and set the <code>-rpcallowip</code>. Note that this will also affect the RPC interface.</p>

CC BY-SA 4.0
2022-08-29T05:04:10.297Z
Could you provide a working example? I used `rpcbind` according to the following docs, and still cannot get the address correct. https://github.com/bitcoin/bitcoin/blob/c5f0cbefa369b0e4d99a4f871e6334955d537c1f/src/init.cpp#L580-L582
Dr. Strangelove
CC BY-SA 4.0
2022-08-29T15:30:47.920Z
For example, if the my computer's LAN IP is 192.168.1.10, then to expose my the rpc interface on LAN, I would do `-rpcbind=192.168.1.10`.
Ava Chow
CC BY-SA 4.0
2022-08-29T17:50:02.350Z
Thanks! I have actually tried that, but that does not seem to be enough; e.g., above-linked docs read `"This option is ignored unless -rpcallowip is also passed."`. I have tried passing `-rpcallowip` arg as well, but that does not seem enough either.
Dr. Strangelove
CC BY-SA 4.0
2022-08-29T22:33:08.160Z
What value did you pass for `-rpcallowip`? In my example, you would do `-rpcallowip=192.168.1.1/24`.
Ava Chow
CC BY-SA 4.0
2022-08-29T22:51:55.427Z
Could you please elaborate? e.g., what is `24`?
Dr. Strangelove
CC BY-SA 4.0
2022-08-29T23:15:10.557Z
That is [CIDR Notation](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#CIDR_notation)
Ava Chow
CC BY-SA 4.0
2022-08-30T17:59:44.293Z
I was not able to connect from the second computer when `bitcoin-qt` was launched on the first computer with the following arguments. `--rpcbind=192.168.1.2/24` (the IP address of my computer on LAN) and `--rpcallowip `--192.168.1.1/24` (the IP of the default gateway and router in the LAN).
Dr. Strangelove
CC BY-SA 4.0
2022-08-30T18:09:32.237Z
I think `-rpcbind` should not have the the `/24`. You can also check the debug.log file to see if there are any warnings or errors related to the rpc interface there.
Ava Chow
CC BY-SA 4.0
2022-08-30T19:19:40.637Z
I don't see any binding to port `8332` in the logs, though I could see `Bound to 0.0.0.0:8333`.
Dr. Strangelove
CC BY-SA 4.0
2022-08-31T03:57:42.270Z
By default, the logs won't say anything about what addresses it is binding to for the RPC interface. You can enable that by starting with `-debug=http`. Are you checking `netstat` or are you checking reachability with another computer? For the latter, you may need to allow port 8332 in the windows firewall. I'm not sure why these options wouldn't work as I do observe them working for me.
Ava Chow
CC BY-SA 4.0
2022-08-31T19:25:39.213Z
I've added `-debug=http` but still cannot see entries for `8332`. I'm checking the connection with `nc -vz 192.168.1.2 8332` on the second computer which returns `Connection refused. I have also opened the port on my firewall.
Dr. Strangelove
CC BY-SA 4.0
2022-08-31T19:26:20.190Z
Could you please paste the full command your are using to start bitcoin-qt that works for you in this scenario?
Dr. Strangelove
CC BY-SA 4.0
2022-08-31T21:08:55.510Z
`./bitcoin-qt -debug=http -rpcbind=10.21.1.10 -rpcallowip=10.21.1.1/24 -server` is my command (my computer's IP is 10.21.1.10). There is a log line that says `[http] Allowing HTTP connections from: 127.0.0.0/8 ::1/128 10.21.1.0/24 127.0.0.1/32` and another with `[http] Binding RPC on address 10.21.1.10 port 8332`
Ava Chow
CC BY-SA 4.0
2022-09-01T00:37:40.323Z
Thanks for sharing the command you use. I executed the very same command (replacing my IP and gateway with yours), though still had the same issues are before. I do not have any of those entries in the log either. I'm using bitcoin-qt `v22`.
Dr. Strangelove
CC BY-SA 4.0
2022-09-01T01:48:24.517Z
when I use `-rpcbind=<IP> -rpcallowip=<IP>` I read in the logs  `option -rpcbind was ignored because -rpcallowip was not specified`, and when I swap their order to `-rpcallowip=<IP> -rpcbind=<IP>` logs read: `option -rpcallowip was specified without -rpcbind`. Does it ring any bells?!
Dr. Strangelove
CC BY-SA 4.0
2022-09-01T16:01:48.007Z
Log lines like that sound like the shell is improperly escaping/passing the arguments to the program. Instead of using command line arguments, you could try putting the arguments in the bitcoin.conf file with one argument per line without the leading `-`. For the boolean options (e.g. `-server` and `-rest`), you also need to append `=1` to those (e.g. `server=1`).
Ava Chow
CC BY-SA 4.0
2022-09-02T01:52:47.023Z
Thanks! I guess all the confusion was because of the shell not parsing the arguments correctly, since setting the values in `bitcoin.conf` worked as expected.
Dr. Strangelove
CC BY-SA 4.0
2022-08-29T04:29:13.190Z
2022-09-02T02:25:20.373Z
2022-09-02T02:25:20.373Z
Ava Chow
<p>I have bitcoin-qt running on a Windows machine in my network started with the following command and empty config file (hence, all default configurations).</p>
<pre><code>bitcoin-qt.exe -server=1 -rest=1
</code></pre>
<p>I can query the API endpoint of the node on the <code>8332</code> port; for instance:</p>
<pre><code>curl http://localhost:8332/rest/chaininfo.json
</code></pre>
<p>I want to access the same REST API endpoint from the second computer on the network. On the second computer, I can reach the <code>8333</code> endpoint, but not <code>8332</code>.</p>
<pre><code>$ nc -vz 196.168.1.2 8333
Connection to 192.168.1.2 port 8333 [tcp/*] succeeded!

$ nc -vz 196.168.1.2 8332
nc: connect to 192.168.1.2 port 8332 (tcp) failed: Connection refused 
</code></pre>
<p>On the first computer (the one that is running bitcoin-qt), it seems port <code>8333</code> can be reached with the computer's IP in the LAN while port <code>8332</code> is only reachble via <code>localhost</code>:</p>
<pre><code>$ netstat -aon | findstr 8333
  TCP    0.0.0.0:8333           0.0.0.0:0              LISTENING       117384
  TCP    192.168.1.2:1033     84.212.130.217:8333    ESTABLISHED     117384
  TCP    192.168.1.2:1034     50.39.164.136:8333     ESTABLISHED     117384
  TCP    192.168.1.2:1035     45.132.158.199:8333    ESTABLISHED     117384
  TCP    192.168.1.2:1045     95.84.137.91:8333      ESTABLISHED     117384
  TCP    192.168.1.2:1065     82.197.215.125:8333    ESTABLISHED     117384
  TCP    192.168.1.2:1076     209.237.133.54:8333    ESTABLISHED     117384
  TCP    192.168.1.2:1091     178.48.160.142:8333    ESTABLISHED     117384
  TCP    192.168.1.2:1093     95.110.133.223:8333    ESTABLISHED     117384
  TCP    192.168.1.2:1106     5.188.62.18:8333       ESTABLISHED     117384
  TCP    192.168.1.2:1112     108.248.87.92:8333     ESTABLISHED     117384
  TCP    [::]:8333              [::]:0                 LISTENING       117384


$ netstat -aon | findstr 8332
  TCP    127.0.0.1:8332         0.0.0.0:0              LISTENING       117384
  TCP    [::1]:8332             [::]:0                 LISTENING       117384
</code></pre>
<p>Mind <code>[::]</code> for port <code>8333</code> and <code>[::1]</code> for port <code>8332</code>.</p>
<p>I am wondering what changes need to be made in order to reach the <code>8332</code> port of the node from another computer in the network.</p>

<bitcoin-core><json-rpc><port>
Access REST endpoint of Bitcoin-qt from another computer on the local network
Dr. Strangelove
# Access REST endpoint of Bitcoin-qt from another computer on the local network

(Asked by: username_0 on 2022-08-28)

I have bitcoin-qt running on a Windows machine in my network started with the following command and empty config file (hence, all default configurations).

```
bitcoin-qt.exe -server=1 -rest=1

```

I can query the API endpoint of the node on the `8332` port; for instance:

```
curl http://localhost:8332/rest/chaininfo.json

```

I want to access the same REST API endpoint from the second computer on the network. On the second computer, I can reach the `8333` endpoint, but not `8332`.

```
$ nc -vz 196.168.1.2 8333
Connection to 192.168.1.2 port 8333 [tcp/*] succeeded!

$ nc -vz 196.168.1.2 8332
nc: connect to 192.168.1.2 port 8332 (tcp) failed: Connection refused 

```

On the first computer (the one that is running bitcoin-qt), it seems port `8333` can be reached with the computer's IP in the LAN while port `8332` is only reachble via `localhost`:

```
$ netstat -aon | findstr 8333
  TCP    0.0.0.0:8333           0.0.0.0:0              LISTENING       117384
  TCP    192.168.1.2:1033     84.212.130.217:8333    ESTABLISHED     117384
  TCP    192.168.1.2:1034     50.39.164.136:8333     ESTABLISHED     117384
  TCP    192.168.1.2:1035     45.132.158.199:8333    ESTABLISHED     117384
  TCP    192.168.1.2:1045     95.84.137.91:8333      ESTABLISHED     117384
  TCP    192.168.1.2:1065     82.197.215.125:8333    ESTABLISHED     117384
  TCP    192.168.1.2:1076     209.237.133.54:8333    ESTABLISHED     117384
  TCP    192.168.1.2:1091     178.48.160.142:8333    ESTABLISHED     117384
  TCP    192.168.1.2:1093     95.110.133.223:8333    ESTABLISHED     117384
  TCP    192.168.1.2:1106     5.188.62.18:8333       ESTABLISHED     117384
  TCP    192.168.1.2:1112     108.248.87.92:8333     ESTABLISHED     117384
  TCP    [::]:8333              [::]:0                 LISTENING       117384

$ netstat -aon | findstr 8332
  TCP    127.0.0.1:8332         0.0.0.0:0              LISTENING       117384
  TCP    [::1]:8332             [::]:0                 LISTENING       117384

```

Mind `[::]` for port `8333` and `[::1]` for port `8332`.

I am wondering what changes need to be made in order to reach the `8332` port of the node from another computer in the network.

**Tags:** bitcoin-core, json-rpc, port


---

## 1 answers

### Answer by username_1 on 2022-08-29. Score: 2 | Accepted answer

The rest interface uses the RPC options for setup. You can use the `-rpcbind` option to bind the interface to a different address and port, and set the `-rpcallowip`. Note that this will also affect the RPC interface.

> **Comments:**
> **username_0**: Could you provide a working example? I used `rpcbind` according to the following docs, and still cannot get the address correct. https://github.com/bitcoin/bitcoin/blob/c5f0cbefa369b0e4d99a4f871e6334955d537c1f/src/init.cpp#L580-L582  
> **username_1**: For example, if the my computer's LAN IP is 192.168.1.10, then to expose my the rpc interface on LAN, I would do `-rpcbind=192.168.1.10`.  
> **username_0**: Thanks! I have actually tried that, but that does not seem to be enough; e.g., above-linked docs read `"This option is ignored unless -rpcallowip is also passed."`. I have tried passing `-rpcallowip` arg as well, but that does not seem enough either.  
> **username_1**: What value did you pass for `-rpcallowip`? In my example, you would do `-rpcallowip=192.168.1.1/24`.  
> **username_0**: Could you please elaborate? e.g., what is `24`?  
> **username_1**: That is [CIDR Notation](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#CIDR_notation)  
> **username_0**: I was not able to connect from the second computer when `bitcoin-qt` was launched on the first computer with the following arguments. `--rpcbind=192.168.1.2/24` (the IP address of my computer on LAN) and `--rpcallowip `--192.168.1.1/24` (the IP of the default gateway and router in the LAN).  
> **username_1**: I think `-rpcbind` should not have the the `/24`. You can also check the debug.log file to see if there are any warnings or errors related to the rpc interface there.  
> **username_0**: I don't see any binding to port `8332` in the logs, though I could see `Bound to 0.0.0.0:8333`.  
> **username_1**: By default, the logs won't say anything about what addresses it is binding to for the RPC interface. You can enable that by starting with `-debug=http`. Are you checking `netstat` or are you checking reachability with another computer? For the latter, you may need to allow port 8332 in the windows firewall. I'm not sure why these options wouldn't work as I do observe them working for me.  
> **username_0**: I've added `-debug=http` but still cannot see entries for `8332`. I'm checking the connection with `nc -vz 192.168.1.2 8332` on the second computer which returns `Connection refused. I have also opened the port on my firewall.  
> **username_0**: Could you please paste the full command your are using to start bitcoin-qt that works for you in this scenario?  
> **username_1**: `./bitcoin-qt -debug=http -rpcbind=10.21.1.10 -rpcallowip=10.21.1.1/24 -server` is my command (my computer's IP is 10.21.1.10). There is a log line that says `[http] Allowing HTTP connections from: 127.0.0.0/8 ::1/128 10.21.1.0/24 127.0.0.1/32` and another with `[http] Binding RPC on address 10.21.1.10 port 8332`  
> **username_0**: Thanks for sharing the command you use. I executed the very same command (replacing my IP and gateway with yours), though still had the same issues are before. I do not have any of those entries in the log either. I'm using bitcoin-qt `v22`.  
> **username_0**: when I use `-rpcbind=<IP> -rpcallowip=<IP>` I read in the logs  `option -rpcbind was ignored because -rpcallowip was not specified`, and when I swap their order to `-rpcallowip=<IP> -rpcbind=<IP>` logs read: `option -rpcallowip was specified without -rpcbind`. Does it ring any bells?!  
> **username_1**: Log lines like that sound like the shell is improperly escaping/passing the arguments to the program. Instead of using command line arguments, you could try putting the arguments in the bitcoin.conf file with one argument per line without the leading `-`. For the boolean options (e.g. `-server` and `-rest`), you also need to append `=1` to those (e.g. `server=1`).  
> **username_0**: Thanks! I guess all the confusion was because of the shell not parsing the arguments correctly, since setting the values in `bitcoin.conf` worked as expected.  

---

