49年的解放军大概率会：

• 在朝鲜战场上堵枪眼、举炸药、冻成冰雕连，供全国人民作为榜样学习。

• 从朝鲜战场上回来，三年吃了个大饱。

• 好不容易没撑死，接下来十年健了个大身。

49年解放军的后代还有可能赶上：

• 90年代全民大就业。

• 2020全民大保健。

@natasha #185760 是的，好多政治学入门科普，国外译本翻译质量差，国人作者的科普又大多夹杂中共意识形态。这本书讲得通俗易懂，查了一下作者李宇晖应该是这位

https://ecdm.fandom.com/zh/wiki/李宇晖

看作者的介绍是美国加州大学政治学在读博士，属于新一代“民运”（非贬义），可惜知名度不高，网上没什么资料。

这篇文章真的挺不错的，我觉得哪怕看50%都受益匪浅。

标题感觉起的不太好，“给孩子看的政治学”这样的标题会让人低估正文的信息量，其实政治常识大约99%的成年人都未必了解。

这里的重点难道不是

应检尽检、应隔尽隔、应收尽收、应治尽治

如果不说出处，我还以为这话是陈全国同志讲话稿摘录出来的。

几年前高压治理、网格化管控措施在边疆试验成熟，将来一段时间这些措施就会借着疫情管控推广到内地和中心城市。

你说的这种技术已经有了，叫做反爬虫字体，简单来说就是自己定义一套CSS，网页中实际的字体编码则是私有编码（不仅是私有编码，还会定期更换，加大爬取难度）。网页渲染的时候，根据私有编码画出文字，爬虫只能爬到乱码。

另外是否有人了解商业公司训练和部署一个覆盖全国的用于文字识别的神经网络至少要多长时间？

OCR的准确率没有想象中那么高，特别是文字存在排版、有干扰的情况下准确率更低，达不到实用水平。如果一定担心OCR，在图片上划一些线即可，做法类似验证码。

我的建议是不要想着去和国内的审查系统做斗争，普及便易的翻墙手段才是王道。无论开发出怎样的混淆方法绕过机器审查，最终都过不了人工审查这一关。换句话说，你的战友能看懂的，审查人员也能看懂，更不用说审查方还可以用事后惩罚等措施无限推高发言的机会成本。

看 https://2047.one/t/16445 有感

分三个问题：

一、

中共计划在2025年完成全国各级应急广播系统及平台建设……在有网友质疑该系统，是不是为了以后断网做准备的？

这位"网友"想得太多了，应急广播系统是很基础的民防设施，不必什么都和“中共作恶”挂钩。

请见美国的紧急广播系统，必要时候会掐断民用广播（含短信）向民众报警

https://zh.wikipedia.org/zh-hans/紧急广播系统

此广播系统最著名的事件就是2018年夏威夷导弹虚警

二、中共是否闭关锁国？

不好说。中共的最高利益是保证政权的连续性，如果闭关锁国有利于中共的存续，那么中共就会这么去做。

需要知道，中共不是铁板一块，它是一个权力寻租和官员效益考核的缝合体，这其中既包含习近平/赵家人的利益，也包含权力机器上大大小小官员的利益。或许有些高层很享受定于一尊的感觉，但闭关锁国对其它各方利益都是重大打击，是否闭关锁国要看两方博弈的结果。

我个人认为中共在政治和文化上会愈加封闭，体现在盲目自大和排外；经济上的开放程度基本不变，以国内市场绑架西方利益；在人才流动上会只进不出，尽可能吸收西方国家一批中高层华人带着技术和管理经验回国创业（例如最近的GPU创业潮）。

三、假如闭关锁国，中共是否会掐断互联网？

当然会，都闭关锁国了，难道留着互联网方便大家起事不成？

详细内容参考hCaptcha官方文档：https://docs.hcaptcha.com/

本文可作为教程和文档的补充。

使用hCaptcha前需要注册账号，注册完成后，会得到两个令牌

• 一个令牌叫site key，是32个字符的uuid。site key放在前端，也就是需要插入到显示验证码的网页上，因此是可以公开的。

• 另一个令牌叫Secret Key，是40位的16进制数。Secret Key放在后端，不可公开。

部署hCaptcha分两步：

1. 在网页上插入hCaptcha控件，这段代码负责显示hcaptcha控件。比如说你希望在个人博客的评论区上添加验证码，就把这个控件放到发布按钮附近。

