不要望文生义。你先搞懂 HTTP CONNECT method 的用法再来看这个文档就不会有疑问了。

大写的 CONNECT ，这是一个单独的 HTTP method ，跟 GET/POST 对等的，只是专用于代理罢了。你引用“the proxy CONNECT method may connect”并自我发挥“CONNECT 其实只在 client->nginx proxy 这个环节吧？ nginx proxy->server 应该是 tcp 连接”实在是理解歪了。

这句话的意思是是通过 CONNECT 方法可以去连的端口。从 cient->nginx proxy 这个环节，操作是发一个 CONNECT 命令，指导 nginx 建立 tcp 连接去连 server 的目标端口。在逻辑上这是一个整体操作。你非要把“CONNECT 方法可能连接的端口”理解为 ient->nginx proxy ……这个逻辑就不对，是 cient->nginx proxy 已经建立好 tcp 连接了，才会按 HTTP 协议的格式发送 CONNECT 请求，所以 cient 能“连”（ connect ，小写，作为一个通用英语单词） nginx proxy 什么端口，跟“CONNECT”（大写，特指 HTTP CONNECT method ）请求根本就是两码事。

@ttgo “这个防火墙的 ip 是啥？怎么远程设置这个防火墙呢？”

防火墙可以做成透明模式，从接进来的设备和上游看就是一个交换机，防火墙从二层流量里剥出三层载荷后做转发过滤。这样防火墙在数据平面是没有 IP 地址的。

要远程管理的话，可以单独拉一根线，一头接在防火墙的管理端口，另一头接到你办公室的网段。给防火墙的管理端口配一个你办公室的 IP 地址就可以了。这个管理端口只负责控制平面，和数据平面没有关系。当然也可以在你电脑上加一块网卡，跟防火墙的管理端口组一个 /30 的小私网。

@ttgo “这个听起来太复杂了。。最好现成的软硬件解决方案。”……那有没有考虑过找网络设备代理商给你做方案？

哦，看到了，“写字楼 → 我们的交换机”……那就没问题了，可以把自己的设备上弱电井。

#4 说的对，招一个 IT

或者你自己成为 IT

@ttgo
1. “每个房间都有自己独立的外网 ip ”是因为“我们需要每个房间都有自己独立的外网 ip ，这是公司治理的刚需”，还是说“按园区默认设置就是每个房间都有自己独立的外网 ip ，现在这样了要改动有阻力”，还是说“老子只想管控，不想改动”？
2. 即使是前者，技术上也是可以实现的。
3. 如果你愿意听我的，路由上移，有个可能的障碍是园区物业和 IT 是否允许你们把自己的设备放进弱电井，这个要沟通确认好。
4. 不论如何，企业（哪怕是只有几个工作组的小企业）级的网络管理比起家庭网络来还是要复杂很多的。其中有些常用的基本原理要懂，比如 VLAN 。
5. 我最不想说的……如果不想动拓扑，满足“老子只想管控，不想改动”的需求，那三个房间的路由器可以选择能刷 OpenWRT 的，然后有什么配置都刷到三个路由器上。这样做可能需要你写一些批处理的脚本。

如果不是因为公司组织架构原因各房间必须有自己可控的路由器，那唯一正经的办法就是把路由做在上层。下面办公室有分网段的需求的话再切 VLAN 。不懂网络的人在办公网络里常做的蠢事之一就是毫无克制地乱用家用路由器。

再比如 Flask 框架官方文档的解决办法 https://flask.palletsprojects.com/en/2.0.x/deploying/fastcgi/

比如这个例子 https://framkant.org/2017/09/flask_script_name/

现在流行的前后端分离项目，最终部署出来的前端静态资源都是“编译”过的，项目内引用路径是写死的，放到反代子路径下，如果你不能自己重新 build 的话，那除了用 sub_filter 来做 dirty hack 之外真没啥好办法。

