epiphyllum

一个解决方法：使用 NoScript 浏览器扩展屏蔽网页对本地网络发起的请求

1. 网站或域名的所有权可以通过非常简单的方式即时验证，而应用程序发布者的个人或企业身份验证过程+密钥存储/分发会繁琐得多。（额外的麻烦=额外的费用）

2. 代码签名证书泄露危害大，容易让发布者背大锅。（影响公司商誉）

3. TLS 证书使用量/签发量大，应用范围广（各种设备/各种应用/各种操作系统都在用）；而代码签名证书往往应用范围有限（例如 Windows/MacOS/Android 都有各自不同的代码签名方式）

4. 保障通过 HTTP(S)/TLS 在网络上传输的数据的私密性非常重要（ TLS 的重要性几乎无可替代），大家更愿意投钱出力推动这样保障基础安全的东西普及。

5. 对于保障发布者来源+程序完整性这些需求而言，付费代码签名证书的替代较多。例如：实际应用中往往还可以用 GPG/PGP （验证发布者&完整性）或者发布时附带 Hash （验证完整性）来解决一些信任问题。

6. 在 Windows 上付费的代码签名证书很多时候是为了过杀软，个人开发者或者小企业可能不在意这些事，而大公司在这种事情上就难受了。CA 对大公司开刀符合经济规律。

“对宝塔嗤之以鼻”可能和“孔乙己的长衫”这种心态真没啥关系，毕竟 1Panel/AMH/AppNode/cPanel/Pleak/VestaCP 也没见得有那么多人黑。

以前叫它“删库塔”可能是少数恶性 bug ，结果宝塔自己真爆了几次利用难度比 log4j 还低的漏洞（ phpmyadmin 未授权访问以及不止一次 xss2rce ），还全是低级错误导致的，这只能怪它草台班子自己不争气。

年初宝塔被挖出来他们家官网的防火墙演示站自带 SQL 注入/未授权访问（ https://v2ex.com/t/1015934 ），前几天又出了事故让官网和 API 全部离线。
作为卖安全产品的公司，自家防火墙还能给客户引入新漏洞；作为卖运维服务的公司，自家官网遇到单点故障连个灾备都没有。只能说实在是太丢人了。

之前宝塔面板的代码质量也是一言难尽：Python 能做的文件操作它非要去拼字符串调 Shell （有时输入内容还过滤不干净）、分发二进制软件包用明文 http 还不带校验……

总之，宝塔的声誉纯粹是他们一次又一次自己丢掉的，虽然靠着产品简单方便吸引了不少用户，但卖了那么多做不好确实该挨骂。（不过现在宝塔在出了这么多事挨了这么多骂以后的确也有长进。

当你配置的代理以`https://`开头时，git 会首先使用 TLS 连接这个代理服务器。
例如，假设我使用了以下命令配置代理：
`export HTTPS_PROXY=https://127.0.0.1:10809`
`git config --global https.proxy https://127.0.0.1:10809`
在 git 发起请求时抓包看一下，可见 git 给 HTTP 代理发了一个 TLS Client Hello 。v2rayn 日志也提示收到一堆非 HTTP/1.1 的二进制，Git 也返回楼主遇到的同款错误。

而 v2rayn （包括 xray/v2fly/sing-box 等）代理软件显然不会自己给 127.0.0.1 签一个 TLS 证书（毕竟麻烦&没必要），它们开放出来的、用于本地访问的 HTTP 代理是不支持像各种网站服务器那样接收 HTTPS/TLS 连接的。


解决方法：
将"https://"替换成"http://"，或者配置 socks5 代理。


这里有几个容易混淆的点：

1. HTTPS_PROXY 或 https.proxy 并不是说这里必须要填一个 HTTPS 代理，它的意思是“指定访问 HTTPS 的服务时所用的代理”。
同理，HTTP_PROXY 或 http.proxy 的意思是“访问未加密的 HTTP 服务时所用的代理”

2. 在此场景中"https://"开头的代理和另一个概念（例如：“xx 免费代理”“全球开放代理”那些网站/场景下所说的“HTTPS 代理”）是不一样的：
- 这里提到的"https://"开头的代理需要客户端用 TLS 连接
- 那些 xx 网站等场景下经常说的 HTTPS 代理指的是：支持"CONNECT"这一 HTTP 请求方法的、基于 HTTP 协议的代理；
- （因为当年有好些“普通 HTTP 代理”只支持或开放 GET 、POST 等方法，访问"https://"网站时 TLS/SSL 加密解密由代理服务器处理，代理服务器能看到全部明文
-（ “CONNECT 方法可用于访问使用 TLS/HTTPS 的网站，它实际上提供了一个中继 TCP 流的隧道”

很好看！换掉 VSCode 左上角的蓝色默认图标后简直完美


不过拆分编辑器区域时标签栏似乎有点小 bug：
（当某一编辑器区域未在焦点时，其当前标签的背景色会变成与字体相同的颜色）

可能是 Windows 安装程序的 bug ，请先看看你现在开机的时候进入的是哪一个 Windows 启动管理器(bootmgfw.efi)

（如果不清楚，可以进 BIOS 菜单/UEFI Setup 看启动选项/启动顺序； DiskGenius 、EasyUEFI 之类的软件也都可以查看&管理 UEFI 启动项

如果能确定两块硬盘里只有一个 Windows 启动管理器的话，可以在 PE 下利用 BOOTICE 或者 EasyBCD 之类的工具编辑 bootmgfw.efi 旁边的"BCD"文件（位置：\EFI\Microsoft\Boot\BCD)，给 BCD 里面的 Windows 启动项设置正确的“启动磁盘”与“启动分区”后（即：你的 1T 硬盘的 C:分区），Windows 启动管理器就能找到你图片上报错的 winload.efi 并启动系统了。


此外，有少数笔记本可能存在玄学 BUG ，硬盘的放置顺序或编号会影响启动，如果上面的方法没用，可以试一下调换两块硬盘的位置。