改成这样：
location /api {
proxy_pass http://localhost:3000;
}

现在这行情，外包也不是想进就能进的。。。

就算再回到那天，大概得到的还是一样的结局。

我觉得这个是一种很 low 的行为。

实现方式不一样，使用方式不一样，都是基于浏览器的

我之前也做过一个类似的浏览器爬虫。。。

@zyxcompany 图片/文件可以不用上传的，js 可以在浏览器上处理。

估算就是需要很多其他的数据来作为估算的依据，不谈具体的业务场景没有数据来源的“估算”就是耍流氓。

有的场景就是上线后 100%的客户端一整天都在线，有的场景就是 80%的用户每天 9 点在线其他时间都不在，有的场景就是每年只有 1 个月 PV 暴增 10000 倍。没有什么统一的算法能衡量这个东西。

如果“估算方法”能量化的话，那么可以说用 20%的方法 可以解决 80%的系统估算问题。

实名制提交代码，实名制开源，再加上公安局备案机制。手动狗头

问题大概是执行脚本的工作目录的问题，脚本虽然能执行，但是脚本的工作目录应该是在用户的家目录下，不是在 git 仓库下，所以失败了。你可以在脚本第一行加一句 cd ，切换到 git 仓库的路径下。

看价值观吧，不同的事情在不同的人看来，价值多少都不一样。结果可以有价值，过程也可以有价值。

1. 一个很常见的误区，家用”路由器“它不是书里面提到的”路由“器，它就是一个 ”NAT 设备“+”二层交换机“的二合一设备。

2. 真正的路由器 它只负责转发数据包，即“路由”。进过它的包进去是啥，出去还是啥。

3. 虚假的路由器（家用路由器/光猫），它看上去在“路由”，实际上背地里在做 NAT 地址转换。

两个不能混在一起谈。

机会是留给有准备的人的

这个帖子牛逼

感觉作用不大。一个是字符串转 base64 的工具太多了，完全没必要开个浏览器再加个书签。

提个建议，不如支持一下 图片/文件 和 base64 互相转换 。感觉这个场景下，很多本地的工具都是没有的，所以你可以支持一下。

这个看用的那种发行版吧，如果是 debian 系的话，那就用 ufw ，如果是 redhat 系的话，那就 firewalld 。
ufw/firewalld 都是 iptables/nftables 的封装，现在基本上可以不直接敲 iptables 命令，也可以不用去理解各种表链这些概念。

也有一些上面说的 cockpit 里面的简单的管理面板，还有一些桌面 GUI 的应用，它们基本上也都是调用 ufw/firewalld 的接口来设置防火墙。

不管系统里面没有安装 ufw/firewalld ，也都是可以直接使用 iptables 的，但是写规则的话就要对 iptables 有点了解，所以 op 应该是觉得这个用起来比较难。所以建议 op 试试 ufw/firewalld 。

另外我理解的，现在新的发行版，应该都是不推荐直接使用 iptables 来操作防火墙的，自己编写的 iptables 规则 它会影响到自带的 ufw/firwalld 生成的规则，ufw/firewalld 操作起来也更“人性化”一点。