有的没的
GitHub - router-for-me/CLIProxyAPI: Wrap Gemini CLI, ChatGPT Codex, Claude Code, Qwen Code as an OpenAI/Gemini/Claude/Codex compatible API service, allowing you to enjoy the free Gemini 2.5 Pro, GPT 5, Claude, Qwen model through API
https://github.com/router-for-me/CLIProxyAPI
https://github.com/router-for-me/CLIProxyAPI
发现我的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.
