有的没的
发现我的xray部署到路由器上，无法通过公网ip:port的形式访问路由器转发的内网服务。
然而xray部署在内网服务器上转发出来，在访问公网ip:port就可以访问了。
经过一段研究，应该是snat相关的问题，只设了dnat但是没设snat。详见接下来连续的几个post
#network
然而xray部署在内网服务器上转发出来，在访问公网ip:port就可以访问了。
经过一段研究，应该是snat相关的问题，只设了dnat但是没设snat。详见接下来连续的几个post
#network
快速记忆几个NAT的区别
DNAT：改目标地址（Destination），实现端口转发
SNAT：改源地址（Source），让回包能正确返回
Masquerade：SNAT的自动版本，适合动态IP
#network
DNAT：改目标地址（Destination），实现端口转发
SNAT：改源地址（Source），让回包能正确返回
Masquerade：SNAT的自动版本，适合动态IP
#network
Since the last month I found the baidunetdisk mounted on alist has a significant speed drop, which is usually around 300Kbps.
This rate is useless for video streaming.. so my baidunetdisk svip wont make anysense if this situation goes on.
But sometimes I find that, try replaying videos multiple times successively will lead to a speed rising, which makes me think it's because alist connected to another cdn node which has no qos.
Afterwards, i started exploring this phenomenon.
—-
To begin with, I tried using the tempermonkey plugin to get the direct link which starts with "d.pcs.baidu.com". Then I tried resolve the domain using different DNSes and even found the HK cdn node of it. So I edited the hosts to it, but it's always with a low speed or sometimes leads to an error responded by the server. ps: not a cert error. so editing hosts is not a proper solution in 2025. Plus, i was thinking that the direct link may varies in its hostname too, a simple host file that doesnt support regex can't list all the variations of the CDN node hostname. So this is not a good orientation.
After reading the source code from openlist, i found the actual direct link is retrieved in the function of LinkOfficial. The hostname of the download link will be different depending on the location of the IP sending the request. So it’s totally not a DNS resolution deviation thing.
So I started observing the links alist was assgined, trying to figure out the QoSed cdn node sni, which is the root cause of the issue.
1. I set the proxy mode to 302 in alist so i can get the link easily.
2. try sending download request multiple times to capture all possible cdn SNIs. You can use curl parameter -L -v -i -A [ua] to see the redirected link.
Better do this both at night and day, and record the download speed for each of the SNIs. And compare them and find the best one. It’s actually pretty easy to find all possible allocated baiduCDN SNIs
3. After trying multiple times, i found my download request will be redirected to these nodes: that are not QoSed, and the QoSed one .
4. So how to avoid the QoSed node is the root issue. I thought a lot, including the idea to set up a clash rule, but i dont rly want to include the domestic traffics by mihomo core so i gave it up. But this one is probably the easiest solution to block all QoSed SNIs.
5. I later find that the download request will always be redirected to for overseas IPs, which is unlimited. So i think it is promising.
6. I found alist-proxy is the perfect companion to solve this. I reckon that a non-Qosed url could be retrieved by the alist on my VPS, then the download traffic is initiated via the alist-proxy deployed at my homelab.
7. It turned out to be working. Alist-proxy is then deployed on my armbian machine. Plus, AlistProxy will display the assigned CDN SNI in the console, so it’s pretty convenient to debug. Beware that the listening port should be accessible since this actually works like this: 1. send download request to overseas alist 2.alist 302 it to the alist-proxy at home 3. alist-proxy got the direct link and modify the UA and download 4. Respond to the user with the resulted data. So u could see that your player client has a working route to your alist proxy is the fundamental requirement.
PS: this combo is versatile. Even if the SNIs VPS retrieved is QoSed one day, you could always deploy alist anywhere a good sni may emerge. Like cmcc networks, or even edge environments. All are worth trying.
Todo: Researching on Quark that is QoSed pretty violently at night.
PS: clouddrive sucks. streaming experience is quite terrible and it takes longer to buffer. I dunno why tho . Removed already.
#network
This rate is useless for video streaming.. so my baidunetdisk svip wont make anysense if this situation goes on.
But sometimes I find that, try replaying videos multiple times successively will lead to a speed rising, which makes me think it's because alist connected to another cdn node which has no qos.
Afterwards, i started exploring this phenomenon.
—-
To begin with, I tried using the tempermonkey plugin to get the direct link which starts with "d.pcs.baidu.com". Then I tried resolve the domain using different DNSes and even found the HK cdn node of it. So I edited the hosts to it, but it's always with a low speed or sometimes leads to an error responded by the server. ps: not a cert error. so editing hosts is not a proper solution in 2025. Plus, i was thinking that the direct link may varies in its hostname too, a simple host file that doesnt support regex can't list all the variations of the CDN node hostname. So this is not a good orientation.
After reading the source code from openlist, i found the actual direct link is retrieved in the function of LinkOfficial. The hostname of the download link will be different depending on the location of the IP sending the request. So it’s totally not a DNS resolution deviation thing.
So I started observing the links alist was assgined, trying to figure out the QoSed cdn node sni, which is the root cause of the issue.
1. I set the proxy mode to 302 in alist so i can get the link easily.
2. try sending download request multiple times to capture all possible cdn SNIs. You can use curl parameter -L -v -i -A [ua] to see the redirected link.
Better do this both at night and day, and record the download speed for each of the SNIs. And compare them and find the best one. It’s actually pretty easy to find all possible allocated baiduCDN SNIs
3. After trying multiple times, i found my download request will be redirected to these nodes: that are not QoSed, and the QoSed one .
4. So how to avoid the QoSed node is the root issue. I thought a lot, including the idea to set up a clash rule, but i dont rly want to include the domestic traffics by mihomo core so i gave it up. But this one is probably the easiest solution to block all QoSed SNIs.
5. I later find that the download request will always be redirected to for overseas IPs, which is unlimited. So i think it is promising.
6. I found alist-proxy is the perfect companion to solve this. I reckon that a non-Qosed url could be retrieved by the alist on my VPS, then the download traffic is initiated via the alist-proxy deployed at my homelab.
7. It turned out to be working. Alist-proxy is then deployed on my armbian machine. Plus, AlistProxy will display the assigned CDN SNI in the console, so it’s pretty convenient to debug. Beware that the listening port should be accessible since this actually works like this: 1. send download request to overseas alist 2.alist 302 it to the alist-proxy at home 3. alist-proxy got the direct link and modify the UA and download 4. Respond to the user with the resulted data. So u could see that your player client has a working route to your alist proxy is the fundamental requirement.
PS: this combo is versatile. Even if the SNIs VPS retrieved is QoSed one day, you could always deploy alist anywhere a good sni may emerge. Like cmcc networks, or even edge environments. All are worth trying.
Todo: Researching on Quark that is QoSed pretty violently at night.
PS: clouddrive sucks. streaming experience is quite terrible and it takes longer to buffer. I dunno why tho . Removed already.
#network
GitHub
OpenList/drivers/baidu_netdisk/util.go at d465da43e3cb9f4ec1429398fd270036ea34bce5 · OpenListTeam/OpenList
A new AList Fork to Anti Trust Crisis. Contribute to OpenListTeam/OpenList development by creating an account on GitHub.
现在有一个问题就是在openclash绕过U D P了之后这种情况下DNS走代理的话到底管不管用
可以做一个小实验，走明文的DNS，加Proxy和不加Proxy看看是否会产生泄漏
只要不泄露的话那么就可以采用这种方法
#network
可以做一个小实验，走明文的DNS，加Proxy和不加Proxy看看是否会产生泄漏
只要不泄露的话那么就可以采用这种方法
#network
好文章！
写了clash的dns 污染问题，以及应该怎么配，做了很多实验
https://blog.echosec.top/p/dive-into-clash-dns/
顺便收藏 clash 和 shadowrocket 的配置手册：
https://wiki.metacubex.one/config/dns/#_1
以下这个Shadowrocket的配置手册直接宝藏！
https://lowertop.github.io/Shadowrocket/
—-
dns 配置总结
国外dns用 dot cf/Google➕remote（反正走 tcp，远方也能代理，也不依赖长连接）
国内dns用明文223、dnspod
节点解析用doh的223主备
#network
#network
写了clash的dns 污染问题，以及应该怎么配，做了很多实验
https://blog.echosec.top/p/dive-into-clash-dns/
顺便收藏 clash 和 shadowrocket 的配置手册：
https://wiki.metacubex.one/config/dns/#_1
以下这个Shadowrocket的配置手册直接宝藏！
https://lowertop.github.io/Shadowrocket/
—-
dns 配置总结
国外dns用 dot cf/Google➕remote（反正走 tcp，远方也能代理，也不依赖长连接）
国内dns用明文223、dnspod
节点解析用doh的223主备
#network
#network
Echosec @QIN2DIM
『Blog』Dive into Clash DNS
深入浅出地介绍 Clash DNS 的工作原理
shadowrocket配置文件语法详解
https://github.com/GMOogway/shadowrocket-rules/blob/master/docs/01.shadowrocket_configure.md
#network
https://github.com/GMOogway/shadowrocket-rules/blob/master/docs/01.shadowrocket_configure.md
#network
GitHub
shadowrocket-rules/docs/01.shadowrocket_configure.md at master · GMOogway/shadowrocket-rules
小火箭规则🚀，小火箭配置，shadowrocket规则，shadowrocket rules，最全面的直连（DIRECT）、代理（PROXY）、屏蔽（REJECT）规则，自动构建，每日更新 - GMOogway/shadowrocket-rules
使用以下命令，在路由器上查看内网设备的 eui64 ipv6。替换下面xx为实际mac：
#network
ip -6 neigh | grep -i "xx:xx:xx:xx:xx:xx" | awk '{print $1}' | grep -i ':ff:fe' | grep '^[23]'#network
现在我们的每一个设备都有公网地址了，但要想被外部访问，需要防火墙放行才行。
ipv6 就不需要像 ipv4 进行转发了，直接放行端口甚至 ip 就行。
如上图所示，进入「网络 - 防火墙 - 通信规则」点击下面的添加按钮：
【常规设置】
协议：按需选择，注意 ping 使用的是 ICMP 协议，不是 TCP/UDP。
源区域：wan
目标区域：lan（如果要访问路由器自己则选择「设备」）
目标端口：自行设置
操作：接受
【高级设置】
地址族限制：仅 IPv6
保存一下就好。
注意，这样配置防火墙实际上是允许以 IPv6 访问任意子网设备的指定端口。
如果希望只放行特定的目标设备，可以指定 IP 后缀。因为运营商分配给我们的前缀是动态变化的，所以不能直接指定 IP，而后缀无论是使用 DHCPv6 还是 SLAAC（使用 eui64），经过配置都可以确保不变。然后添加防火墙规则时填写「目标地址」为 ::aaaa:bbbb:cccc:dddd/-64，其中 -64 的意思是匹配从右往左的 64 位。若部分系统不支持这种缩写，可以回退到 IPv4 的掩码表示形式：::aaaa:bbbb:cccc:dddd/::ffff:ffff:ffff:ffff。
附录
常见前缀
240e::/20: 中国电信
2409:8000::/20: 中国移动
2408:8000::/20: 中国联通
2000::/3: 全局单播地址。也就是全球可路由的公网地址。上述三个都属于这个。
FE80::/10: 链路本地地址。
2002::/16: 仅供 6to4 隧道使用
特殊地址
:: - 相当于 0.0.0.0
::1/128 - 本地回环地址，相当于 127.0.0.1/32
在线小工具
#network
关于armbian （network manager）以 eui64 的形式获取 Ipv6
刚开始编辑 sysctl 很久发现 ipv6 还不是 eui64, 问了 llm 都没回答对。
查了一下，因为是 network manager接管了这一块，而不是内核管理，随意编辑 sysctl 没用。
查看Linux_ipv6_无状态_设置为_eui64_有状态ipv6更改后缀
—-节选—-
修改 ipv6 无状态地址的缺省模式 addr_gen_mode 为 eui64
检查系统是否有 nmcli 命令。如果没有。-->网络是由内核直接管理的修改方法
执行 nmcli net 检查 NetworkManager 是否启用。
如果返回 disabled 即没启用，-->网络由内核直接管理的修改方法
如果返回 enabled 即启用了。
执行 nmcli device 查看对应的网卡设备是否由 NetworkManager 管理。
显示绿色的 connected 就是由 NetworkManager 管理的。-->由 NetworkManager 管理的修改方法
显示灰色的 unmanaged 是 NetworkManager 没有管理的。-->网络由内核直接管理的修改方法
你也可以考虑，启用NetworkManager对此网卡的管理。 -->见文章后面的“让 NetworkManager 管理有线网卡”
—-
网络由 NetworkManager 管理的,修改eui64方法
Armbian或Debian系统，改缺省无状态ipv6 为 stable-privacy
看帮助 man NetworkManager.conf。
修改 cd /etc/NetworkManager/system-connections/ 目录中对应网卡的文件。比如,Armbian_ethernet文件
[ipv6]
- addr-gen-mode=stable-privacy
+ #addr-gen-mode=stable-privacy
+ addr-gen-mode=eui64
dns-search=
Armbian_ethernet 文件中包含interface-name=eth0 , 所以这个文件是设置有线网卡的。
如果要设置无线网卡为eui64，则去修改对应的包含interface-name=wlan0的配置文件。
对eui64地址，valid_flt 和 preferred_lft 缺省值的修改。debian系统。(未测试)。
看 man systemd.network 有提到 ValidLifetimeSec=,PreferredLifetimeSec=。
另外，sysctl -a| grep _lft 能看到，
net.ipv6.conf.all.temp_prefered_lft = 86400
net.ipv6.conf.all.temp_valid_lft = 604800
net.ipv6.conf.default.temp_prefered_lft = 86400
net.ipv6.conf.default.temp_valid_lft = 604800
但 eui64实际的 valid_lft 远小于 604800，prefered_lft 远大于 86400。
对比 eui64地址的 lft，和路由器上 ipv6-prefix的 lft 基本一样，只差几秒。(2023-10测)
可是，在路由上设置 IPv6 RA Settings -> RA Livetime 为 1800sec，对客户机eui64的两个 lft没影响。
CentOS 或 Debian 修改之后。 systemctl restart NetworkManager 重启服务,即可生效。
#network
刚开始编辑 sysctl 很久发现 ipv6 还不是 eui64, 问了 llm 都没回答对。
查了一下，因为是 network manager接管了这一块，而不是内核管理，随意编辑 sysctl 没用。
查看Linux_ipv6_无状态_设置为_eui64_有状态ipv6更改后缀
—-节选—-
修改 ipv6 无状态地址的缺省模式 addr_gen_mode 为 eui64
检查系统是否有 nmcli 命令。如果没有。-->网络是由内核直接管理的修改方法
执行 nmcli net 检查 NetworkManager 是否启用。
如果返回 disabled 即没启用，-->网络由内核直接管理的修改方法
如果返回 enabled 即启用了。
执行 nmcli device 查看对应的网卡设备是否由 NetworkManager 管理。
显示绿色的 connected 就是由 NetworkManager 管理的。-->由 NetworkManager 管理的修改方法
显示灰色的 unmanaged 是 NetworkManager 没有管理的。-->网络由内核直接管理的修改方法
你也可以考虑，启用NetworkManager对此网卡的管理。 -->见文章后面的“让 NetworkManager 管理有线网卡”
—-
网络由 NetworkManager 管理的,修改eui64方法
Armbian或Debian系统，改缺省无状态ipv6 为 stable-privacy
看帮助 man NetworkManager.conf。
修改 cd /etc/NetworkManager/system-connections/ 目录中对应网卡的文件。比如,Armbian_ethernet文件
[ipv6]
- addr-gen-mode=stable-privacy
+ #addr-gen-mode=stable-privacy
+ addr-gen-mode=eui64
dns-search=
Armbian_ethernet 文件中包含interface-name=eth0 , 所以这个文件是设置有线网卡的。
如果要设置无线网卡为eui64，则去修改对应的包含interface-name=wlan0的配置文件。
对eui64地址，valid_flt 和 preferred_lft 缺省值的修改。debian系统。(未测试)。
看 man systemd.network 有提到 ValidLifetimeSec=,PreferredLifetimeSec=。
另外，sysctl -a| grep _lft 能看到，
net.ipv6.conf.all.temp_prefered_lft = 86400
net.ipv6.conf.all.temp_valid_lft = 604800
net.ipv6.conf.default.temp_prefered_lft = 86400
net.ipv6.conf.default.temp_valid_lft = 604800
但 eui64实际的 valid_lft 远小于 604800，prefered_lft 远大于 86400。
对比 eui64地址的 lft，和路由器上 ipv6-prefix的 lft 基本一样，只差几秒。(2023-10测)
可是，在路由上设置 IPv6 RA Settings -> RA Livetime 为 1800sec，对客户机eui64的两个 lft没影响。
CentOS 或 Debian 修改之后。 systemctl restart NetworkManager 重启服务,即可生效。
#network
好文章！ 关于openwrt 的ipv6设置以及防火墙设置！
注意！！即使路由器已经设定eui64 分配，但是客户端有权决定启不启用 eui64。所以对于 linux 客户端，还需要进行配置。见下面几篇文章。
https://github.com/Aethersailor/Custom_OpenClash_Rules/wiki/OpenWrt-IPv6-%E8%AE%BE%E7%BD%AE%E6%96%B9%E6%A1%88
#network
注意！！即使路由器已经设定eui64 分配，但是客户端有权决定启不启用 eui64。所以对于 linux 客户端，还需要进行配置。见下面几篇文章。
https://github.com/Aethersailor/Custom_OpenClash_Rules/wiki/OpenWrt-IPv6-%E8%AE%BE%E7%BD%AE%E6%96%B9%E6%A1%88
#network
GitHub - DustinWin/ruleset_geodata: 定制适合 Clash、mihomo 和 sing-box 内核的 ruleset&geodata 文件
https://github.com/DustinWin/ruleset_geodata
#network
https://github.com/DustinWin/ruleset_geodata
#network
GitHub
GitHub - DustinWin/ruleset_geodata: 定制适合 Clash、mihomo 和 sing-box 内核的 ruleset&geodata 文件
定制适合 Clash、mihomo 和 sing-box 内核的 ruleset&geodata 文件 - DustinWin/ruleset_geodata
ax6600 libwrt集成的lucky和官方的luci-app-lucky不兼容。一般就不用去动这个luci-app-lucky. 更新的时候只动本体就行？
rax3000m上使用的官方三件套。luci-app-lucky i8n语言包 lucky。可以和官方github repo的无缝兼容升级
#network
rax3000m上使用的官方三件套。luci-app-lucky i8n语言包 lucky。可以和官方github repo的无缝兼容升级
#network
写成了第一个 stun cf 反代脚本
有一点：反代不能直接用 ip 回源，要用域名。要不就会报 direct access.
所以对于 stun，目前 ipv4 一个域名，v6 一个域名，xray 的 ip4p 透传一个域名。
这样正好脚本里面采用 ipv4 域名加上 ip4p 解析出来的端口来回源
—-
又补充了 302 版本。
发现 uptime kuma 支持 307，那就不走 cf 了，直接用 worker 解析 ip4p 后 307.（ai 推荐用 307）
都放在了 autoCPE repo 里
#network #programming
有一点：反代不能直接用 ip 回源，要用域名。要不就会报 direct access.
所以对于 stun，目前 ipv4 一个域名，v6 一个域名，xray 的 ip4p 透传一个域名。
这样正好脚本里面采用 ipv4 域名加上 ip4p 解析出来的端口来回源
—-
又补充了 302 版本。
发现 uptime kuma 支持 307，那就不走 cf 了，直接用 worker 解析 ip4p 后 307.（ai 推荐用 307）
都放在了 autoCPE repo 里
#network #programming
[标题]联通云盘500g免流包免费领(阅926)
[时间]2025-08-23 10:34获赏666
论坛里还有30帮开的业务我也是没想到。。。。
联通号码都能开，目前看上去没有加限制，如果开不了就去联通云盘app领个免费会员就能开。
https://panservice.mail.wo.cn/h5/activitymobile/freedatapkg?touchpoint=300300010035&clientType=iOS&appVersionCode=5.0.4&clientid=1001000035
#network
[时间]2025-08-23 10:34获赏666
论坛里还有30帮开的业务我也是没想到。。。。
联通号码都能开，目前看上去没有加限制，如果开不了就去联通云盘app领个免费会员就能开。
https://panservice.mail.wo.cn/h5/activitymobile/freedatapkg?touchpoint=300300010035&clientType=iOS&appVersionCode=5.0.4&clientid=1001000035
#network