2. 在服务器代码上部署后端验证代码，这段代码会把用户的验证码递交给hcaptcha服务器。比如你希望别人发布评论的时候填写验证码，就把后端验证代码添加进发布评论的逻辑里。

在hcaptcha验证过程中，存在三方：用户（填写验证码的人）、网站服务器（你要部署hcaptcha的服务器）、和hcaptcha的官方服务器。hcaptcha的工作流程是：

1. 用户填写验证码；

2. 验证码上传到网站服务器上，上传的内容称为Response；

3. 网站服务器把Response和自己的Secret Key一起打包，发送给hcaptcha的官方服务器；

4. hcaptcha的官方服务器把验证结果发送给网站服务器；

5. 网站服务器根据验证结果，决定是否放行。

6. 在网页上插入hCaptcha控件

1.1 首先在网页上引入hcaptcha脚本：

<scri src="https://js.hcaptcha.com/1/api.js" async defer></scri>

1.2 然后在欲展示验证码的位置，插入以下html

<diw class="h-captcha" data-sitekey="your_site_key"></diw>

（这里把script写作scri，div写作diw，防止被WAF拦截）

这里可以随意插入html，但必须满足以下三个要求：

1. 必须包含“h-captcha”的类名；
2. 必须包含“data-sitekey”的属性，属性值是你的site key；
3. html内部必须是空值（在这里，div块之间不能有内容）

做完以上两步后，hcaptcha脚本就会自动在你的网页中插入验证码控件了，无需其它操作。

1. 在后端引入hCaptcha验证

2.1 在用户提交请求时，携带Response

这需要修改提交请求的表单，因后端程序不同而异。

2.2 向hcaptcha服务器发起请求。

现在，后端需要打包Response和secret key，向hcaptcha服务器发起请求。

不同的后端语言，发起请求的方式不同，官方给出的例子是curl：

curl https://hcaptcha.com/siteverify \
  -X POST \
  -d "response=CLIENT-RESPONSE&secret=YOUR-SECRET"

hcaptcha的官方服务器返回的是json，取里面的“success”字段，如果是true，即为通过，反之不通过。

Python的例子如下（使用request）

def verify(secret, response) -> bool:
    # 用request发起post请求，表单数据里有secret和response两个字段
    r = requests.post('https://hcaptcha.com/siteverify', data={
        'secret': secret, 
        'response': response
    })
    
    # 从json里读取success字段
    valid = json.loads(r.text).get('success')
    if valid:
        return True
    else:
        return False

Rust语言的例子如下（使用Reqwest）

/// response: 前端提交的验证码
/// secret: secret key，需要保密
pub async fn verify_captcha(response: &str, secret: &str) -> Result<bool, std::io::Error> {
    use serde_derive::Deserialize;
    
    #[derive(Deserialize)]
    struct Response {
        success: bool,
        challenge_ts: String,
        hostname: String,
        error_codes: Option<Vec<String>>,
    }

    const URL: &str = "https://hcaptcha.com/siteverify";
    let form = [("response", response), ("secret", secret)];
    let client = reqwest::ClientBuilder::new().build()?;

    match client.post(URL).form(&form).send().await {
        Ok(resp) if resp.status().as_u16() == 200 => match resp.json::<Response>().await {
            Ok(r) if r.success => Ok(true),
            _ => Ok(false),
        },
        _ => Ok(false),
    }
}

在后端逻辑中加上上述的“verify”函数，就可以使用hcaptcha验证码了。

我觉得自焚这个问题争来争去，到底还是没跳出中共的舆论陷阱。

我并不是鼓励或者赞同自焚，但是在历史上，自焚作为一种最极端的抗议与表达诉求的方式，明明很正常好吧？60年代南越僧人释广德自焚抗议吴廷琰政府对佛教徒的打压。照片传出以后震动西方，间接导致吴廷琰政府垮台。

另一些自焚抗议的人例如西藏藏人，最近十年来一直有藏人用这种最痛苦的方式抗议中共对藏人的迫害。还有70年代的乌克兰人奥勒克萨（Oleksa Hirnyk），自焚抗议苏联当局对乌克兰文化的打压。近期的如2020年俄罗斯女记者伊琳娜，在俄罗斯政府门前自焚抗议当局迫害新闻自由，这个事件有摄像头全程录像，过于惨烈我就不放了。

