2026-02-09 17:41:27
过去一年是 AI Coding 在整个业界爆发的一年，Claude Code、Codex、Cursor 等 AI 编码工具覆盖了海量的程序员甚至不少“麻瓜”也在积极尝试 “Vibe Coding”，过于一年善用此类工具的人产出已经得到了极其显著的提高。
对于居住在中国大陆的人来说，要想畅通无阻的使用这些海外的顶级 AI 工具通常会面临各种各样的问题。
本文会分享我过去几年在使用 AI 工具方面的一些心得体会。
中国大陆、香港、澳门这几个地区被大量主流 AI 厂商限制提供服务，也就说人家明确禁止这些地区的人使用，不给你提供服务。像 Anthropic CEO 甚至公开放话要 Ban 掉背后是由中国公司控股的马甲公司。
所以，需要先解决自己的网络环境和付款方式等。一般来说美区 Apple ID + 美区 Apple Gift Card 可以相对低成本，省心的解决支付问题。（谨慎在淘宝闲鱼购买礼品卡，容易秋后算账被封号）
网络方面，最好是通过 clash、sing-box、surge 之类的支持自定义代理规则的工具让海外 AI 相关的域名走单独的代理，最好是你自己独享的比较干净的 IP。可以在这里 https://ipinfo.io/ 查看 IP 质量。有时候你可以通过 surge 的链式代理让落地 IP 走自己私有的 VPS IP，这样既能保障访问速度又避免和其他人共用 IP。
由于 Anthropic 和 OpenAI 域名在国内可直连，在自己家的路由器和电脑 hosts 上最好将相关域名屏蔽掉，避免因为代理软件重启或者异常退出导致正在进行中的连接瞬间走了直连，容易被风控。
这里的框架是指 ClaudeCode、Codex、OpenCode 之类的 CLI 或者 App。
就目前而言，GPT Pro 和 Claude Fable 这类模型依旧是没有代替，所以推荐的方案是 Claude + ChatGPT 订阅双持，再配合 Grok 或者 OpenCode 可以用来日常相对简单的任务。
开源模型方面，GLM 5.2 以及 Kimi k2.6、k2.7-code 都是相对不错的模型，不过目前很多国内开源模型一大问题是很多都不支持多模态，也就是无法给它图片输入。在前端 UI 层面这点很重要。
在 TUI 方面，也就是直接在命令行终端使用的场景，Claude Code 是目前综合最好用功能最强大的，包括 Codex CLI 和它比起来都差了不少，其他的就 OpenCode Grok 之类的就更不用说了。
如果你用不惯 TUI，在 GUI 方面目前 Cursor 和 Codex Desktop 是相对最好用的。
如果只能选一个就选 Cursor。
这是一个很好的折中，不要完全敞开权限，也不要默认每次都手动审批。
这点 Claude Code 和 Codex 做的比较好。
codex 相比其他框架有个 sandbox 机制，默认很烦人，会导致很多跨目录场景被限制，最好把 sandbox 设置成 full-access, 审批模式改成 Auto (approval for me)
对于全局 AGENTS.md 应当尽可能保持轻量，随着模型进步，说多了反倒影响模型发挥。并且容易自相矛盾。每隔一段时间重新 Review 你的 AGENTS.md，并做一些删减。
千万不要看到一堆技能直接一键安装到全局，技能多了也会互相冲突，并且有些技能会过于刻板，反倒限制模型发挥。
典型的例子，superpowers 就是需要谨慎考虑一组 skills
此外，每次新增一个技能都要考虑和已有技能之间是否存在冲突和重叠的部分。
我自己会经常 review 哪些技能可以删掉，哪些可以合并。如果你用 codex 可以在网页端看到技能的使用数据统计。
每个模型都有自己独特的地方，甚至不可代替的地方。
grok 自带高性能的实时检索 x 内容，并且整体内容尺度比较宽松，不会动不动拒答或者教育你。
gemini pro 在语言文字方面独树一帜，有时候读它的文字你会心旷神怡。
gpt 5.x 的文字能力非常差，黑话之类的非常多，曾经的 4.5 模型在语言方面是 gpt 家族最顶级的，甚至比 gemini pro 都要好不少，可惜最近已经下架了。据说成本太高。gpt 在上下文自动压缩方面独树一帜，虽然只有 200多k上下文，但配合它的服务端自动上下文压缩，可以连续运行几十个小时。
glm 5.2 在中文方面表现相对不错，整体除了速度稍微慢点和没多模态，还是不错的。
单纯逻辑推理，fable 和 gpt pro 目前是最强的。gpt 5.5 次之。
工具调用方面，sonnet 5 和 opus 系列都是明显要比其他模型好的。
通过躬身入局，你才能感受的 AI 当前的能力和边界。才能感受到它对整个人类世界的冲击。进而引发你更多关于自己独特价值的思考。
对于可以自闭环验证的任务是最容易被 AI 代替的，例如编程就是典型的场景。很多知识类白领的工作会受到冲击。
不过，AI 并不能完全帮助一个初级、中级的人一下子变的突然生产力爆炸。反倒是实践经验越丰富，架构经验越资深的人可以更显著的发挥好 AI 的能力。原因很简单，当你不知道自己不知道什么的时候，很难让 AI 正确的触发特定回路。即-无法驾驭 AI
所以要区分 Demo 和真正生产级别的能力，AI 可以快速弄一个看似像那么一回事的东西，但没有靠谱的舵手，很难稳定走完整个航程。更别提持续迭代了。
要获得最佳阅读体验，请访问原文 https://baiyun.me/ai-coding-master
2026-01-15 23:01:08
传统的 IPTV 需要使用运营商提供的 IPTV Box 连接电视才能观看，这种方案有几个缺点：
如果你想解决这些问题。网络上通常有很多术语，令人眼花缭乱，例如 IPTV 组播转单播、IPTV 单线复用、光猫超级管理员密码之类的概念。
本文经过实际测试摸索，找到一条相对简单高效的方案，大概只需要10分钟时间即可配置完毕。
经常听到一种说法：“现在都没人看电视了”，在抖音之类的短视频大行其道，人手一个智能手机的现状下，确实，现在包括很多老年人在内一年都开不了几次电视。
那为什么要折腾开通 IPTV 呢？从我的角度来说主要有以下几点：
对我来说主要观看的是 CCTV 5、CCTV 16 这类体育频道，虽然有广告，但是相对来说明显画质和延迟要比国内流媒体平台好不少，并且不用每家都开会员。
相比腾讯优酷爱奇艺之类的体育会员动辄几十块一个月，IPTV 一个月 10 块钱，对于轻度用户来说性价比可以说很好了。
我的光猫是在安装宽带时就让电信工作人员设置了桥接模式加路由器拨号，除此以外没有改过网络接口相关设置。也就说你不需要超级管理员账密。
将光猫 ITV 口接一根网线连到电脑，在电脑网络设置里手动设置此连接的 IP（指定为 192.168.1.1xx）具体 IP 段一般和光猫背面展示的控制台地址一致。本文后面以此 IP 段示例。
网关指定为 192.168.1.1
然后使用 VLC 播放器播放组播地址，可以从以下项目找具体地址：
https://github.com/FHZDCJ/Zhejiang_Telecom_IPTV/blob/main/Zhejiang_Multicast/Zhejiang_Telecom_IPTV.m3u
格式：rtp://233.xxx.xxx.xxx:5140，如果可以正常播放组播源，则继续后面的步骤。
在执行此测试的时候建议关闭 Wi-Fi 和 surge 之类的工具。确保所有请求直接通过网线发给光猫的 ITV 口。
如果前面的测试通过，说明你当前的网络条件可以正常播放组播源信号。
接下来为了实现在局域网内任意设备观看 IPTV，需要将组播信号（通常是 rtp 协议）转为单播信号（http 协议）。
首先需要在局域网内正常部署 https://github.com/stackia/rtp2httpd 服务。
我是直接在 NAS 上通过 Docker Compose 部署的，配置如下：
services:
rtp2httpd:
image: ghcr.io/stackia/rtp2httpd:latest
container_name: rtp2httpd
network_mode: host
command: --noconfig --verbose 2 --listen 5140 --maxclients 20
待你可以正常访问 http://NAS-IP:5140/status 之后再进行下一步。
将光猫 ITV 口连接到路由器的第二个 WAN 口（第一个 WAN 口用于正常上网），这一步的主要目的是实现在正常上网的这个 LAN(局域网) 里面通过 HTTP 单播源观看 IPTV。
我用的是 Unifi 路由器，直接在控制台新建一个 WAN 口，关联刚才连接 ITV 口的端口，同时勾选 IGMP proxy 开关（这个很关键），选择静态 ip。
此时在 VLC 里打开 rtp2httpd 格式的单播信号源地址：
http://192.168.10.20:5140/rtp/239.xxx.xxx.xxx:5140
这里 192.168.10.20 是我的 NAS 地址，里面用 docker 部署了rtp2httpd（host 网络模式，默认绑定在 5140 端口），239.xxx.xxx.xxx 是具体 IPTV 频道的组播地址。
正常情况下这里就可以正常观看了。
最后，为了方便切换所有可观看的频道，可以将这里的 m3u 文件进行修改:
https://github.com/FHZDCJ/Zhejiang_Telecom_IPTV/blob/main/Zhejiang_Multicast/Zhejiang_Telecom_IPTV_ONLINE_LOGO.m3u
替换里面的链接为 rtp2httpd 格式，以下是替换后的示例：
#EXTM3U
#EXTINF:-1 tvg-id="CCTV1" tvg-name="CCTV1" group-title="央视",CCTV1综合
http://192.168.10.20:5140/rtp/233.xxx.xxx.xxx:5140
#EXTINF:-1 tvg-id="CCTV2" tvg-name="CCTV2" group-title="央视",CCTV2财经
http://192.168.10.20:5140/rtp/233.xxx.xxx.xxx:5140
将修改后的 m3u 文件导入到 APTV 之类的软件即可在 Apple TV、Mac、iPhone 等局域网设备观看 IPTV 频道。
对于大部分用户来说，如果组播信号用起来感觉没啥问题，就不推荐折腾单播信号了，毕竟首次设置和后续维护成本还是显著增加的。并且单播的延迟和性能在高峰期可能不如组播稳定，这是它们的技术原理决定的。不存在单播就一定优于组播。
组播最大的问题是如果配置不当，可能对局域网性能造成影响，例如在观看 IPTV 的时候会给局域网内所有设备端口进行 “泛洪” 发送无意义流量包。使用运营商提供的原始单播信号可以避免这个问题。
所谓原始单播信号是指直接在局域网任意设备上使用下面这种格式的 URL 即可观看 IPTV 频道：
rtsp://115.xxx.xxx.xxx/PLTV/88888913/224/3221228078/xxx.smil
对于杭州电信来说，想要访问运营商提供的单播信号源，需要通过和 IPTV 盒子一样的认证才可以。
杭州电信的 IPTV 盒子使用 IPoE 认证，打开 IPTV 盒子的网络设置可以发现，正常通过认证的情况下可以获取到 10 开头的 IP 地址和网关地址。
要想认证通过拿到合法的 IP 和网关信息，IPTV 盒子会作为一个 DHCP Client 向运营商发送 DHCP 报文，并在报文里携带两个关键信息：
IPoE (IP over Ethernet) 是一种直接在以太网（Ethernet）上承载 IP 数据的网络接入技术，它替代了传统的 PPPoE，通过 DHCP 动态获取 IP 地址并利用用户的物理信息（如 MAC 地址、VLAN ID）进行认证。
记下盒子上的 STBID，它就是 dhcp 报文里的 option 12（hostname）
示例值：00108325090207200000B1FDF1E258FD
这一步核心原理是抓取 IPTV 盒子开机后发送的 DHCP 报文，里面包含了盒子内部计算好的 vendorid。
抓包方式有很多种，简单的一种是直接将盒子用网线（交叉线）连接到电脑网口，电脑启动 Wireshark 捕获对应的网口，待盒子通电开机后，在 Wireshark 顶部搜索框输入 dhcp 过滤出所有 dhcp 报文。
找到对应报文找到并展开 Option: (60) Vendor class identifier，选中里面的 Vendor class identifier:，右键 copy as hex stream。
复制到的内容应当是这种格式：00001f39d35c06c5560f91e4f652a438f7bd9ad33a5972fb06e75f6f45cb4fdfb190045a51153196b05f5a7b5d5b6f699b5d5b4956975b4900000000300e89ed9c786007ee110
将其保存起来。
注意 DHCP 报文里的
Client MAC address要和 IPTV 盒子的 MAC 地址匹配，避免被电脑自己发出的报文干扰。
我的光猫 ITV 口和主路由 UDM Port 4 用网线连接。确保 Port 4 没被分配给 WAN 口。
id 设置为 100，命名为 IPTV, 避免和其他 vlan id 混淆：
给 UDM Port 4 绑定 VLAN 100：
我的 OpenWrt 是一个树莓派，我将其插入了客厅 USW 交换机的 Port 6，需要正确配置此端口：
Native VLAN：选择局域网主 VLAN
Tagged VLAN Management：custom
Tagged VLANs：选择前面新增的 VLAN 100
由于我家里的 UDM 路由器不支持设置 DHCP Client 的 hostname，所以找来找去还是找一台设备刷个 OpenWrt 最简单，我是找了家里吃灰的树莓派 4B 刷了最新稳定版 OpenWrt。
新增 一个 device，一个 interface：
vim /etc/config/network
config device
option type '8021q'
option ifname 'eth0'
option vid '100'
option name 'eth0.100'
config interface 'IPTV_WAN'
option proto 'dhcp'
option device 'eth0.100'
option metric '20'
option hostname '这里替换为前面拼接获取的hostname'
option macaddr '这里替换为iptv盒子的完整mac地址'
option sendopts '60:这里替换为前面抓包拿到的vendorid'
option defaultroute '0'
修改 lan 的 IP 地址：
vim /etc/config/network
将 interface 'lan' 改为静态 IP，指定正确的局域网 IP 和网关地址。
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '主路由器局域网IP地址（没被使用的）'
option netmask '255.255.255.0'
option ip6assign '60'
option gateway '主路由器网关地址'
option metric '20'
dhcp.sh 脚本vim /lib/netifd/proto/dhcp.sh
原版：会导致 DHCP 报文发送两个 option 60
proto_run_command "$config" udhcpc \
-p /var/run/udhcpc-$iface.pid \
-s /lib/netifd/dhcp.script \
-f -t 0 -i "$iface" \
${ipaddr:+-r $ipaddr} \
${hostname:+-x "hostname:$hostname"} \
${vendorid:+-V "$vendorid"} \
$clientid $defaultreqopts $broadcast $release $dhcpopts
修改后的版本：去除了 ${vendorid:+-V "$vendorid"} 这一行，增加了 -V '' \ 这行
proto_run_command "$config" udhcpc \
-p /var/run/udhcpc-$iface.pid \
-s /lib/netifd/dhcp.script \
-f -t 0 -i "$iface" \
${ipaddr:+-r ${ipaddr/\/*/}} \
${hostname:+-x "hostname:$hostname"} \
-V '' \
$clientid $defaultreqopts $broadcast $norelease $dhcpopts
如果要正常在局域网内访问单播地址，就需要将单播服务器的 IP 设置静态路由让其可以正常走 IPTV-WAN 出去，最终走到光猫 ITV 口。
用下面的脚本自动化获取 IPTV_WAN 口的 网关 地址，然后添加静态路由。
所以后续如果要添加新的静态路由，则需要编辑这个脚本里的 TARGET_NET 变量。
vim /etc/hotplug.d/iface/99-iptv-route
#!/bin/sh
set -u
[ "${INTERFACE:-}" = "IPTV_WAN" ] || exit 0
# 需要接管的单播 IP 段列表，将其替换为你自行抓包或者网络上找到的单播服务器IP
TARGET_NETS="
115.233.40.0/21
220.191.136.0/24
"
if [ "${ACTION:-}" = "ifup" ]; then
GW="$(ifstatus "$INTERFACE" | jsonfilter -e '@.inactive.route[@.target="0.0.0.0"].nexthop')"
if [ -z "$GW" ]; then
GW="$(ifstatus "$INTERFACE" | jsonfilter -e '@.data.dhcpserver')"
fi
if [ -n "$GW" ]; then
for NET in $TARGET_NETS; do
ip route replace "$NET" via "$GW" dev "$DEVICE"
logger -t IPTV_Route "Fixed: Replaced DHCP route for $NET via $GW"
done
else
logger -t IPTV_Route "Warning: Gateway not found, skip route fix"
fi
fi
为了确保在局域网内访问单播服务器时，流量走光猫的 ITV 口出去，需要在主路由上指定静态 IP 路由表，实现局域网内任意设备访问单播服务器 IP -> 静态路由到 OpenWrt -> 走 IPTV_WAN -> 光猫 ITV 口。一旦路由策略不对，导致流量走到常规公网口去了，就会出现单播无法访问的情况。
以上配置全部调整好之后，重启网络以验证。注意待你重启后电脑就无法直接通过网线访问 OpenWrt 了，因为前面已经改成了主路由局域网内的 static 静态 IP，你需要将 OpenWrt 设备接入到主路由的 lan 口或者下面的交换机上面。再用你指定的静态 IP 重新访问。
重启 OpenWrt 网络：
/etc/init.d/network restart
检查 IPTV_WAN 口是否正常获取到 IP：
ifstatus IPTV_WAN
正常情况应当获取到 10 开头的 ipv4 地址。
{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"dynamic": false,
"uptime": 67031,
"l3_device": "eth0.100",
"proto": "dhcp",
"device": "eth0.100",
"metric": 20,
"dns_metric": 0,
"delegation": true,
"ipv4-address": [
{
"address": "10.xxx.xxx.xxx",
"mask": 19
}
],
"dns-server": ["202.101.172.35", "202.101.172.46"],
"inactive": {
"route": [
{
"target": "0.0.0.0",
"mask": 0,
"nexthop": "10.xxx.xxx.1",
"source": "10.xxx.xxx.xxx/32"
}
]
},
"data": {
"dhcpserver": "10.xxx.xxx.1",
"leasetime": 2400
}
}
查看路由表是否生效：
ip route show
正常应当展示 /etc/hotplug.d/iface/99-iptv-route 脚本里指定的 IP 段，例如：
default via 192.168.10.1 dev br-lan metric 20
10.xxx.xxx.0/19 dev eth0.100 scope link metric 20
115.xxx.xxx.0/21 via 10.xxx.xxx.1 dev eth0.100
192.168.10.0/24 dev br-lan scope link metric 20
220.xxx.xxx.0/24 via 10.xxx.xxx.1 dev eth0.100
via 后面的 10.xxx.xxx.1 对应前面的 dhcpserver。
到这里正常情况下就大功告成了，可以在局域网内直接播放原始单播信号源。
在本文最前面我们没有使用 OpenWrt 也实现了正常播放组播信号，但是如果你已经有一台 OpenWrt 了，并且按照本文前面的内容进行了单播相关的设置，此时如果想同时支持组播，需要声明防火墙规则：
vi /etc/config/firewall
# --- IPTV 专用规则 ---
# 允许 UDP 组播视频流量进入，否则有信号无画面
config rule
option name 'Allow-IPTV-UDP'
option src 'wan'
option proto 'udp'
option dest_ip '224.0.0.0/4'
option target 'ACCEPT'
这个开关打开之后可能会引发一些额外的问题导致组播不可用或者卡顿。如果你没法解决则关掉最省事。
前面新建 WAN 口的时候我们开启了 IGMP Proxy，IPTV 信号成功进入了局域网（LAN），但此时如果你没有开启（或设备不支持）IGMP Snooping 就会发生“泛洪机制”。
IGMPProxy 的工作（L3）： 路由器把 WAN 口进来的 IPTV 视频流（比如 20Mbps 的高清流）转发到了 LAN 口。
交换机/LAN 的困惑（L2）： 到了局域网这一层，普通的二层交换机（或者路由器内部集成的交换芯片）如果不运行 IGMP Snooping，它就看不懂这个组播包。
默认行为： 对于看不懂的组播包，交换机的默认处理方式是把它当成广播（Broadcast）。它会想：“我不知道谁要这个包，为了保险起见，我发给所有人吧！”
下图是局域网开启 IGMP Snooping 之前和之后的对比，注意当我在 Mac Mini 上用 APTV 观看 IPTV 频道时，Apple TV 和 Flex 摄像头的端口流量。
可以清晰看到，虽然我只在 Mac Mini 上观看 IPTV，但是流量被发送到了其他局域网端口（这里是 Apple TV + Flex 摄像头）。这会造成带宽和性能浪费。
IGMP Snooping 就是用来解决这个问题的。
IGMP Snooping（窥探） 是二层交换机（或桥接接口）的一个功能。它的做法： “偷听” IGMP Proxy 和机顶盒之间的对话。效果：
它听到机顶盒说：“我要看 CCTV-5”。
它就在心里记下：“只有 LAN Port 2 需要这个组播流”。
当视频流过来时，它只把数据发给 Port 2，其他端口（Port 1, 3, Wi-Fi）完全收不到这个数据。有效避免了垃圾流量产生。
IGMP Snooping 开启后如果出现无法播放或者几分钟后自动断开无信号，可以尝试将 OpenWrt 内核以及对应的 interface（在本文就是 eth.100）降低到 IGMPv2 版本。
内核层面指定使用 IGMPv2：
cat <<EOF >> /etc/sysctl.conf
# 强制 IGMP v2
net.ipv4.conf.all.force_igmp_version=2
net.ipv4.conf.eth0.100.force_igmp_version=2
EOF
sysctl -p
interface 层面也需要指定 igmp 版本：
vim /etc/config/network
找到 interface IPTV_WAN，增加一行 `option igmpversion '2'：
config interface 'IPTV_WAN'
option proto 'dhcp'
option device 'eth0.100'
option metric '20'
option hostname 'xxxxxx'
option macaddr 'b1:xxxxxx'
option sendopts '60:xxxx'
option defaultroute '0'
option igmpversion '2'
在将 OpenWrt 作为旁路由接入我的主网交换机时，我单独划分了一个 VLAN 100 给 IPTV 流量使用。其他家庭设备不会接入这个 VLAN。
所以呢，我们完全可以在 VLAN 层面切断 “泛洪”，具体做法是，在其他连接局域网设备的 LAN 口上只接受一个 Main VLAN（家里主局域网），其他 VLAN 流量一律屏蔽即可解决 “泛洪” 的问题。
路由器到 AP 的端口设置为自定义 VLAN，以确保访客和 IoT 设备专用 Wi-Fi 可以正常使用。
其他连接 NAS 和局域网设备的端口一律设置为 Block all，这样 IPTV 的组播流量由于有 vlan id = 100 的标记，就不会影响到其他 VLAN 端口。
如果你只是组播转单播，这个架构就足够了
为了正常访问原始单播信号源，网络架构变的复杂了很多。下面这个架构同时支持原始单播和组播。
引入了 VLAN + Trunk：核心功能是通过单条网线/端口承载和传输来自多个 VLAN 的流量，通过 VLAN 标记（如802.1Q）区分不同 VLAN 的帧。
本文提供了两种方案，其中组播方案唯一的物理链路修改是光猫到路由器多了一根网线，客厅网口和 HDMI 线完全没有任何调整。
原始单播方案引入了额外的 OpenWrt 旁路由，整体网络配置方案较为复杂。
两种方案都可以实现在任意局域网设备例如 Apple TV 上观看 IPTV 节目，整体具备低延迟高稳定性。
折腾下来可以明显感知到 IPTV 在技术和电信资源层面明显是要比互联网流媒体占很大优势的，可惜在内容方面惨不忍睹，白白浪费这些电信资源。
踩坑需要耗费不少时间，如果此文对你有帮助，欢迎通过 /buyMeCoffee 请我喝杯咖啡。
感谢诸多在互联网上公开分享自己折腾历程的人。
要获得最佳阅读体验，请访问原文 https://baiyun.me/zhejiang-hangzhou-telecom-iptv
2025-06-04 23:13:13
近期因为 ChatGPT 降智问题，研究和体验了一波美国住宅IP代理。
第一次就开到了数据上及其干净的美国住宅 IP：
体验测试中...
最后，我认为 ChatGPT 这种根据 ip 偷偷降智的做法迟早会被市场教育，随着 AI 厂商竞争白热化，再搞这种小动作只会把用户拱手让给竞争对手，毕竟没有多少用户愿意花这么大代价去解决 ChatGPT 降智。除非 OpenAI 可以持续大幅领先对手。但，可能吗？能保持多久？
例如之前的 Claude 乱封号（刚续费会员）不退款，现在我都懒得看它一眼，Cursor 里我都优先选 Gemini 2.5 Pro。
要获得最佳阅读体验，请访问原文 https://baiyun.me/us-residential-ip-provider-comparison
2024-10-28 17:23:24
最近经常用 Node.js 写一些本地运行的脚本，需要安全的读取一些密钥密码之类的敏感信息，业界通常的做法是这样：
对于环境变量模式，一般情况需要在本地文件系统明文保存一些关键的密钥信息。本质上还是不太安全，例如你的钱包私钥明文放在本地文件系统，容易在未来的某一天爆雷，这种模式本质上不是无密码（Keyless）的。
对于 KMS 模式，需要依赖各种在线 KMS 服务，整体方案比较重，不太适合在本地电脑上轻量化使用。
本文使用 1Password 和官方提供的 CLI，在本地以无密码方式读取敏感信息。
brew install 1password-cli。具体可参考：https://developer.1password.com/docs/cli/get-started/
op account add
import { exec } from 'child_process'
import util from 'util'
const execPromise = util.promisify(exec)
// 使用内存缓存存储密钥
const secretCache = new Map<string, string>()
async function getSecretFromOnePassword(itemName: string, label: string): Promise<string> {
const cacheKey = `${itemName}:${label}`
// 检查缓存中是否已存在
const cachedSecret = secretCache.get(cacheKey)
if (cachedSecret) {
console.log('从缓存获取密钥')
return cachedSecret
}
console.log('从 1Password 获取密钥...')
try {
// 使用 op cli 获取 JSON 格式的 item 数据
/*
返回值示例：
{
"id": "xxx",
"section": {
"id": "add more"
},
"type": "CONCEALED",
"label": "secret-key",
"value": "xxx-value",
"reference": "op://xxx/secret-key"
}
*/
const command = `op item get "${itemName}" --fields label="${label}" --format json`
const { stdout } = await execPromise(command)
// 解析返回的 JSON 并返回值
const item = JSON.parse(stdout)
if (item && item.value) {
console.log('密钥获取成功')
// 存入缓存
secretCache.set(cacheKey, item.value)
return item.value
} else {
throw new Error(`label "${label}" not found in item "${itemName}"`)
}
} catch (error) {
console.error('从 1Password 获取密钥失败:', error)
throw error
}
}
在执行脚本时，系统会弹出 1Password 确认框，待你确认后，程序就可以获取到对应的密钥。
本文用 Node.js 示范了如何在本地以 Keyless 模式读取 1Password 里的密钥，实现原理本质上是包装调用了 1Password 官方的 CLI 程序，其他语言例如 Python、Java、Golang 之类的也可以很轻松的实现本文的逻辑。
这套方案特别适合加密货币钱包私钥或者 root 账号私钥之类敏感内容，通过本文的方案可以满足可信消费和安全存储。
要获得最佳阅读体验，请访问原文 https://baiyun.me/nodejs-keyless-read-1password-secrets
2024-10-28 16:59:03
本文主要聚焦在如何高效、优雅的观看你想看的任意 影视剧、体育、综艺等节目，尤其是一些国外的影视资源。只探讨技术，不提供任何无版权资源。
近些年海内外各大内容巨头均推出了自己的流媒体平台，对于用户来说面临一个问题：经常需要订阅很多家平台的会员才有可能看到自己想看的内容。
对于国内用户来说，还额外面临一些尴尬的问题，比如近些年广电总局的限外令，国外影视剧在国内以肉眼可见的速度减少，很多电影的出品方甚至会直接取消在国内院线上映，例如最近漫威的 雷神4，其他例如 花月杀手 这些均没有在国内院线上映。
即使好不容易在国内上映，很多情况也会面临删减、改台词等问题。
另外，国内主流的流媒体平台普遍还有几个大的现状：
国内主要是爱优腾三家，国外就非常多了。
| 平台 | 公司 | 简介 | 订阅用户数量 | 代表作 |
|---|---|---|---|---|
| Netflix | Netflix, Inc. | 全球最大的流媒体平台之一，以其丰富的原创内容和广泛的影视库而闻名。 | 超过2.3亿 | - 《怪奇物语》 (Stranger Things) - 《纸牌屋》 (House of Cards) - 《王冠》 (The Crown) |
| Amazon Prime Video | Amazon.com, Inc. | 提供广泛的电影和电视剧集，并且拥有不少高质量的原创内容。 | 超过2亿 | - 《指环王：力量之戒》 - 《了不起的麦瑟尔夫人》 (The Marvelous Mrs. Maisel) |
| Disney+ | The Walt Disney Company | 提供迪士尼、皮克斯、漫威、星球大战和国家地理的内容。 | 超过1.6亿 | - 《曼达洛人》 (The Mandalorian) - 《旺达幻视》 (WandaVision) - 《洛基》 (Loki) |
| HBO Max | Warner Bros. Discovery | 提供HBO经典剧集以及Warner Bros.的电影和原创内容。 | 超过7700万 | - 《权力的游戏》 (Game of Thrones) - 《切尔诺贝利》 (Chernobyl) |
| Hulu | The Walt Disney Company (majority stake) & Comcast (minority stake) | 提供丰富的电视剧集、电影和原创内容，主要面向美国市场。 | 超过4800万 | - 《使女的故事》 (The Handmaid's Tale) |
| Paramount+ | Paramount Global | 提供派拉蒙电影公司、CBS、MTV、Nickelodeon等品牌的内容。 | 超过4600万 | - 《星际迷航：发现号》 (Star Trek: Discovery) - 《黄石》 (Yellowstone) - 《好妻子》 (The Good Wife) |
| Apple TV+ | Apple Inc. | 苹果公司推出的流媒体平台，专注于高质量的原创内容，默认支持双杜比。 | 超过4000万 | - 《基地》 - 《人生切割术》 |
除了耳熟能详的 分辨率和帧率。真正显著影响视频质量的主要包括以下几点：
码率（Bitrate）：码率是每秒传输的数据量，通常用kbps（千比特每秒）或Mbps（兆比特每秒）表示。码率越高，视频质量越好，但文件大小也会增大。常见的码率有2500kbps、5000kbps等。
动态范围（Dynamic Range）：动态范围指视频中最亮和最暗部分的差异。高动态范围（HDR）视频能显示更多的亮部和暗部细节。
通俗的说，就是该亮的时候非常亮，例如聚光灯和日光、该暗的时候非常暗。同时确保细节依旧显示清晰。
业界主流的 HDR 格式：
音频格式：好的音频质量可以确保你听到更多细节，更加沉浸。
目前业界主流的高质量音频格式：
如果一些内容刚好这些流媒体平台都没有，这时候就有很多用户会使用 Bittorrent 协议以 p2p 的形式分享资源。
目前 BT 协议产生的流量依旧在全球流量占比中有接近 3% 的比例，比 Google 的流量还要高。
BT 协议是任何人都可以随时加入和离开的，它有一些缺点：
所以，PT 诞生了，PT（Private Torrent） 本质上还是 BT，只不过它的 Tracker 是私有的，只有白名单用户可以连接到这个 Tracker 进而下载内容。如果用户只下载不上传，或者上传比例太低，账号就会自动被 ban，这样确保了 PT 的用户体验在大部分情况下比 BT 好很多。
内容获取流程：
很多片源都会自带中文字幕，对于一些新的资源没有带字幕的，可以去 subhd 之类的字幕分享网站下载。
推荐方案是用 NAS，它相当于一台 24 小时开机、体积小巧、低功耗的电脑，厂商在设计上特地为内容存储做了优化，用户买回来插上硬盘就可以开箱即用。
大部分 NAS 上面都可以运行 Docker 容器，基于这个可以跑不少服务，且长期稳定运行。
NAS 品牌：群晖、威联通、极空间、绿联。对于喜欢折腾的用户来说推荐前两者，小白用户推荐后两者。
内容整理是指：自动从内容库识别这部影片的元信息（剧名、海报、剧照、卡司、分集信息）
Infuse 这款软件可以很高效实现内容整理、跨设备云端同步观看进度。以及正确播放几乎所有格式的视频，包括杜比视界。
Apple TV
Mac
iPhone
基于这套工作流可以让我们的观影体验变得纯净且高质量。
声音对于观影体验是至关重要的，相比于获得优质的视频画面，想要获得一个好的声音效果是更复杂的。
通常，优质的音响系统会让你感受到身临其境的沉浸感。相反，如果你能明显地感觉到声音来自某个特定方向，那就意味着声场质量很差。另外，一个常见的误解是声音并非越大越好，好声音的关键在于营造身临其境的空间感，同时保持扎实和清晰的层次。
选购音响系统首先要关注的是声道，不同声道的体验从普通到优秀排名如下：
这里小数点左边的数字表示音响数量，右边的 .1 表示一个独立的低音音响。例如 5.1 环绕声至少需要 5 个音响 + 一个独立的低音音响，前面放置三个作为左中右三个声道，后面放置两个作为后置的左右声道。
传统音响系统对于普通人的复杂之处在于：搞定复杂的布线、找到合适的摆放位置、了解不同房间布局对于声音的影响、了解声音校准，光搞清楚这些概念大部分人可能就要放弃了。
所以对于大多数人我的推荐有以下几种方案：
以上几种方案都通过无线技术大幅简化了布线和音响摆放位置的问题，且都自带校准功能（HomePod 是全自动的， Sony 需要在 App 里手动触发一次）。
在有选择的情况下，始终优先选择用多个分体音响组多声道，而不是用单个回音壁代替。
关于 HomePod 组立体声和传统 5.1 音响系统的效果对比可以查看这个视频：https://www.youtube.com/watch?v=DPZ11P6ojpE
要获得最佳阅读体验，请访问原文 https://baiyun.me/efficient-elegant-movie-watching-guide
2023-09-27 13:23:33
要获得良好的网络冲浪体验，DNS 设置是至关重要的。本文主要介绍如何使用 Surge 来提高 DNS 隐私和安全性，特别是在复杂的网络环境下，并分享一些经验，其中的原理也可以应用到诸如 Clash、Shadowrocket、Quantumult X 之类的软件。
Host 配置决定了你访问一个域名时 surge 如何解析这个域名的 DNS 记录，想获得高效安全的 DNS 解析体验，首先需要先根据你所处的网络环境配置合适的 Host 规则，先看一个配置示例：
[Host]
local.example.net = 127.0.0.1
local.xxx.net = 1.1.1.1
*xxxx-inc.com = server:system
*example*.com = server:system
*.* = server:https://223.6.6.6/dns-query
各种规则可以总结归类为三个梯队，优先级从上到下：
需要注意的是，如果遇到配置了 /etc/hosts 不生效，可以检查对应域名是否在 surge 配置里指定了其他服务器解析，有时候会导致冲突。解决方案：
http_proxy 之类的变量，执行 curl 的时候需要指定 --noproxy '*' 参数避免将请求发送给 Surge希望后续 surge 能优化这个点，提供更直观的配置。
对于希望走代理的请求，应该尽量避免它们在本地触发 DNS 解析，最好将你常用的需要代理的网站加到 surge 的规则列表中，例如：
[Rule]
DOMAIN-SUFFIX,google.com,📡 Proxy
DOMAIN-SUFFIX,x.com,📡 Proxy
如果你有大量域名需要代理，可以使用 Surge 提供的 rule-set 或者 domain-set 将这些规则和域名维护到单独的文件中，通过 URL 来引用和自动更新，例如：
# 自定义代理域名
RULE-SET,https://ruleset.example.com/proxy.txt,📡 Proxy
# GitHub 项目维护的代理域名
DOMAIN-SET,https://cdn.jsdelivr.net/gh/Loyalsoldier/surge-rules@release/proxy.txt,📡 Proxy
按照上述设置后，访问这些域名将不会在本地触发 DNS 解析，请求会直接发送到代理服务器，由它负责 DNS 解析，这样既可以提升隐私也可以获得更好的 DNS 解析结果。
好的 surge 配置应该尽量避免在前面的规则触发 DNS 解析，将需要触发 DNS 的规则尽量放置的末尾，下面是一个示例：
DOMAIN-SUFFIX,github.com,📡 Proxy
PROCESS-NAME,go-ipfs*,📡 Proxy
USER-AGENT,Figma,📡 Proxy
IP-CIDR,66.197.128.0/17,📡 Proxy,no-resolve
IP-CIDR,23.246.0.0/12,DIRECT
RULE-SET,LAN,DIRECT
GEOIP,CN,DIRECT
很多大型企业内部都有自己研发的 VPN 客户端（基于 TUN 模式），当你在公司外通过企业 VPN 访问内部域名通常需要特殊设定优化才能避免和 Surge 冲突。
本文接下来使用 10.x.x.x 作为企业内网 DNS IP 示例。
[General]
# 10.x.x.x 换成企业内网的固定 DNS 服务器（如果有的话）用于兜底
dns-server = system, 10.x.x.x
# 企业内部域名确保返回真实的 IP，这样才能被企业 VPN 的 TUN 路由表匹配到。
always-real-ip = %INSERT% *.your-corp.com
[Host]
# 将内网 DNS 管理的 zone 直接指定用内网 DNS 服务器解析
*your-corp.com = server:10.x.x.x
注意：尽量避免使用 surge 的 tun-excluded-routes 配置，如果你把公司内网IP段加入到这个配置，有可能引发和企业 VPN 的冲突或者各种兼容性问题。
例如 10.x.x.x 是你的企业内网 DNS IP，如果你将其加到 surge 的 tun-excluded-routes 配置里：
tun-excluded-routes = 10.x.x.x/32
重启 surge 后，查看路由表就会发现这个 IP 被 surge 又插入了一遍，你再 ping 这个 IP 就发现 ping 不通了（即使开了企业 VPN），因为此时它是走 192.168.10.1 这个家庭网关出口的自然访问不通了。
netstat -rn -f inet | grep 10.x
10.x.x.x 192.168.10.1 UGHS en0
10.x.x.x/32 10.2.x.x UGSc utun5
下面是一些辅助命令，如果配置过程遇到问题可以结合这些命令排查。
确定内网 DNS 服务器，可以使用下面的命令：（先关闭 surge 增强模式。）
scutil --dns
DNS configuration (for scoped queries)
resolver #1
search domain[0] : router.home
nameserver[0] : 10.x.x.x
if_index : 15 (en0)
flags : Scoped, Request A records
reach : 0x00020002 (Reachable,Directly Reachable Address)
resolver #2
nameserver[0] : 198.18.0.2
if_index : 38 (utun4)
flags : Scoped, Request A records
reach : 0x00000002 (Reachable)
找到上面 nameserver[0] 后面的 IP，用 dig 测试能否解析内网域名：
dig your-corp.com @10.x.x.x
找到可以解析出正确 IP 的那个 namesever 就是内网 DNS 服务器。当然一般内网都有固定的 IP 段，可以辅助判断。
开启企业 VPN 之后可以通过以下命令查看哪些 IP 段会走企业 VPN 出口：
netstat -rn -f inet
下面示例中，10.2.x.x 就是企业VPN的网关地址，10.x.x.x/32，9.x.x.x/32 这些 IP 段是企业内网IP。
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default link#38 UCSg utun4
default 192.168.10.1 UGScIg en0
8.x.x.x/28 10.2.x.x UGSc utun5
9.x.x.x/32 10.2.x.x UGSc utun5
10.x.x.x/32 10.2.x.x UGSc utun5
查看所有的 TUN 设备：
ifconfig | grep -B3 -A5 utun
要获得最佳阅读体验，请访问原文 https://baiyun.me/surge-dns-optimization-guide