关于机场在公司连不上的离奇排查记录
前几天朋友换了个新机场，速度快延迟低，我在家里白嫖用得那叫一个舒坦。结果到了公司就开始玄学——死活连不上。
开始以为是常见问题，按照惯例把能查的都查了一遍:
- 系统时间？ 去 time.is 对过了，误差不到 0.3s
- 路由追踪？ traceroute 到入口 IP，一路畅通无阻
- 端口封禁？ 试了好几个节点,都是同样的症状（就它家全军覆没，备用机场是好的）
这就很诡异了。配置文件在家里能用,到公司就不行,但网络层面又看不出任何问题。难道是公司网络有什么深层检测?但其他机场的备用节点又能正常使用...
就这样用了几天备用节点,心里一直觉得不对劲。直到今天突发奇想,盯着配置文件看了半天,注意到了那个 obfs-host 参数:
爱奇艺的域名...做混淆倒是挺合理的,毕竟流量大看起来正常。但转念一想——等等,公司不会把视频网站封了吧?
抱着试一试的心态,直接 curl 测试了一下:
结果屏幕上赫然出现:
真相大白。
不是端口被封,不是协议被识别,不是时间不同步,也不是路由问题——单纯是因为公司防火墙把爱奇艺域名拉黑了,而机场的混淆恰好用的是这个域名。
所以这几天的现象就是:客户端尝试连接 → 防火墙看到 iqiyi.com → 直接阻断 → 连接失败。跟代理本身、加密协议、什么深度包检测都没关系,就是撞在了一个意想不到的应用层策略上。
排查问题有时候就是这样,技术上越复杂的方向查得越细,反而忽略了最简单的可能性。谁能想到机场会因为混淆域名"太正常"而翻车呢?
这个 case 算是记一笔了——以后遇到类似问题,记得先 curl 一下混淆域名看看...
前几天朋友换了个新机场，速度快延迟低，我在家里白嫖用得那叫一个舒坦。结果到了公司就开始玄学——死活连不上。
开始以为是常见问题，按照惯例把能查的都查了一遍:
- 系统时间？ 去 time.is 对过了，误差不到 0.3s
- 路由追踪？ traceroute 到入口 IP，一路畅通无阻
- 端口封禁？ 试了好几个节点,都是同样的症状（就它家全军覆没，备用机场是好的）
这就很诡异了。配置文件在家里能用,到公司就不行,但网络层面又看不出任何问题。难道是公司网络有什么深层检测?但其他机场的备用节点又能正常使用...
就这样用了几天备用节点,心里一直觉得不对劲。直到今天突发奇想,盯着配置文件看了半天,注意到了那个 obfs-host 参数:
{
"tag": "高级 专线 香港 08",
"type": "shadowsocks",
"server": "[REDACTED]",
"server_port": 14xxx,
"method": "chacha20-ietf-poly1305",
"password": "[REDACTED]",
"plugin": "obfs-local",
"plugin_opts": "obfs=http;obfs-host=[REDACTED].iqiyi.com", // 注: [0-9a-f]{10}.iqiyi.com
"network": "tcp",
"udp_over_tcp": false,
"detour": "direct"
}
爱奇艺的域名...做混淆倒是挺合理的,毕竟流量大看起来正常。但转念一想——等等,公司不会把视频网站封了吧?
抱着试一试的心态,直接 curl 测试了一下:
curl -vv [REDACTED].iqiyi.com:14xxx --resolve [REDACTED].iqiyi.com:14xxx:[REDACTED]
结果屏幕上赫然出现:
<body><div class="message-container">
<div class="logo"></div>
<h1>FortiGate Application Control</h1>
<h3>Application Blocked</h3>
<p>You have attempted to use an application that violates your Internet usage policy.</p>
<table><tbody>
<tr>
<td>Application</td>
<td>iQiyi</td>
</tr>
<tr>
<td>Category</td>
<td>Video/Audio</td>
</tr>
<tr>
<td>URL</td>
<td>http://[REDACTED].iqiyi.com/</td>
</tr>
<tr>
<td>Policy</td>
<td>[REDACTED]</td>
</tr>
</tbody></table>
</div></body>
真相大白。
不是端口被封,不是协议被识别,不是时间不同步,也不是路由问题——单纯是因为公司防火墙把爱奇艺域名拉黑了,而机场的混淆恰好用的是这个域名。
所以这几天的现象就是:客户端尝试连接 → 防火墙看到 iqiyi.com → 直接阻断 → 连接失败。跟代理本身、加密协议、什么深度包检测都没关系,就是撞在了一个意想不到的应用层策略上。
排查问题有时候就是这样,技术上越复杂的方向查得越细,反而忽略了最简单的可能性。谁能想到机场会因为混淆域名"太正常"而翻车呢?
这个 case 算是记一笔了——以后遇到类似问题,记得先 curl 一下混淆域名看看...
🤣28🤯5❤1
Forwarded from Howard's 碎碎念 (Howard)
https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/
在翻 Windows Shim Database 时看到的一篇文章
商业软件靠兼容性赢得市场
Windows 升级一直要保持向后兼容导致 API 不能变
在翻 Windows Shim Database 时看到的一篇文章
商业软件靠兼容性赢得市场
Windows 升级一直要保持向后兼容导致 API 不能变
Joel on Software
How Microsoft Lost the API War
Here’s a theory you hear a lot these days: “Microsoft is finished. As soon as Linux makes some inroads on the desktop and web applications replace desktop applications, the mighty empir…
Forwarded from 橘橘橘子汁 & 🍊
https://github.com/LLM-Red-Team/qwen-free-api/issues/82
https://github.com/LLM-Red-Team/kimi-free-api/blob/5c114bf5926fcdced096f583953d7e86e9433672/src/api/routes/chat.ts#L40
啧，6k star 的项目就这么简单地藏毒藏了一年才有人发现
是谁在觉得开源软件有安全保障呢
https://github.com/LLM-Red-Team/kimi-free-api/blob/5c114bf5926fcdced096f583953d7e86e9433672/src/api/routes/chat.ts#L40
啧，6k star 的项目就这么简单地藏毒藏了一年才有人发现
是谁在觉得开源软件有安全保障呢
🤔4