再次声明我并不鼓励或者赞同自焚，只是需要指出以极端手段结束生命来抗议，从古至今一直存在，从历史上看这是很正常的现象。古罗马政治家卡托切腹，经过缓慢而痛苦的死亡表示对凯撒的抗议，日本古代也有类似的腹谏，武士切腹以死明志，表达对领主的抗议或挽回名誉。

把自焚和邪教挂钩本身就是一种宣传战，你无论承认或反驳，都中了宣传的套路。就算真的有人自焚，我认为这和藏人一样，只是一种极端的抗议而已，和所谓的蛊惑、洗脑并不挂钩。

最后说回自焚事件的真实性本身，共产党主动烧人或者法轮功“教唆”自焚的可能性都不大，毕竟法轮功教义禁止自杀。我认为这件事情小概率是法轮功教徒自发行为（类似藏人抗议），大概率是共产党方面作假。法轮功方面针对自焚事件提出了很多疑点，相对有理有据，如果这些疑点不能合理解释，我更倾向作假这种解释。

这些难民不是盲流，他们在战争爆发之前也有自己的生活。你看不上的难民，很多原来也是公司白领，学校老师，过着朝九晚五的小日子。他们都是有自己梦想的人，他们有的还想着努力工作，攒钱在基辅安家。

但是战争让他们无法生活。那些把孩子辛苦养大的父母，正期望给他找个好大学，但是陪伴孩子十几年，抵不过俄军的一颗子弹；那些努力工作的小白领，正欢天喜地的搬新家，就看着自己的房子在火箭弹前化为乌有。

这个女人几天前还做了美甲，和你的邻居、家人、朋友没有任何区别，几天之后就变成了街头的尸体。

所以这些过着平静生活的人必须要逃亡，就算抛下自己打理了几十年的家，也不得不做难民。

我真心觉得你们大国人讲话多积一点口德，不要看见难民两个字就一脸鄙弃，多想想如果自己换到这个位置会怎样？某大国真的就以后保证不出现这种事情？他们和你一样也是有自己生活的人，也有做人的尊严，不是养猪场一样的对待就能打发的。

当然有些大国人本来就非常热爱猪圈，觉得人就应该和猪一样管起来。某些大国人不仅认为自己是猪，还觉得全世界其他地方的人也不要做人，最好来和他们一起做猪，这样世界就完美了。

Cloudflare免费版提供不计上限的DDOS防护，几乎可以拦下100%的网络层DDOS攻击。然而，如果服务器的配置很差，那么即使是流量很小、不足以触发Cloudflare防护的HTTP DDOS攻击也可以使服务器宕机。

这里介绍一种防御HTTP DDOS攻击（也叫CC攻击）的方法，用Nginx的限速功能，拦截绕过Cloudflare的漏网之鱼。

Nginx使用漏桶算法限速，漏桶算法把传入请求看作往桶里注水，桶会以一定的速度往外漏水（放过合法请求），漏桶自身也有一定的容量，可以承受突发的注水（接受突发请求），如果桶满水就会溢出（拒绝超出限制的请求）。

Nginx使用漏桶算法限速用limit_req_zone和limit_req这两个指令。一个和cloudflare配合使用的例子如下：

http {

    limit_req_zone $http_cf_connecting_ip zone=my_limiter:20m rate=2r/s;

    server {

        limit_req zone=my_limiter burst=30;

    }
}

limit_req_zone指令的用途是分配内存，对每个来访问的IP，记录其一段时间内的访问次数，因此这个指令必须放在http块里。上面指令的意思是，设置一个新的限速器，命名为my_limiter，占用内存20MB，此限速器可接受的最大访问频率为每秒2次。

因为服务器套了cloudflare，所以nginx看到的是CF的IP，而不是用户的IP。cloudflare会把用户的IP放在cf_connecting_ip请求头里，可以用Nginx变量$http_cf_connecting_ip表示从http请求头中获取用户IP，对每个用户的IP进行限速。

注意这里的IP以文本形式记录，因此会浪费一些空间，不过20MB的内存足以支持数万的IP连接。

limit_req可以放在http、server、或location块里，表示指定该区域的可接受的突发请求速率。

nginx会把拦截的请求写入error.log，可以在日志看到nginx的拦截记录，被拦截的请求不会交给后端处理，而是返回503错误。

