Chrome 更新至 94 版本后，为了保护用户免受针对专用网络（也就是内网）上的路由器和其他设备的跨站点请求伪造 (CSRF) 攻击，限制网站向专用网络上服务器发送请求的能力，该限制当前(Chrome94)中可以用配置开关临时解除，预计于 Chrome v102（2022 年五月）成为正式特性
私有地址
| 地址块 | 姓名 | 参考 | 地址空间 |
|---|---|---|---|
127.0.0.0/8 |
IPv4 环回 | RFC1122 | local |
10.0.0.0/8 |
私人使用 | RFC1918 | private |
172.16.0.0/12 |
私人使用 | RFC1918 | private |
192.168.0.0/16 |
私人使用 | RFC1918 | private |
169.254.0.0/16 |
链接本地 | RFC3927 | private |
::1/128 |
IPv6 环回 | RFC4291 | local |
fc00::/7 |
独特的地方 | RFC4193 | private |
fe80::/10 |
链路本地单播 | RFC4291 | private |
::ffff:0:0/96 |
IPv4 映射 | RFC4291 | 查看映射的 IPv4 地址 |
这些类型的地址都属于私有地址。
推出Private Network Access特性的原因
大概就是为了防止当我们在内网环境中访问到某些不怀好意的网站时，这些网站去请求我们的内网资源。
那有什么办法能够绕过这个特性,让我们依然能够在公网访问的网页中去访问内网中的资源呢？
chrome://flags/
引导用户进入 chrome://flags/ 搜索 Block insecure private network requests，置为 Disabled。
缺点
- 需要引导用户进行设置，步骤比较多，用户操作成本高；
- 预计于 Chrome v102（2022 年五月）成为该特性将成为正式特性，
Block insecure private network requests不在生效。
公网内网两端均升级为 Https
其实升级公网的域名为https就能解决访问内网接口的问题。但如果我们在内网域名不升级到https的情况下需要访问内网视频等媒体资源，又会触发到chrome的另一个安全策略Mixed Content。即在https域名访问http的资源时，chrome会自动将https转化成https，详情可查看：blog.chromium.org/2019/10/no-...
所以需要两端均升级为https。
缺点
- 内网服务器升级https会产生相应的成本
将公网地址反向代理到内网地址
修改内网服务器nginx配置，将公网地址反向代理到内网地址，让用户通过访问内网地址去访问内网资源。
ini
体验AI代码助手
代码解读
复制代码
server { listen 8062; server_name localhost; location / { proxy_pass https://xxx.com/; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }
缺点
- 修改内网服务器配置需要相应成本