现在用 cursor 的视频很多，但很多都是解决从 0 到 1 的问题，其实这个除了原型阶段其它时候更多需要在已有代码上做修改，楼主能不能推荐一下你认为比较有深度的 cursor 使用视频

我个人的理解：cursor 相比 VSCODE+各种插件的优势在于 cursor 能把项目的所有文件作为上下文，在 cursor 里可以增加或减少上下文，但是 vscode 的插件好像都只能用当前的文件，如果我的需求写在 md 文件或其它文件就不行。我个人认为这是 cursor 最大的优点

个人理解，错误的观点请指正

我每次用 v2ray 一键脚本搭建的网站都秒封 ip ，还不是封端口，所以后来我对 xray 工程都有点心怀芥蒂。不过很有可能是我偷懒，不该使用一键脚本，因为它这个配置的确有点复杂

不过我刚才认真看了看 XHTTP 的介绍，对于那个上下行分离，而且可以用 2 台 VPS ，一台上行 IPV4 TCP ，一台下行 IPV6 UDP 的思路还是很佩服的，而且他还实现了(我没用过，只根据文字判断)，这也算是一种逆天设计了

@darkgeek 我 CPU 和内存的负载都不大，而且 10 个有 9 个都是坏的有线网口，一定是质量问题

@Ashe007 因为我早已掌握透明代理技术，我就没有找 K8S 镜像仓库等一系列所需仓库的镜像，我想大致找不完整

透明代理不是在服务器上实现科学上网，而必须在服务器所连接的路由器上实现。了解一下 openwrt https://openwrt.org/ ，都是基于这个操作系统

二者的区别在于，一般的科学上网需要安装客户端，这个客户端会开通一个端口，每个程序都需要通过这个代理端口才能访问，但是这种做法局限太大，一是本地 Dns 查询需要另想办法，二是每个服务器的每个应用程序都需要配置，配置起来太麻烦，如果还考虑容器运行的需求则实际不可能采用这种办法

所以只能在网络层解决问题，让每台服务器连接到路由器后，统一在路由器上做路由控制，这个就要借助 iptables 或者 nftables 的功能了，这也是 K8S 中 service 这种资源干的事情，所以你迟早要懂

相关知识不敢多说，你 google 一下 透明代理 openwrt dnsmasq iptables 等关键词

还有楼上说的网络问题的确很重要，但是如果你要是没有能力在路由器上实现透明代理，那就也不用研究 K8S 了，因为 service 这种资源的本质就是一堆 rule ，你搞不定透明代理和科学上网，就肯定懂不了 K8S 的 servce 是咋回事

关于学习 K8S ，我还是认为通过官方文档学习比较靠谱，因为这个东西还在发展，附着在它身上的其它工具可能活不了那么久，或者慢慢就不兼容了，所以泼一下楼上很多人的凉水，知识应该从源头学习，不要学习被别人转换或理解过的笔记或者 blog ，因为有些内容可能被扭曲或丢失

搭建环境也是，还是推荐用 kubeadm ，其它工具会更方便，但是只有 hard 模式才能让你理解更多，计算机就是实践性科学，你初学时不栽跟头，以后栽跟头成本更高

至于 K3S 我不了解，但线下与人讨论时别人说这个 bug 很多，我自己在搭建 K8S 集群发现也存在很多文档上没有写，自己实践做时才出现的问题，所以虽然我搭建 K8S 的环境是 ARM 的，但我也没有研究 K3S

我是自己在类似树莓派的国产开发板上搭建 K8S 集群，可以看看我这个帖子

草根云，每个云原生工程师都值得拥有 https://www.v2ex.com/t/1003629

不过 orangepi 3B 在运行 2 年后，10 个板子有 9 个的有线网口都坏了，所以这个质量不怎么样，我现在用了其它开发板，运行时也从 docker 换成了 runc ，操作系统还要自己编译，等我用一段时间后再写篇实践过程文档

包括容器运行时接口 CNI 标准 此处应该是 CRI 标准

kubernetes 的整体架构，运作流程

