@sentinelK 另外从 OP 的表述来看，他的疑问显然不是翻译问题。如果是翻译问题，那应该是在这个语境里 render 使用合理但翻译成渲染不合理，而他显然是在确认这个语境里英文的 render 和中文的渲染对应的情况下，质疑英文 render/中文渲染这个名字是否能准确表达语义。

@sentinelK 不要泛泛而谈空对空。就 web 开发里的从模板+数据生成页面这件事来说，中文里说的渲染就是直接来自英语里的 render ，而且是老早就有的事，不是 react 和 vue 时代的培训班生造出来的。有一定年岁而且习惯看英文材料的老 web 开发者应该都有印象。

这也怪培训班？还特么的从 vue 、react 时代？

英语原文里早在不知多少年前就用 render 表示根据 HTML 模板和实际数据来生成最终页面的过程了。

@tempw 是指 4K 显示器，24 算非常规的。

OP 要被一群精通大厂职场螺丝钉精神的爹友们拍死了

3. 多 WAN

可能需要的场景
1. 简单的多 LAN 段，每个口一段。
2. 跟交换机之间做 LAG 。

文档并没有歧义。你对涉及到的背景知识了解不够罢了，另外也可能英文阅读能力有待提高。

不要望文生义。你先搞懂 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 月初教育网会有一大批服务器或网络设备集中维护……