这样的配置足以防御一些小型的DOS攻击或者高频爬虫。

很多墙外匿名站出于安全的角度，使用CDN隐藏真实IP，不幸的是有很多方法可以绕过CDN。

IPv4的总数是有限的（42亿个），网络上有很多扫描器在一刻不停的扫描，一天就可以过一遍全网IP。如果网站没有做好防御，这些扫描器就会找到IP地址上面对应的网站。很多扫描器的数据甚至是公开可查的。

幸运的是，只要做足防御，就完全不用担心源站IP泄露。这里科普一下防止源站IP泄露的方法。

设置防火墙

cloudflare会提供回源IP的名单，见https://www.cloudflare.com/ips/。我们要做的就是把这些IP全部添加进防火墙白名单。

这样除了cloudflare，其它一切ip就都没法连接服务器的https端口了。

防火墙白名单的具体规则是：

1. 默认拒绝所有的入站IP。防火墙的拒绝模式有reject和drop两种，reject会明确返回一个拒绝信息，drop则直接丢弃入站包。我们要选deny而不是reject；
2. 允许cloudflare的IP地址，从443端口连接服务器；
3. 允许任意IP连接22端口，这是为了能SSH连上服务器。SSH加固是另外一个话题，这里暂且不提。

本文这里没有用防火墙限制出站连接，如果对安全有需求，也可以禁用所有的出站连接。通常而言，对入站规则做设置就足以防止IP扫描了。

我通常用的防火墙是nftables，在debian/ubuntu系统上，可以这样设置防火墙：

(1). 安装nftables

sudo apt install nftables

(2). 编辑nftables文件

sudo vim /etc/nftables.conf

然后写入如下的配置文件

flush ruleset

table inet firewall {
    chain inbound {
        type filter hook input priority 0; policy drop;
        ct state vmap { established : accept, related : accept, invalid : drop }
        iifname lo accept

        ip saddr {
            173.245.48.0/20,
            103.21.244.0/22,
            103.22.200.0/22,
            103.31.4.0/22,
            141.101.64.0/18,
            108.162.192.0/18,
            190.93.240.0/20,
            188.114.96.0/20,
            197.234.240.0/22,
            198.41.128.0/17,
            162.158.0.0/15,
            104.16.0.0/13,
            104.24.0.0/14,
            172.64.0.0/13,
            131.0.72.0/22
        } tcp dport { 443 } accept

        tcp dport 22 accept
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }
}

上面这个配置文件会：

• 默认drop所有入站包
• 默认drop所有转发包
• 默认接受所有出站包
• 接受所有来自cloudflare ip地址，向443端口建立的TCP连接
• 接受全网IP向22端口连接
• 允许本地环回上的连接（数据库和Apache等服务器需要）

(3). 最后保存配置并刷新

sudo nft -f /etc/nftables.conf

输入sudo nft list ruleset，如果显示上面的配置文件，就说明保存成功。

对nftables不熟的朋友，也可以用Ubuntu自带的ufw建立防火墙，安全性是一样的。

# 启用ufw
ufw enable

# 允许所有出站，禁止所有入站
ufw default allow outgoing 
ufw default deny incoming

# 允许22端口
ufw allow 22

# 允许cloudflare ip地址连接443
ufw allow from 173.245.48.0/20 to any port 443 proto tcp
ufw allow from 103.21.244.0/22 to any port 443 proto tcp

# （以下略）

打开cloudflare的客户端验证

按照上面的方法，就可以100%防止IP扫描。不过，黑客可以向cloudflare works上传脚本，利用cloudflare的IP地址去扫描。这种攻击形式很少见，不过，为了防止这种形式的探测，我们还要打开验证CF客户端证书。

具体而言，需要打开nginx配置里的以下选项：

ssl_verify_client on;
ssl_client_certificate /xxxxx/cloudflare_certificate.pem;

最后，需要让nginx拒绝无效请求，打开以下选项

ssl_reject_handshake on;

但是需要注意，最后这个指令只在1.19.4以上的nginx版本可用，你可能需要自己编译nginx。

其它注意事项

除了ip扫描，如果网站在配置CF前已经有了DNS记录，那么从这些DNS记录也可以匹配到源站IP。如果是全新的服务器，在配置完成之前，一定不要连上公网。