本文由 发布，转载请注明出处，如有问题请联系我们！ 发布时间: 2021-08-01localhost8080无法访问-浏览器打不开localhost原因
加载中Chrome正方案严禁来源于不安全网站的常用互联网要求，以维护客户免遭对于专用型互联网上无线路由器和其它机器设备的跨网站要求仿冒(CSRF)进攻:
从 Chrome 94 逐渐阻拦来源于不安全公共性平台的独享互联网要求。在 Chrome 101 中完毕的停止使用实验。在 Chrome 92 中获取一些 Chrome 对策，容许代管的 Chrome 布署永久性绕开弃用。什么叫网络系统？
在网络的详细地址构架中，独享互联网就是指合乎RFC 1918(IPV4)和RFC 4193(IPV6)规范，应用独享IP地址空的互联网。独享IP不可以立即接入到互联网技术，因而需要应用IP地址转化器(NAT)或服务器代理来完成。
一般，我们在公司中搭建的局域网络，无线网络中的局域网络及其您的当地服务器全是专用型互联网。专用型互联网接入标准。
专用型互联网浏览标准(之前的CORS-RFC1918)限定了网址向专用型互联网上的服务器发送要求的工作能力。它只容许来源于安全性前后文的该类要求(HTTPS)。该标准还拓展了跨域请求共享资源(CORS)协议书，因而网址在推送要求以前务必根据使用互联网上的网络服务器受权大会。
专用型互联网要求就是指总体目标网络服务器的IP地址比获得要求的发动者的IP地址更加专用型的要求。比如，从公共性网址(https://example.com)到独享网址(http://router.local)的要求或从独享网址到localhost的要求。在人们的开发设计流程中，这种状况其实是非常普遍的，因此大家必须开发者提早使用并作出回应。浏览localhost。
假如您的网址必须向当地服务器推送要求，那麼您只要将您的网站改版到HTTPS。混和內容不容易阻拦以http://localhost(或http://127)为目的的要求。*.*.*，http://[::1])，即便他们是以安全性前后文推送的。
一定要注意这儿有一个洞。WebKit模块和根据它的电脑浏览器(例如Safari)在这儿不符W3C混和內容标准。这种要求将被视作混和內容，禁止访问。他们都没有完成专用型互联网接入。因而，假如网址应用这类电脑浏览器的手机客户端，就可以试着HTTP协议书，这类电脑浏览器依然容许要求localhost。
浏览独享IP。
假如您的网址必须根据独享IP地址向总体目标服务器发送要求，简易地将驱动器网站改版到HTTPS不是可以的。混和內容阻拦安全性前后文根据密文HTTP开展要求，因而新安全性的网址依然会察觉自己没法开展要求。有几种方式能够化解这个问题:
将两边升級到HTTPS。
这一计划方案有点儿难，由于HTTPS只对于公共性网站域名。您必须最先为您的独享IP申请注册一个公共性网站域名，随后配备DNS分析以将公共性域名跳转该独享IP，最终为该网站域名配备TLS资格证书。
应用WebTransport。
在这个计划方案中，您不用自身操纵解析域名，反而是必须在专用型互联网上实现一个数据传输网络服务器。WebTransport是WebRTC系统软件下的一套电脑浏览器API，给予手机客户端和集群服务器的低延迟时间和双向通信。
WebTransport 给予根据 QUIC 和 HTTP3 完成的API ，全自动得到 QUIC 和 HTTP3自身的特点，例如网络层的时延，防止队头堵塞。双向通信的工作能力，好几个传送安全通道重复使用一个联接的工作能力，可以有效的取代 WebSocket。给予推送/接纳不靠谱 UDP 的工作能力，这个是电脑浏览器一直缺乏的工作能力。关键的是，根据应用WebTransport的资格证书锁住体制，您能够绕开缺乏由可靠CA签字的合理TLS资格证书的难题。
反方向置入。
网址的体系结构能够从独享网络服务器得到，随后它的全部子資源(如脚本制作或图象)能够从公共性网络服务器(如CDN)得到。以这类方法转化成的网址能够向独享服务器发送要求，由于这种要求是同宗的，它乃至可以应用私有ip向别的用户推送要求。
这一计划方案临时能够应用，以后官网很有可能会限定这类状况。
CORS浏览要求的变更。
CORS浏览要求是一个HTTP OPTIONS要求，含有一些Access-Control-Request-*头，标示事后要求的特性，比如是不是容许跨域请求。专用型互联网浏览标准的第二一部分是应用CORS浏览要求来操纵从安全性前后文进行的常用互联网要求。即便要求是以安全性前后文进行的，总体目标网络服务器也必须向发动者给予显式受权，而且仅有在受权取得成功时才会推送要求。
最终
查验你复杂的平台是不是有连接特有互联网，如果有，快速解决~