我的理解，K8S 整体是一个分布式的高可用架构，运行这个架构之上的应用不需要应用本身具有高可用的特点(降低应用开发者的门槛)，而可以借助架构的能力让应用高可用。详细的理解建议看周志明的《凤凰架构》 https://icyfenix.cn/ 建议看电子版，因为链接也是需要看的，不要急，书的知识量很大，我花了 9 个月才读完，很多内容都需要实践。当然读后为了感谢作者买了纸质版。

为什么它需要 docker 容器，而后最新版本又不需要 docker 容器呢

当多个应用程序在操作系统上运行时，操作系统有两个基本问题要解决，共享和隔离，共享是为了降低成本、解决应用之间的通信等问题，隔离是安全、避免干扰和解决雪花崩溃问题，容器这种技术很好地解决了这两个问题，docker 生逢其实，刚好撞上了微服务的大风口，但是输掉了与 google 的容器编排战争，输给了 K8S 容器编排技术，然后 Google 所在 CNCF 又搞了一系列标准，包括容器运行时接口 CNI 标准，而 docker 嘴硬不遵从该标准，所以有 cri-o\containerd runc 其它遵循 CRI 的容器运行时技术更普遍受欢迎。其实 docker 配合 cri-docker 也可以用 https://github.com/Mirantis/cri-dockerd

草根云，每个云原生工程师都值得拥有 https://www.v2ex.com/t/1003629

@Serino 谢谢，我已经采购思源了，而且把印象笔记也都迁移到思源笔记上，还自己写了一个小工具

我是怎么一天之内将接近八千条图文笔记从印象笔记迁移思源的
https://ld246.com/article/1728710707910

迁移以后其它的还好，但是最大的问题就是原先我自己在印象笔记中代码格式写的内容，转换后换行符都丢了，反倒是用纯文本写的代码的换行符还在

@Serino 我的需求和你是一样的

1 、能抓取微信和网页的内容的插件
2 、能自己编辑
3 、最好能使用私有的存储，不管是 S3 还是用 NAS.

我看见有人说笔记的功能是"编辑+同步"，我觉得不全对，我的需求是“抓取+编辑+同步”，因为学习的过程是研究别人的内容+自己的思考，所以需要先抓取别人的，然后加上自己的实践和理解，全部重写或 COPY 实际很不方便

请问你现在还是用思源这种商业产品吗？有没有私有化部署的替代方案？

@Jinnrry 转发规则主要体现在这两个 chain 上

Chain PREROUTING (policy ACCEPT 7861 packets, 601K bytes)
pkts bytes target prot opt in out source destination
3187 191K SS_SPEC_WAN_AC tcp -- br-lan * 0.0.0.0/0 0.0.0.0/0 /* _SS_SPEC_RULE_ */
693K 54M prerouting_rule all -- * * 0.0.0.0/0 0.0.0.0/0 /* !fw3: Custom prerouting rule chain */
692K 53M zone_lan_prerouting all -- br-lan * 0.0.0.0/0 0.0.0.0/0 /* !fw3 */
838 245K zone_wan_prerouting all -- pppoe-wan * 0.0.0.0/0 0.0.0.0/0 /* !fw3 */
0 0 zone_wan_prerouting all -- eth1 * 0.0.0.0/0 0.0.0.0/0 /* !fw3 */

