但是 198.18.0.2 是什么？它并不是本机某网口的地址。
越研究发现越神奇。
首先使用 route -n get 198.18.0.2 结果如下:
route to: 198.18.0.2
destination: 198.18.0.2
gateway: 198.18.0.1
interface: utun10
但是只要不是 198.18.0.1 和 198.18.0.2 (有时候 0.3 也可能是）则结果如下:
route to: 198.18.0.4
destination: 128.0.0.0
mask: 128.0.0.0
gateway: 198.18.0.1
interface: utun10
route to: 198.18.1.2
destination: 128.0.0.0
mask: 128.0.0.0
gateway: 198.18.0.1
interface: utun10
看到这个 destination 应该是 CIDR 128.0.0.0/1 起作用了。
查看路由表:
~ netstat -rn
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 192.168.31.1 UGScg en1
default link#28 UCSIg utun3
1 198.18.0.1 UGSc utun10
2/7 198.18.0.1 UGSc utun10
4/6 198.18.0.1 UGSc utun10
8/5 198.18.0.1 UGSc utun10
16/4 198.18.0.1 UGSc utun10
32/3 198.18.0.1 UGSc utun10
64/2 198.18.0.1 UGSc utun10
100.64/10 link#28 UCS utun3
100.100.100.100/32 link#28 UCS utun3
100.124.11.45 100.124.11.45 UH utun3
127 127.0.0.1 UCS lo0
127.0.0.1 127.0.0.1 UH lo0
128.0/1 198.18.0.1 UGSc utun10
169.254 link#13 UCS en1 !
169.254.12.71 50:ed:3c:3:2:c UHLSW en1 !
169.254.35.85 60:dd:8e:69:5c:d0 UHLSW en1 !
192.168.31 link#13 UCS en1 !
192.168.31.1/32 link#13 UCS en1 !
192.168.31.1 88:c3:97:c8:2:b6 UHLWIir en1 1169
192.168.31.24 4:cf:8c:29:a4:97 UHLWI en1 1157
192.168.31.59 c:7a:15:c1:ad:cc UHLWI en1 !
192.168.31.73 6:6e:f7:98:f3:4b UHLWI en1 349
192.168.31.80 84:c5:a6:9e:4:3 UHLWI en1 601
192.168.31.129 86:11:14:df:18:ce UHLWI en1 555
192.168.31.144 56:f9:cf:1e:97:7d UHLWI en1 95
192.168.31.166/32 link#13 UCS en1 !
192.168.31.189 66:17:81:34:32:5c UHLWI en1 1112
192.168.31.199 60:dd:8e:69:5c:d0 UHLWIi en1 1160
192.168.31.213 50:ed:3c:3:2:c UHLWIi en1 1189
192.168.31.214 2:69:d6:3d:12:3d UHLWI en1 1179
192.168.31.222 f8:d0:27:54:e4:84 UHLWI en1 1200
192.168.31.255 ff:ff:ff:ff:ff:ff UHLWbI en1 !
198.18.0.1 198.18.0.1 UH utun10
224.0.0/4 link#13 UmCS en1 !
224.0.0/4 link#28 UmCSI utun3
224.0.0.251 1:0:5e:0:0:fb UHmLWI en1
239.255.255.250 1:0:5e:7f:ff:fa UHmLWI en1
255.255.255.255/32 link#13 UCS en1 !
255.255.255.255/32 link#28 UCSI utun3
里面关于 utun10 的几条解释:
2/7 地址范围: 2.0.0.0 到 2.255.255.255
4/6 地址范围: 4.0.0.0 到 7.255.255.255
8/5 地址范围: 8.0.0.0 到 15.255.255.255
16/4 地址范围: 16.0.0.0 到 31.255.255.255
32/3 地址范围: 32.0.0.0 到 63.255.255.255
64/2 地址范围: 64.0.0.0 到 127.255.255.255
128.0/1 地址范围: 128.0.0.0 到 255.255.255.255
198.18.0.1 就表示它自己
所以除了 198.18.0.1 之外其余的都应该解析成 128.0.0.1 才对啊。那 198.18.0.2 为啥也解析成自己了呢？
我的理解: 跑的服务程序可以监听本地网口, 每个网口有对应的 ip 地址，如果监听 0.0.0.0 则表示所有网口，如果监听 127.0.0.1 则表示监听 lo0 ，如果监听 192.168.31.166 （我电脑 en0 地址）则表示监听 en0 网口，任何发送到这个网口的数据（当然要指定好端口号）都会被转发到这个服务程序。
但查看 ifconfig 则看不到 198.18.0.2 是属于哪一个接口的，而它是 utun10(198.18.0.1)的一个子网 ip 。当开启虚拟网口后（软件的增强模式透明模式） dns 被改成 198.18.0.2 是为什么？使用 dig 程序测试也是没问题的:
~ dig @198.18.0.2 -p 53 baidu.com
~ dig @198.18.0.2 -p 53 google.com
~ dig @198.18.0.2 -p 53 fb.com
结果都是 fakeip 。
所以，我哪里理解错了吗？为什么会有 198.18.0.2 ？
写一个程序来测试:
```javascript
const http = require('http');
const server = http.createServer((req, res) => {
res.setHeader('Access-Control-Allow-Origin', '*');
res.setHeader('Content-Type', 'text/plain');
res.end('Hello');
});
const ifrq = "198.18.0.2";
server.listen(3000, ifrq, () => {
console.log(`Server running at http://${ifrq}:3000/`);
});
```
开启增强模式后 如果 ifrq 是 198.18.0.1 则可以正常绑定到这个地址，打开这个地址 3000 端口后正常响应。
但如果将 ifrq 改成 198.18.0.2 ，则服务起不了 Error: listen EADDRNOTAVAIL: address not available 198.18.0.2:3000.
