我怀疑基于某种计算机的IP地址，实际上已通过某种安全机制阻止了https连接.

I suspect that the https connection is actually blocked, based on the IP address of the machine, by some security mechanism.

之所以这样，是因为如果我更改机器的ip并生成一个新的个人访问令牌，它似乎只能工作一次，只有一次，因此，我猜想它是一个安全防火墙网络上的主机正在默默地阻止连接.他们还告诉我，通过查看McAfee日志，问题不存在.我已经通过在同一台计算机上克隆一个bitbucket私有存储库进行了测试，但是授权失败，所以github看起来也没有错误...

I've derived this because if I change the ip of the machine and I produce a new personal access token, it seems to work for just a single time, one shot, hence I'd guess that it is a security firewall on the network is silently blocking the connection. They also told me that, by looking at McAfee logs, the issue is not there. I've done a test by cloning a bitbucket private repo on the same machine but the authorization fails, so github looks not at fault either...

所以最后我要说的是此答案中所述的Blue Coat统一代理.

So finally I'd say it could be Blue Coat Unified Agent as described in this answer.

是的，这已经确认，我暂时断开了Blue Coat Unified Agent的连接，并且git clone现在也可以通过https正常运行. 为了确定要解决的问题，他们从git verbose中注意到了错误401，并且可能还委托了github证书.

Yes, this is confirmed, I have momentarily disconnected the Blue Coat Unified Agent and git clone is now working as expected also via https. To definitely fix it they noticed from git verbose the error 401 and maybe entrusted github certificate.

就原始问题的描述而言，另请参见以下步骤，在重现此github问题的步骤中报告了有关"与SSL拦截相关的多个问题(与代理，企业MITM等有关的环境)"

As far as the description of the original problem is concerned, see also the following sentence reported in the steps to reproduce this github issue about the context of "Multiple issues related to SSL Interception (environs with proxy, enterprise MITM, etc)"

建议设置实验室并配置企业级 执行MITM的安全产品(例如BlueCoat或类似产品)，然后 使用内部证书进行回传.

Recommend setting up a lab and configuring an Enterprise grade security product such as BlueCoat or similar that does MITM, then using internal certificates for the pass-back.