Chain SS_SPEC_WAN_AC (2 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 match-set whitelist dst
0 0 SS_SPEC_WAN_FW all -- * * 0.0.0.0/0 0.0.0.0/0 match-set blacklist dst
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 match-set bplan src
0 0 SS_SPEC_WAN_FW all -- * * 0.0.0.0/0 0.0.0.0/0 match-set fplan src
75 4500 RETURN tcp -- * * 0.0.0.0/0 45.78.45.70 tcp dpt:!53
61 3680 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 match-set ss_spec_wan_ac dst
572 34320 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 match-set china dst
0 0 SS_SPEC_WAN_FW all -- * * 0.0.0.0/0 0.0.0.0/0 match-set gmlan src ! match-set china dst
3242 195K SS_SPEC_WAN_FW all -- * * 0.0.0.0/0 0.0.0.0/0

Chain SS_SPEC_WAN_FW (4 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 10.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 127.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 169.254.0.0/16
0 0 RETURN all -- * * 0.0.0.0/0 172.16.0.0/12
0 0 RETURN all -- * * 0.0.0.0/0 192.168.0.0/16
0 0 RETURN all -- * * 0.0.0.0/0 224.0.0.0/4
0 0 RETURN all -- * * 0.0.0.0/0 240.0.0.0/4
3188 191K REDIRECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 22,53,587,465,995,993,143,80,443,853,9418 redir ports 1234

从 Chain PREROUTING -> Chain SS_SPEC_WAN_AC -> Chain SS_SPEC_WAN_FW

规则采用目标地址匹配，就是这行 rule
SS_SPEC_WAN_FW all -- * * 0.0.0.0/0 0.0.0.0/0 match-set blacklist dst

blacklist 应该是所有需要科学上网的域名返回的 ip 地址，所有流量包的目标地址只要存在于 blacklist ipset 中，就会进入 Chain SS_SPEC_WAN_AC

你可以用 ipset list blacklist 命令看一下哪些 ip 是目标 ip

而 Chain SS_SPEC_WAN_FW 的最后一行 rule
REDIRECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 22,53,587,465,995,993,143,80,443,853,9418 redir ports 1234

再排除了局域网 ip(172.16.0.0/12,192.168.0.0/16.....)后，剩下的都应该是需要科学上网的域名，且如果目标端口是 22,53,587,465,995,993,143,80,443,853,9418,就重定向到 1234 端口(如你所言，是 v2ray 的端口)

所以采用的是目标地址匹配的方法

不过我有点不明白，如果你的路由器使用 FW4 ，iptables 命令应该不能执行吧？如果 iptables 命令能执行成功，那就应该是 FW3 啊

@Jinnrry 如果策略是“非国内 ip 代理”，那么肯定有针对目标地址的转发规则，你现在找到这个是针对目标端口的转发，不是这个

你把 iptables -t nat -L -v -n 的结果全部贴出来看看

说错了

iptables -L 这个命令默认查询的是 filter 表，但一般在 nat 表，所以命令应该这么写

iptables -t nat -L -v -n

@Jinnrry 那就不用 ipv6

gost,v2ray ，现在能用的工具很多。gost 是肯定可以在 ARM 上用的，就是要路由器的内存大点

@Jinnrry iptables 的配置与具体的采用的科学上网的工具有关

比如你使用 gost 作为科学上网工具，在本地开了 18443 作为端口转发，那么整体配置思路如下

在 dnsmasq 中的配置
server=/docker.io/127.0.0.1#10053
nftset=/docker.io/4#inet#wgcross#crs_dst

以上配置的作用是将 docker.io 的域名交给 127.0.0.1#10053 这个域名解析服务器解析，返回的 ip 存到 nft table 名为 wgcross 的 ipset crs_dst 中

说明一下：因为我使用的 openwrt23.05 已经是 firewell 4 了，而 firewell 4 使用 nftables 代替了 iptables ，所以与你使用的 firewell 3 的配置参数不同，但是思路是一样的

然后我的 nftables 的配置中就有如下一项

nft add rule inet wgcross PREROUTING ip daddr @crs_dst meta l4proto {tcp,udp} redirect to :18443

这个命令在 nft table 名为 wgcross 中增加了一条规则，将目标地址在 ipset crs_dst 中的 tcp 和 udp 包都专发到本地的 18443 端口上

所以通过 server ，nftset(firewell 3 是 ipset)解决 DNS 域名污染并存储了对应域名的目标 ip ，再通过 iptables 实现了目标 ip 转发到指定端口

我记得 iptables -L 默认是 NAT 表，一般转发规则在 PREROUTING 表中，你可能对 iptables 的几个表的使用不理解，你看看我写的这篇文章 https://mp.weixin.qq.com/s?__biz=Mzg3OTYwMTE1NA==&mid=2247483967&idx=1&sn=ed36e7007329ad78cf55c91fbed7b0b8&chksm=cf00b152f877384447032ecb2f5500f902941980683977e2d301f6e581599509f20121161889&token=111951293&lang=zh_CN#rd
可能对你有所启发

@Jinnrry server 参数要配合 ipset 一起使用才能实现科学上网