有些事情，不做不知道，一做吓一跳。
最近我搞了个 GitHub 反向代理，部署在 Cloudflare Worker 上，本意是方便在某些网络环境下访问 GitHub。代码写好了，部署成功了，当天晚上看好好的，第二天一看就被Cloudflare标记为钓鱼网站并且收到了警告邮件。
当时我人都傻了。
开始入坑
众所周知，部分地区访问 GitHub 的体验…一言难尽。虽然有各种加速方案，但大多依赖第三方服务，不太稳定。于是我想到一个思路：用 Cloudflare Worker 做反向代理，把请求透明地转发到 Github.com，再把响应中的 URL 重写回代理域名。
原理其实很简单，听起来很完美对吧？
着手开发
整个项目的核心就是 worker.js 这一个文件，大概做了这几件事：
请求转发：Worker 收到请求后，保留 Path 和 Query，直接转发到 Github.com。
重定向拦截：GitHub 返回 301/302 时，把 Location 头里的 Github.com 替换成代理域名，防止浏览器直接跳走。
内容改写：根据 Content-Type 判断响应类型，对 HTML、CSS、JS 分别进行 URL 重写。HTML 里改 href、src、action 等属性，CSS 里改 url() 和 @import，JS 里改字符串中的 URL。
其他传输：其他资源（如图片、字体等）不做修改，直接流式返回，无需代理。
被标记钓鱼网站
浏览器弹出的警告页面写着大意：“Microsoft 建议你不要继续访问此站点。已向 Microsoft 报告此问题，以阻止可能试图窃取个人或财务信息的钓鱼威胁。”。
仔细想想，好像也…不冤。
这不就是经典的钓鱼网站特征吗？
安全厂商标记钓鱼网站主要靠启发式检测，看网站行为是否可疑。我这个代理站点完美命中了启发式检测的特征，用一个无关域名展示另一个知名网站的内容，还带有登录表单。
说实话，这确实是一个正当的安全防护机制。
危险警告
经过多次部署尝试，本项目的反向代理方案基本无法行通。部署后有极大概率会被 Cloudflare 以及 Microsoft 双方同时标记为钓鱼网站，不仅浏览器会弹出全屏警告拦截访问，Cloudflare 还会直接下发警告邮件甚至冻结你的 Worker 服务。
请不要再尝试部署本项目，一切后果由部署者自行承担，与作者无关。
这大概就是”技术上可行，但现实中行不通”的典型案例吧。