其实在 good old CGI 时代，前后端不分离的系统，写得体贴的系统会根据 web server 或者反代传过来的 SCRIPT_NAME + PATH_INFO 来自适应地“意识到自己运行在子路径下”从而调整页面内路径引用的生成规则。缺点时静态资源的路径每次都要计算，性能有影响，当然对大部分系统来说没必要担心这个性能。

按惯例，每年 5 月底 6 月初教育网会有一大批服务器或网络设备集中维护……

是从一线互联网大肠毕业出来的不懂关系数据库不懂传统 CRUD 只会在没毕业的夹狗屎指定的萎服务业务框架里填空的后端吧

传统 IT 的技术屎和互联网的技术屎是两种不同风味的屎，但都是屎。

客户端软件在建立 SSL 连接的时候需要验证对方证书是否在“我认可的”Root CA 链下。这个 Root CA 的列表是储存在本机系统里某个地方的。如果你用的是 Linux 发行版们打包好的软件，通常会改过代码或者编译选项，指定从一个系统默认位置去读。但如果是第三方或者自己编译的，可能软件上游默认并不会去读发行版设置的默认位置，那么 Root CA 列表可能会过时或者缺失。

可以试试这段里提到的 REQUESTS_CA_BUNDLE / CURL_CA_BUNDLE 环境变量 https://requests.readthedocs.io/en/latest/user/advanced/#ssl-cert-verification

把它指到发行版默认的位置去。Arch 我不清楚，deb 系是 /etc/ssl/certs/ca-certificates.crt ，你找找看 Arch 里对应的位置试试看。

这不叫技术好。只是喜欢、好奇而已，甚至可能只是自以为喜欢、好奇。“好”是看结果而不是动机的。

给你举一个技术好的例子：

## Linus 亲手帮英特尔优化 LAM 代码

去年年底英特尔将 LAM （ Linear Address Masking：线性地址掩码） 功能提交到 Linux 6.2 的合并窗口，但该功能受到 Linus 的批评并拒绝合并。在经历了一段时间的代码改进后，Linus 终于同意将 LAM 代码合并到 Linux 6.4 窗口。

但 Linus 似乎仍对英特尔工程师提交的代码不太满意，在合并了 LAM 代码后，先是写了一个使 access_ok () 独立于 LAM 的新补丁，而后又亲手写了多个补丁对 LAM 代码进行了优化。

在最新提交的 LAM 优化补丁中，Linus 解释了自己的动机：

> 我对此版本中的 LAM （“线性地址掩码”）的 “access_ok ()” 的完成方式感到很不爽，而且它实际上也有一些小 Bug ，所以我动手清理了代码。

改动主要集中在以下几方面：

* 使用 __user 指针的符号位而不是屏蔽地址，并根据 TASK_SIZE 范围检查它。 get/put_user () 端做了这部分，但是 'access_ok ()' 做了天真的 “掩码和范围检查”，它不仅生成多余的代码，还意味着 __access_ok 本身的任务做得不好，copy_from_user_nmi () 没有得到正确的检查。
* 将所有 64 位代码仅移动到 64 位版本的头文件中，这样就不会污染共享的 x86 代码，也不会误导用户 LAM 可以在 32 位环境中工作。
* 修复地址掩码中的 Bug （这不重要，只是完全删除了错误的代码）。
* 几个简单的清理，并添加了关于 access_ok () 规则的注释。

Linus 重新编写了约一百行代码来清理 LAM ，这意味着如果测试没问题， 就可以在 Linux 6.4 中顺利启用 LAM 功能。不过这次 Linus 竟然亲自动手为英特尔工程师修改 “有瑕疵的代码”，这种情况相当少见。

除了第三个 System Interpreter 不建议选之外，其它都差不多。不过你既然用 conda 装的那就先 conda 吧。

都在跟你说数据库端口不要对公网开放，你非要坚持说数据库端口不放公网你就没法维护……

别忘了操作系统组件的安全更新。

以上都是 fat jar 的方法。还可以 build 成 war ，用传统的 tomcat 方法启动。