[{"content":"","date":"2026-06-10","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"2026-06-10","externalUrl":null,"permalink":"/categories/logs/","section":"Categories","summary":"","title":"Logs","type":"categories"},{"content":"","date":"2026-06-10","externalUrl":null,"permalink":"/logs/","section":"Logs","summary":"","title":"Logs","type":"logs"},{"content":"","date":"2026-06-10","externalUrl":null,"permalink":"/","section":"Pyaxy的博客","summary":"","title":"Pyaxy的博客","type":"page"},{"content":" 写在前面 # 这篇文章并没有评价某一段关系或者审判某个人的意思，我更想记录的是在我旁观了我朋友和他女朋友吵架并闹到分手的过程中，我观察到了我朋友的一种行为模式：\n一个人可以不断说出“正确的话”，不断宣布自己“懂了”，“成长了”，“成熟了”，但是如果底层的结算目标没有改变，那么所谓的感悟只是进行了语言层面上的更新，而不是系统层面的升级。\n事件背景：一次次不断重复的“顿悟” # 我的朋友在他的亲密关系中不断感受到痛苦，他认为自己已经为她付出的够多了，为什么没有得到相应的回报。\n后来，我了解到，他的付出不是纯粹的为了让对方开心，而是带着一种隐性的回报期待：我这样对你好，你也应该以某种方式回应我。当这种期待没有被满足时，付出就不再只是付出，而会变成关系里的压力。\n我向他说明了这点，他反复复盘，反复道歉，反复说自己“我懂了”。\n一开始，我也以为他真的明白了。\n但随着时间推移，我发现了一些现象：\n他对他女朋友道歉的内容永远是“我错了”“我不好”“我有罪”，他好像没有提到他对对方造成了什么困扰。 对方明确的表示不想和他说话，但是他依旧是“我错了”“我不好”“我有罪”。 我告诉他爱别人首先要爱自己，他告诉我“他懂了”。 一周后他也累了，他渐渐放宽了对对方的“情感轰炸”和“道歉”，发现了对方愿意跟他沟通了。 他顿悟了，他认为他的痛苦来源于他对对方的情感要求过高，并立志打算以后“不纠缠”和“爱自己”。 于是我开始怀疑了：他到底是真的改变了，还是换了一套听起来更正确的话术？\n“被通知”的礼物：付出为什么会变成压力 # 他维系爱情和友情的一大方式是送礼物。\n送礼物当然没有问题，但如果每次送礼都要提前通知、强调、制造期待，那么礼物就不但是礼物了。\n它会变成：\n我重视你的证明。 我们关系之间的凭证 我需要你立刻看见我对你的好 我希望你回应我的情绪账单 礼物还没收到手里，对方心里先开始承担心理压力了。\n这让我意识到，这并不只是他在亲密关系中的问题，而是一种更普遍的相处方式：他做很多事情并不是做完就结束，而是需要被看见、被回应、被确认。\n感悟表演：他把“说出来”当成”做到了“ # 他的一个明显特点是：只要有一点新的想法，就会立刻说出来，发给很多人，等待别人对他的感悟的回应。\n比如 “我懂了。”\n“我成熟了。”\n“我知道问题在哪了。”\n“我以后不会这样了。”\n“我要开始爱自己了。”\n这些话本身可能不假，但问题在于：他把说出这些话当初一种成长。\n他在刚开始的时候告诉我他对成熟的定义：\n出去和对象玩可以把事情安排的很妥当，让对方不用操心行程。 吃饭的时候汤洒到他对象衣服上可以让他对象别慌，他来解决这个事情。 遇到航班取消了，可以很好的安排行程，不慌不乱。 但是我认为真正的成熟应该是：\n情绪上来的时候，不再继续发信息量为0的长文。 被拒绝时，真的做到不打扰对方 道歉时，不再要求被伤害的人接受自己的愧疚。 说“爱自己”之后，即使没人看见，也正常过自己的生活 但在为看来，他更像是把感悟广播出去，然后通过外部反馈获得“我已经成长了”的确认。\n这也是为什么我后来对他的“新感悟”越来越不敏感，因为类似的话一周前也出现过，只是换了一个新的说法。\n这算一种感悟表演吧\n不是完全没有感悟，但是仅仅停留于语言层。\n“正确的话”服务错误的动机 # 他观察到对方在他停止轰炸后愿意沟通了，但与此同时他本打算过好自己的生活，于是他顿悟了：\n比如 “我发现爱自己可以让自己变得很有魅力”； “不要把太多情感寄托在别人身上” ； “我不会再纠缠了”； “我要开始提升自己了”； “我要给她单独的个人空间”\n最让我警觉的，就是他说了很多正确的话。\n这些话但看起来都挺对，但如果结合他的目的，它们的功能变了：\n“我爱自己”不是因为我本来就应该好好生活，而是因为我变好了，她可能会重新回来。 他把“我不寄托太多感情在她身上”当成工具，目的是为了更好的把情感寄托在她身上。 “我尊重她”不是因为她本来就应该被尊重，而是因为尊重她可以让我重新获得进入她生活的资格。 他发现了自己痛苦的原因了，他的改变是为了让自己没有那么痛苦，他给别人带来痛苦呢？ 于是，语言正确了，但结算对象没有改变。所谓“爱自己”“尊重她”“不纠缠”，仍然在围绕着同一个目的转：让她回来。\n当朋友成为他叙事里的工具 # 事情真正越界的地方，不在于他用正确的话把旧目的包装起来了，而是他把其他人放到了他的挽回计划里。\n他一边对他女朋友说：“xxx跟我一起来的上海，要不要一起见一面”。 他一边又对我这个朋友说：“我女朋友想要见你，想通过你了解我最近到底怎么想的，我这一辈子的幸福可就靠你了啊！”\n而我当时在干嘛：凌晨2点在别的城市陪他聊天，他让我早上8点坐飞机去上海。\n也就是说，他同时在向两边同时提供加工过的信息。\n这也是我后来真正生气的原因：不是因为他难过，不是因为他想挽回，而是因为他未经同意使用了别人的名字、身份和信誉。\n他擅自的把本该自己承担的后果，转移到了我的身上，让我觉得\n如果我拒绝去上海，就是我在毁掉他们两个的感情。\n他同样让我觉得\n如果我坚守了自己的底线，就是我对不起他。\n道歉为什么也会成为新的情绪负担 # 这里还有一种更隐蔽的消耗：他伤害了别人（无论是他女朋友还是我），然后来道歉，但道歉本身就是一种情绪。\n他擅长于发“我错了”“对不起”“我真的很后悔”“我对不起你”“我不好”。\n这些话看起来是在认错，但焦点仍然可能停留在他的愧疚、他的后悔、他的痛苦上。\n真正的道歉应该是：\n我看见了我对你造成了什么伤害。 我承认这是我做的不对。 我尽量去补偿对对方的损失。 我之后会用什么行为避免再次发生这样的事情。 而他：\n“我都已经向你道歉了，你还想怎么样呢？”\n被伤害的人，还得继续接着伤害者的愧疚。\n如果你回复他了，他会给你说“我错了”，如果你不理他，他会给你刷屏“我错了”\n这也是我后来理解为什么他女朋友要跟他闹矛盾了：原来最累的不是对方犯错，而是对方犯错之后，受伤的人还要承接他的崩溃、反思和道歉情绪，然后反过来哄他，这本来是不必要的消耗。\n我后来意识到，他的行为需要观众：\n送礼需要观众 顿悟需要观众 爱自己需要观众 不纠缠需要观众 痛苦需要观众 他的事情可以不做，但是不能没有被注意到。\n底层行为模式：高表达，低兑现 # 如果让我对他的行为做出总结，我会证明认为：\n把表达当成行动：说“我顿悟了”，好像就等于已经改变了。 被看见之后行动已经结算：别人听见了、回应了、认可了，这件事才算完成。 把关系当成自我确认系统：别人回应他，他才确认自己是好的、成熟的、有价值的。 用正确的话维护旧系统：话术升级了，但底层目的没有改变。 因此我想到一句话：\n语言更新了，但是系统没有升级。\n回到自己：把“分析了”当成“做到了” # 如果文章通篇讲他，那也没什么意思了，我从他身上也隐隐看到了自己的问题。\n他用表达代替行动。\n而我喜欢用分析代替行动。\n形式不同，风险相似。\n就像这篇文章一样，我确实做这么多分析会有一种“我已经进步”的感觉。\n还有一种“还好他有的问题我没有”的高高在上的视角。\n我曾经也一度“顿悟”，并雄心壮志的为自己规划了路线，可能我和他的区别就是我不会说出来给别人。\n但是我会仔细的制定计划，每天看着这份计划单就很满足，但是计划单只是计划单，我看着它，而不做任何事情。\n真正的升级永远在下一次运行的时候 # 真正的成长不是靠嘴说出来的，也不是靠分析和做计划就能得到的。\n而是在下一次同样的问题出现时，人的系统不会复现旧的bug。\n真正的升级，从来不是因为日志打印出来了就升级成功了。\n","date":"2026-06-10","externalUrl":null,"permalink":"/logs/language-updated-system-not-upgraded/","section":"Logs","summary":"我观察到的我朋友的一些行为习惯以及自己可能存在的问题","title":"朋友的语言更新了，系统并没有升级","type":"logs"},{"content":" 介绍 # 美国的电话卡，无需KYC，国内只能使用AT\u0026amp;T的网络，包含100分钟通话、100条短信、1G流量，都是国际范围内可用的，实测用来注册美区Google账号非常丝滑，即使弹出手机号验证也是可以通过的。\n操作环境 # 网络环境：挂的自建的美国节点。 操作系统：Windows 浏览器：Chrome正常访问网站 购买 # 在eBay上购买redpocket上2.5$/mo的套餐，发货方式选择eSIM，介绍上说有200兆高速流量，是指美国境内的流量，另外还有1G的全球漫游流量。 注意：\n收货地址填美国的免税州地址，不然会多出约2$的税 收到的电话区号是由收货地址的地区决定的。 购买5-15分钟后会收到一封邮件，里面有eSIM的Confirmation Code，用于激活eSIM。 激活 # 使用邮件里的激活网址，填入Confirmation Code和手机的IMEI号。\n注意 我使用的是iPhone SE3 美版，看网上说Redpocket卡对非原生的eSIM套卡检测非常严格，所以使用小白卡可能概率失败。\n使用Google登陆redpocket账号，这样你的redpocket的用户名就是你的邮箱，进去之后趁着还有登陆状态先改密码，不然后续app上的Google登陆有问题，只能使用账号密码登录。\n激活后邮箱会收到二维码，手机扫描二维码即可添加eSIM。\n关于Wi-Fi calling # 在我尝试开启Wi-Fi calling的时候，我试了3次：\n直接国内直连激活，失败，激活网址直接显示access deny。 换上了自建的美国节点，成功进去了网址，但是会显示无法激活Wi-Fi calling，试了几次都是这样。 尝试使用webshare的伪家宽激活，成功显示了网页，让填入e911地址，网上随便搜了一个地址填了进去，过了一会成功激活了。 维持Wi-Fi calling，我目前用的是美国节点维持，应该不需要家宽维持，我的家宽用的是socks5协议，本质上是不支持udp的，Wi-Fi calling的底层走的是udp维持的，不过由于各地网络环境不一致，请自行尝试直连是否可以维持。 该卡潜在的风险 # 手机号可能是回收过的，我激活收到的手机号的tg已经被封了。可能区号在免税州的号段已经被薅过一遍了，填写非免税州的地址可能会好一些。 不确定ebay上的30$/年的套餐是否会一直存在，如果下架了保号费用就高了。 ","date":"2026-05-28","externalUrl":null,"permalink":"/posts/redpocket/","section":"Posts","summary":"Redpocket 30$/年 包含了1GB全球漫游流量，100分钟全球漫游通话，100条全球漫游，各种平台接码也很丝滑","title":"【eSIM】Redpocket(红包卡) 30$每年 购买激活记录","type":"posts"},{"content":"","date":"2026-05-28","externalUrl":null,"permalink":"/tags/esim/","section":"Tags","summary":"","title":"Esim","type":"tags"},{"content":"","date":"2026-05-28","externalUrl":null,"permalink":"/categories/networking/","section":"Categories","summary":"","title":"Networking","type":"categories"},{"content":"","date":"2026-05-28","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"2026-05-28","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":" 需求背景 # 楼主最近新买了一台软路由，然后设置了openclash为全屋代理，但是我使用Mac开发时所使用的网络环境会经常变化，而且会使用到surge进行rewrite（毕竟如果我全屋都用openclash我的surge不白买了😭），最终目的还是让surge接管我电脑的代理\n问题随之而来，现在openclash主推的模式是fake-ip模式，但fake-ip模式下，若要实现局域网设备的黑白名单过滤，DNS劫持模式必须改为防火墙转发模式，并不支持Dnsmasq转发。\n放弃Dnsmasq转发意味着放弃了openclash的绕过中国大陆功能，该功能可以使访问国内大众网站下的流量不经过clash内核处理，有效降低了内核的负载，同时提高了访问速度。\n在Dnsmasq模式下，大家最普遍的控制设备是否走代理的方式就是在openclash的规则集里添加这条规则：\nrules: SRC-IP-CIDR,192.168.1.23/32,DIRECT 这样做的确可以实现特定设备不走代理，但是弊端也很明显，虽然特定设备不走代理，但是流量白白的进入了内核进行了拆包再根据规则封装转发，同样会提高内核负载。\nfake-ip的另一个缺点 在fake-ip模式下，设备针对域名的ping操作会失效，这是因为在开启fake-ip模式后，为了保证系统的正常运作，openclash会向防火墙添加拒绝ICMP报文的规则，导致失效。\n因此，无论是使用Dnsmasq转发，还是使用防火墙转发，都无法解决上述的所有问题，那么是否可以让特定设备的所有流量全部绕过内核，在该设备上网时，openclash对于它是完全透明的。\n这样无论是NAS还是别的什么设备，可以放心的让它进行直连而不用担心流量被偷偷跑完了\n参考文档 # 在实现上述目标的过程中，我参考了以下链接：\nopenclash的基础设置，实现全屋代理\n# OpenWrt 使用 Tag 给特定的设备单独指定旁路网关的地址和 DNS\nOpenClash 在 Dnsmasq 转发模式下基于 MAC 绕过设备\n整合实现 # 我整合并优化了上述文档的内容生成了下面这一份实现教程。\n这是这份教程撰写时我的软路由系统信息：\n固件版本：ImmortalWrt 24.10.4 r33602-e717d133ed6d / LuCI openwrt-24.10 branch 25.300.72106~0418b54 内核版本：6.6.110 Clash内核版本：alpha-g86257fc Openclash客户端版本：v0.47.055 如果你在实施过程中发现有的Web UI不一致，请搜索自己的系统版本的相同操作方法。\n固定设备ip地址 # 如果你已经为设备设置了dhcp静态ip地址，请忽略该步骤。\n进入网络 -\u0026gt; DHCP/DNS -\u0026gt; 静态地址分配 -\u0026gt; 添加\nMAC 地址选择设备的MAC地址，IPv4 地址填写为设备当前的ip地址，租约时间选择12h，剩下的保持默认，保存并应用配置，这样以后每次设备联网时都会固定分到当前的ip地址。\n修改来源流量访问控制 # 进入Openclash主页，选择插件设置，滑到最下面，在来源流量访问控制的设置界面，添加新的一项，内部地址填刚才固定的ip地址，端口留空，通讯协议选择全部，对象选择RETURN，完成后点击最下面的应用配置。\n这样设置完毕后，设备针对real-ip地址的访问流量会直接绕过内核，但是设备要获得real-ip需要先进行DNS。如果设备的DNS服务器地址还填的路由器网关地址，那么内核还是会劫持DNS请求并返回一个fake-ip，而来源流量访问控制是不会让访问fake-ip的流量绕过内核的，因此下一步我们需要设置设备的DNS服务器。\n设置设备的DNS服务器 # 关于设备的DNS服务器有两种设置方法：\n方法一 # 直接进入自己设备的网络设置，手动更改DNS服务器为国内的热门DNS服务器，比如114.114.114.114、223.5.5.5、119.29.29.29 但个人更推荐第二种方法，方法二不会修改设备的网络设置，方便设备切换不同网络环境时保证网络设置的唯一性\n方法二 # 该方法是基于Dnsmasq的tag功能实现的，可以为单独的设置分配网关和DNS服务器地址，我们此处只需要分配DNS服务器地址。\n进入刚才固定ip地址的页面中，编辑你刚才设置的固定ip的那一条目，找到标签，添加一个，比如directnode，tag 名称不能包含空格和特殊字符，保存并应用。\n进入OpenWrt的命令行页面，执行以下命令：\nuci set dhcp.directnode=\u0026#34;tag\u0026#34; uci set dhcp.directnode.dhcp_option=\u0026#34;6,223.5.5.5,119.29.29.29,114.114.114.114\u0026#34; uci commit dhcp /etc/init.d/dnsmasq restart 上面的directnode即你创建的tag名称，类型设置为tag，dhcp_option中6代表下发的DNS服务器地址，多个地址直接使用逗号分隔。\n断开设备的网络连接，并重新连上，这样会重新触发dhcp分配，查看设备的网络设置，路由器下发的DNS服务器地址应该就不是路由器地址了。\n理论上讲，此时DNS过程也不走路由器了，这下应该可以实现从DNS到访问real-ip全程绕过内核了，但是如果你这个时候去访问Google，发现你的设备还是能访问成功。\n修改防火墙规则 # 问题其实出在了路由器防火墙规则上，在openclash到fake-ip模式启动后，openclash会添加一条防火墙规则，将所有的TCP/UDP到53端口的请求全部劫持到本机的53端口，那么其实上面设置的公共DNS并没有什么作用，设备发送到公共DNS服务器的请求还是会被劫持并返回fake-ip\n解决的方法也很简单，由于openclash的防火墙转发的黑白名单实现就是依赖防火墙的，它维护了一个需要绕过的设备的MAC地址的集合，随后在DNS劫持的时候，凡是命中该集合内的MAC地址的数据包都直接放行。\n我们可以仿照这个思路在Dnsmasq模式下也实现黑白名单功能，在openclash中用户可以通过覆写脚本实现对防火墙规则的操作。\n进入openclash首页，点击 插件设置，再点击开发者选项。\n粘贴下面的覆写代码，填写具体设备的MAC地址到里面，该代码维护了一个需要绕过的MAC地址集合，使DNS劫持时命中集合的数据包直接放行。\n警告 下面代码修改的是基于nftables的防火墙，如果你使用的是iptabls的防火墙，部分语法可能不适用，可以让AI帮你转化一下语法。\n#!/bin/sh . /usr/share/openclash/ruby.sh . /usr/share/openclash/log.sh . /lib/functions.sh # This script is called by /etc/init.d/openclash # Add your custom overwrite scripts here, they will be take effict after the OpenClash own srcipts LOG_OUT \u0026#34;Tip: Start Running Custom Overwrite Scripts...\u0026#34; LOGTIME=$(echo $(date \u0026#34;+%Y-%m-%d %H:%M:%S\u0026#34;)) LOG_FILE=\u0026#34;/tmp/openclash.log\u0026#34; #Config Path CONFIG_FILE=\u0026#34;$1\u0026#34; sleep 20 LOG_OUT \u0026#34;Tip: Start Add Custom Firewall Rules...\u0026#34; # \u0026gt;\u0026gt;\u0026gt; 在这里填需要绕过 Clash 的设备 MAC，空格分隔 MACS=\u0026#34;aa:bb:cc:dd:ee:ff\u0026#34; # 1) 集合：lan_bypass_macs（存在则清空，确保可重复执行） if nft list set inet fw4 lan_bypass_macs \u0026gt;/dev/null 2\u0026gt;\u0026amp;1; then nft flush set inet fw4 lan_bypass_macs || : else nft add set inet fw4 lan_bypass_macs \u0026#39;{ type ether_addr; flags interval; }\u0026#39; || : fi # 填充集合 for mac in $MACS; do # 正规化为小写 m=$(echo \u0026#34;$mac\u0026#34; | tr \u0026#39;A-F\u0026#39; \u0026#39;a-f\u0026#39;) nft add element inet fw4 lan_bypass_macs \u0026#34;{ $m }\u0026#34; 2\u0026gt;/dev/null || : done # 2) 删除所有旧的“ether saddr @lan_bypass_macs return”，再插到链首 nft -a list chain inet fw4 dstnat 2\u0026gt;/dev/null | awk \u0026#39; /ether saddr @lan_bypass_macs/ \u0026amp;\u0026amp; / return/ { for (i=1;i\u0026lt;=NF;i++) if ($i==\u0026#34;handle\u0026#34;) {print $(i+1)} }\u0026#39; | while read -r h; do [ -n \u0026#34;$h\u0026#34; ] \u0026amp;\u0026amp; nft delete rule inet fw4 dstnat handle \u0026#34;$h\u0026#34; 2\u0026gt;/dev/null || : done nft insert rule inet fw4 dstnat ether saddr @lan_bypass_macs return || : LOG_OUT \u0026#34;Done: MAC bypass rules loaded.\u0026#34; exit 0 事已至此，现在你的设备的所有流量应该都不会进入clash内核了，而且fake-ip也不会影响你ping域名了😄。\n","date":"2026-03-7","externalUrl":null,"permalink":"/posts/fake-ip/","section":"Posts","summary":"实现了openclash在fake-ip的Dnsmasq转发下按设备走代理","title":"【教程】Openclash在fake-ip的Dnsmasq转发模式下根据设备MAC让其流量绕过内核","type":"posts"},{"content":"","date":"2026-03-7","externalUrl":null,"permalink":"/tags/openclash/","section":"Tags","summary":"","title":"Openclash","type":"tags"},{"content":"","date":"7 March 2026","externalUrl":null,"permalink":"/en/tags/soft-router/","section":"Tags","summary":"","title":"Soft Router","type":"tags"},{"content":"","date":"2026-03-7","externalUrl":null,"permalink":"/tags/%E8%BD%AF%E8%B7%AF%E7%94%B1/","section":"Tags","summary":"","title":"软路由","type":"tags"},{"content":" 需求背景 # 作者最近想要折腾一台NAS用于家庭影音库的搭建，但是仔细研究了一下，内存和硬盘的价格都不是很合适，且近几年来由于NAS走入了大众视野，运营商对上行带宽的限制变严格了许多，导致外网播放也逐渐受损。\n恰好这个大佬的文章可以很好的解决我的需求：【教程】如何用一台2g15g的VPS结合网盘实现302直链播放的个人全自动追番Emby影视库\n于是我仿照着大佬的思路进行了复现，并在最后记录下自己踩坑的点，如果你在部署时遇到了问题，希望我踩过的坑你不用再踩一遍，希望对大家有所帮助！\n搭建前的准备 # 你需要具备的知识：\n了解Linux系统的基本操作。 了解Docker的基本用法。 我的基本情况：\n树莓派5 8G内存 32G存储卡 115网盘会员 关于设备 根据我部署成功之后的体验来看，我这块树莓派5的性能是完全冗余的，由于这套观影架构的特性，设备大部分时间的CPU占用为0，因此一台入门级别的VPS是完全够用的。\n关于网盘 网盘的选择主要在于两点\n最好是国内网盘，这套架构完全支持杜比蓝光原盘电影的播放，一部这样的电影大小约70G～80G，如果使用国外的网盘，那么就要付出高昂的流量费用了，且大部分国外网盘在国内并没有做CDN加速。 最好没有速度限制，要播放高码率的影片，对网盘的带宽提出了很大的要求，如果你的网盘会员会限速（比如淘宝88 VIP兑换的夸克网盘），那么观影体验会差很多。 最终效果 # 如果搭建成功的话，可以实现家庭影音库的搭建，包括：\n秒开4K原盘电影。 零服务器带宽消耗，带宽由网盘商提供。 最终效果图： 方案介绍 # 组件介绍 # 本方案全程使用Docker容器部署，具备良好的可迁移性，理解各个Docker容器具体作用有利于我们完整的理解整个方案架构。\nOpenList # OpenListTeam/OpenList\n相当于在服务器上自建了一个品牌为OpenList的网盘，可以将市面上的其他网盘挂载在该网盘的目录下，理解这一点对后续架构的理解至关重要。\n笔记 比如我将115网盘挂载到了OpenList网盘的/115目录下，同时我将夸克网盘挂载到了OpenList网盘的/Quark目录下，用户只需要访问OpenList网盘就可以同时访问两个甚至多个网盘。\nTaoSync # dr34m-cn/taosync\n可以将OpenList网盘中的在线内容下载到服务器上，主要用于将OpenList网盘生成的Strm文件同步到服务器上。\nMihomo # MetaCubeX/mihomo\n基于Clash.Meta的科学上网组件，实现服务器访问墙外的网站，主要用于解决Emby获取影片元数据连接不成功的问题。\nMetacubexd # MetaCubeX/metacubexd Mihomo的前端面板，用于控制Mihomo的代理节点。\nEmby # 家庭媒体库的核心，对家庭影音库的资源进行统筹管理，在本方案中主要是用于扫描存储到本地的Strm文件用于建立媒体库索引。\n镜像地址：https://hub.docker.com/r/amilys/embyserver\nMediaLinker # thsrite/MediaLinker\n对Emby实现反向代理，并拦截用户的观影请求重定向到网盘，是实现观影时服务器0负载的关键\n方案原理 # 方案的主要原理为将轻量化的VPS转化为PB级数据中心的网关，用户与VPS的数据交换均为控制信号，VPS将用户的观影请求直接重定向至网盘，影片流量绕过了VPS直接来到了用户设备中，极大的降低了服务器的配置要求。\n开始部署 # 在我们准备好VPS后，在用户目录下，创建目录my_media，家庭影音库的所有配置都存储到该目录下\n部署OpenList # 在my_media下创建docker-compose.yml文件，填入我们第一个容器OpenList的配置信息。\ndocker-compose.yml # services: # OpenList配置 openlist: image: openlistteam/openlist:latest # 官方镜像 container_name: openlist restart: always # 保证服务器意外断电时自动重启服务 ports: - 5244:5244 # 将5244端口映射到外部 environment: - TZ=Asia/Shanghai # 国内时区 volumes: - ./openlist/data:/opt/openlist/data # my_media/openlist文件夹下存储OpenList的所有配置信息 - ./Strm:/Strm # 重点！OpenList生成的Strm文件保存到物理机的my_media/Strm里 挂载网盘 # 完成编辑后尝试启动服务，在命令行输入\ndocker compose up -d 显示运行成功后访问http://\u0026lt;服务器ip\u0026gt;:5244，成功进入OpenList主界面。\n账户为admin，密码会在第一次启动的时候在终端日志里打印出来，登陆进去后第一时间改密码。\n根据OpenList的官方文档添加自己的使用的网盘，我添加的是115，添加成功后会在主页显示出来。\nStrm文件生成 # .strm 文件本质上是一个纯文本文件，里面并不存储任何视频内容，而只保存了一行或多行媒体资源的直接访问地址（例如 HTTP / HTTPS / WebDAV / SMB / RTSP 等）。\n可以把它理解为一个“视频的快捷方式”或“在线播放指针”。\n而Emby完美支持Strm文件的读取，在Emby的眼中.strm文件就是一个媒体视频，因此我们可以将大量的Strm文件保存在存储空间有限的轻量VPS中。\nOpenList支持对内部目标进行扫描并自动生成该目录下文件对应的.strm文件，进入开OpenList管理 -\u0026gt; 存储 -\u0026gt; 添加 -\u0026gt; 驱动名称选择Strm，我们都需要填这些内容：\n挂载路径：/virtual_strm 启用签名：开启。 路径：你挂载在OpenList中的网盘的路径。比如我将115网盘挂载在/115，而我的影音文件都存储在网盘的01_Media_Library中，因此我的完整路径填为/115/01_Media_Library。 站点URL：填为http://\u0026lt;服务器ip\u0026gt;:5244。这样我们生成的**媒体资源的直接访问地址（直链）**为外部地址，而不是容器内的地址。 携带签名：开启。开启此项OpenList生成的直链后面会加上签名用于鉴权，如果你的服务器会暴露在公网环境下请务必开启，此项用于防止你的网盘目录结构被猜出来被任意用户使用直链访问。 完成之后OpenList会自动生成你选择的目录下的.strm文件到/virtual_strm中\n按照预期，此时我们在浏览器访问.strm中的链接是可以直接播放的，同时服务器的不会产生明显的流量变化。\n注意 此时的.strm文件只存储于OpenList网盘中，在VPS的视角中该文件依然是在线文件，而Emby只支持本地文件夹的访问，因此我们需要将.strm文件同步到本地文件夹中，我们使用TaoSync实现这一过程。\n部署TaoSync # 我们在刚才编辑的docker-compose.yml中填入TaoSync的配置信息。\ndocker-compose.yml # services: # OpenList配置 openlist: ... # TaoSync配置 taosync: image: dr34m/tao-sync:latest # 官方镜像 container_name: taosync restart: always ports: - 8023:8023 # 映射8023端口到外面 volumes: - ./taosync:/app/data # my_media/taosync目录下存储TaoSync的配置信息 配置同步作业 # 再次启动服务，此时我们访问http://\u0026lt;服务器ip\u0026gt;:8023，成功进入TaoSync的主界面。与OpenList类似，用户名为admin，密码打印到了日志里，如果没有的话使用my_media/taosync中的恢复密钥改一下密码即可。\nTaoSync本质上是用于操作网盘的，不支持对本地文件的操作，但是我们可以在OpenList中再挂载一个类型为本机存储的路径。同样进入开OpenList管理 -\u0026gt; 存储 -\u0026gt; 添加 -\u0026gt; 驱动名称选择本机存储，我们都需要填这些内容：\n挂载路径：/physical_strm 启用签名：开启。 根文件夹路径：/Strm。 保存后，我们现在应该在OpenList中看到physical_strm目录，里面为空。\n进入TaoSync，进入引擎管理 -\u0026gt; 新增引擎，我们填写：\n地址：OpenList的入口地址，即http://\u0026lt;服务器ip\u0026gt;:5244。 备注：自己填写即可。 令牌：在OpenList的管理 - \u0026gt; 设置 -\u0026gt; 其他 -\u0026gt; 页面最下面的令牌，复制填写进去。 接下来进入作业管理 -\u0026gt; 新建作业，我们填写：\n引擎：刚才创建的引擎。 源目录：即存储着生成的strm文件的目录/virtual_strm。 目标目录：即需要被同步的目录，即刚才创建的本机存储目录/physicial_strm。 同步方法：全同步。这样我们在云端删除的文件也会在本地删除。 同步间隔：10分钟，自己酌情考虑时间，该时间仅供参考。 完成后点击作业右侧的手动执行进行初次同步，完成后进入OpenList的/physical_strm目录，里面应该有着刚才生成的strm文件。\n各种strm文件夹的区分（点击展开阅读） 这是我刚开始搭建时让我很迷惑的点，从开始部署到现在一共出现了3个strm文件夹/Strm，/virtual_strm，/physical_strm。\n为了便于区分其作用域，我才用类网络传输协议的方式对这些文件夹加上前缀：\nVPS://代表该目录是在服务器物理存储的，与服务器上的其他文件夹并无差异。 OpenList://代表该目录只在OpenList中可见，就类似于你在其他网盘里的内容一样，你在其中的修改不会影响到服务器本地文件，就类似于你在网盘中新建了文件夹，这对你电脑没有任何影响。 接下来我们讲讲各种strm目录协作下发生了什么。\n在我们添加了OpenList://virtual_strm之后，该目录下自动生成了与OpenList://115/01_Media_Library中一样的目录结构，并且为每个媒体文件创建了strm文件。这是最初的strm文件。 在我们配置OpenList://physical_strm之后，由于OpenList的本机存储目录的特性，OpenList将VPS://my_media/Strm文件夹挂载到OpenList://physical_strm上，我们在操作OpenList://physical_strm的同时，其实就是在操作VPS://my_media/Strm。 当我们使用TaoSync将OpenList://virtual_strm与OpenList://physical_strm建立同步时，TaoSync会一直保持OpenList://physical_strm与OpenList://virtual_strm一致，而操作OpenList://physical_strm的时候同样会在VPS://my_media/Strm中写入strm文件。 到此为止，我们就成功的对网盘上的内容建立strm文件并进行本地存储。\n此时你如果再向网盘上传一个视频后，10分钟后该文件的strm文件会出现在服务器端my_media/Strm目录中，浏览器点击strm的链接也是可以直接播放的。\n部署Emby # Emby是个人媒体服务器软件，部署到服务器上之后可以将分散在本地硬盘、NAS 或远程存储中的媒体资源统一整理成一个带有海报、简介、演员信息的媒体库，并通过客户端实现在线播放。\n继续在docker-compose.yml中编写Emby配置，\ndocker-compose.yml # servicces: # OpenList配置 openlist: ... # TaoSync配置 taosync: ... # Emby配置 embyserver: image: amilys/embyserver_arm64v8:latest # arm架构的镜像 container_name: emby network_mode: bridge # 使用桥接模式 environment: - UID=0 - GID=0 - TZ=Asia/Shanghai - HTTP_PROXY=http://192.168.31.164:7890 - HTTPS_PROXY=http://192.168.31.164:7890 - http_proxy=http://192.168.31.164:7890 - https_proxy=http://192.168.31.164:7890 - NO_PROXY=localhost,127.0.0.1,openlist,medialinker - no_proxy=localhost,127.0.0.1,openlist,medialinker volumes: - ./emby/config:/config - ./Strm:/data/Strm # 将本地的VPS://Strm目标映射到容器里 ports: - 7568:8096 # 将Emby端口映射到7568 restart: always 注意服务器系统架构 由于我的树莓派是arm架构的，所以我的emby用的是arm架构的镜像文件，请根据自己的服务器架构选择合适的镜像：\nARM架构的服务器配置与我一样即可。 x86架构的服务器镜像填为amilys/embyserver:latest即可。 创建媒体库 # 再次运行Docker之后，我们访问http://\u0026lt;服务器ip\u0026gt;:7568进入Emby的首页，第一次启动需要进行初始化，请根据页面的提示完成即可。\n用户完成注册登陆后，我们进入设置 -\u0026gt; 媒体库 -\u0026gt; 新建媒体库：\n内容类型：番剧/电视剧目录选择电视节目；电影选择影片 文件夹：选择/data/Strm/Movies'或者/data/Strm/TV_Shows\u0026rsquo;等，具体根据你自己的媒体库结构选择，不过建议是媒体类型按照种类存放。 其他配置保持默认即可，Emby是个比较复杂的系统，后续留着慢慢折腾。 建立成功后如图所示，此时回到主页视频应该是可以直接播放的，此时CPU利用率应该会占满，同时服务器也会有明显的上传与下载流量。如果播放不了也没关系，这大概率是因为浏览器的解码能力太弱导致的。 另外，你的媒体库可能加载不出来封面图片等元数据，这大概率是因为获取这些数据的网站被墙了，我们接下来在服务器上部署代理服务解决此问题。\n部署Mihomo与Metacubexd # Mihomo是新一代基于Clash.Meta内核的代理软件，由于服务器普遍没有GUI界面，我们需要再部署Metacubexd用于控制Mihomo。\ndocker-compose.yml # services: # 刚才的一些配置 ...... # Mihomo配置 mihomo: image: metacubex/mihomo:latest container_name: mihomo restart: always network_mode: host volumes: - ./mihomo/config:/root/.config/mihomo # my_media/mihomo/config存储mihomo配置 cap_add: - NET_ADMIN # 给予网络权限，防止出错 # Metacubexd配置 metacubexd: image: dzlx/metacubexd:latest container_name: metacubexd restart: always ports: - \u0026#34;8088:80\u0026#34; # 网页访问端口，你可以改成自己喜欢的 配置代理服务 # 由于代理只需要进行媒体元数据的采集，因此对梯子的要求很低，我用的是市面上很常见的1元机场，下载机场配置文件到服务器的~/my_media/mihomo/config/config.yaml中。\n提供一个简单的思路 由于市面上提供的机场订阅链接直接下载普遍都是Base64编码后的配置文件，那么我们先进行订阅转化再下载即可。\n随便搜一个订阅转换的网站，我这里用的是https://acl4ssr-sub.github.io/ 选择基础模式，直接粘贴你的机场订阅链接，点击生成订阅链接，并复制。 在服务器终端输入：curl -L -o ~/my_media/mihomo/config/config.yaml \u0026quot;你刚才转换生成的订阅下载链接\u0026quot; 检查一下下载完的配置文件，确保开头有这些内容，如果没有需要自己加上。\n再次运行Docker，进入http://\u0026lt;服务器ip\u0026gt;:8088，进入到Mihomo管理页面，进行节点选择等的配置。\n让Emby服务器走代理 # 再次编辑docker-compose.yml，为Emby的配置添加上这几行环境\nservices: ... ... ... # Emby配置 Emby: ... environment: ... - HTTP_PROXY=http://\u0026lt;服务器ip\u0026gt;:7890 - HTTPS_PROXY=http://\u0026lt;服务器ip\u0026gt;:7890 - http_proxy=http://\u0026lt;服务器ip\u0026gt;:7890 - https_proxy=http://\u0026lt;服务器ip\u0026gt;:7890 - NO_PROXY=localhost,127.0.0.1,openlist,medialinker - no_proxy=localhost,127.0.0.1,openlist,medialinker 重启Docker，这下我们媒体库的页面可以完美显示封面等信息了。\n部署MediaLinker # 我们在直接使用Emby进行播放时，由于Emby的本身的特性，就算Emby获得了用户需要观看的视频的直链，他会亲自当作中转，自己获取直链的内容并转发给用户，这样就导致服务器的CPU占用极高，同时伴随着大量的上传/下载行为，太费钱了。\nMediaLinker应运而生，MediaLinker是embyExternalUrl的docker版本，旨在通过nginx对Emby进行反向代理。\n当用户发起播放请求时，MediaLinker会拦截这个请求，自己调用Emby的API获取播放直链，一旦获取成功就直接返回给用户，此时的直链终点目标是OpenList，用户会直接访问OpenList的直链，OpenList在接收到请求后会根据直链查数据库 / 缓存，确认这是哪个存储（阿里云盘 / OneDrive / 115 / 百度网盘…）的哪个文件，调用对应的官方网盘的API接口获取该资源在官方网盘上的直链，一般为https://cdn.115.com/xxx/xxx/xxx?sign=xxxx\u0026amp;expires=10000，这种链接的有效期一般有限，每次获取都不一样。然后将这个链接通过302重定向的方式返回给用户，用户就成功建立起了用户 -\u0026gt; 网盘CDN之间的数据流 继续编写docker-compose.yml\ndocker-compose.yml # services: # 刚才的一些配置 ... ... ... # MediaLinker配置 medialinker: image: thsrite/medialinker:latest container_name: medialinker restart: always network_mode: host # 注意使用Host模式，Host在高并发的情况下性能会更优 environment: - SERVER=emby - NGINX_PORT=8091 # 我们以后就通过ip:8091访问emby - NGINX_SSL_PORT=8095 - AUTO_UPDATE=false volumes: - ./medialinker:/opt 配置MediaLinker # 运行Docker服务后，MediaLinker会自动生成~/my_media/medialinker/constant.js配置文件，配置里面的几项，剩下的无特殊需求可以不用修改。\nconst embyHost = \u0026#34;http://\u0026lt;服务器ip\u0026gt;:7568\u0026#34;; # 为Emby暴露出来的端口 const embyApiKey = \u0026#34;xxxxxxxxxxxxx\u0026#34;; # 在Emby -\u0026gt; 设置 -\u0026gt; API密钥 -\u0026gt; 新建API密钥，生成后复制进来 const mediaMountPath = [\u0026#34;\u0026#34;]; # 这里不用填 再次重启Docker服务，这次我们访问http://\u0026lt;服务器ip\u0026gt;:8091进入Emby，此时再点击一个视频播放，我们会惊喜地发现CPU占用与上下行流量几乎都为0了😄。\n当然，我个人是不推荐直接在浏览器上看Emby的，市面上有着很多成熟的支持Emby的媒体播放器，添加Emby服务时地址端口记得填写为8091即可。\n部署过程中我遇到的问题 # Emby第一次运行时退出，代码555 # 这就是因为系统架构不同，记住选择适配自己机器的镜像！\nEmby显示不出视频封面 # 90%是因为网络问题，参考上面的教程部署Mihomo，并让Emby走代理。\n家庭内网里服务器断电重启后连接不上所有服务 # 试着在路由器的管理页面检查一下服务器的ip是不是变了，最好别让服务器使用DHCP，在路由器管理界面为服务器分配一个静态ip，记得同步更改OpenList的Strm里的站点URL。\n尝试使用互联网现成的Clash前端页面时发现连不上 # 大概率是因为服务器地址填的是http协议，被浏览器拦截了，有能力最好让服务器用上https😿。\n部署Mihomo后Emby获取元数据的地址依然没有走代理 # 一般是因为获取元数据的地址没有在规则里，一般的解决方法是添加超时的地址到规则里面去，又或者代理走白名单模式，只有在白名单里面的地址直连，不在里面的地址一律走代理。\n配置基本上都没问题但是播放不了 # 检查OpenList中的网盘Cookie之类的是否过期了，不要认为你可以通过OpenList查看文件列表就可以播放文件，网盘商对查看内容的API更严格，验证cookie是否失效的方法就是在OpenList中打开一个文件，如何过期了会显示消息。\n播放报错401 # 一般是因为OpenList开启了签名，访问者访问的时候没有携带签名。 有两种解决方法：\n（推荐）在配置生成strm文件的存储驱动中开启携带签名选项，开启后最好手动在TaoSync中同步一下，如果你不想等10分钟的话。 （公网环境下慎用）在OpenList管理 -\u0026gt; 设置 -\u0026gt; 全局 -\u0026gt; 签名所有，关掉这个，同时关闭所有存储驱动的签名功能，关闭你访问的存储驱动的密码。 断开与服务器的链接后服务就失效了 # Docker运行时没有加-d，没有建立守护进程。\n总结 # 经过上面的一番折腾，我们实现了在轻量服务器上部署可以播放4K蓝光原盘电影的Emby项目，用户与服务器之间只进行控制信号的交流，数据流是直接与网盘进行的。\n此方案优点在于在户外播放也是满速的，你不必使用自己服务器的上行带宽进行数据传输，此外大多数网盘都具有妙传的功能，节约了下载资源的时间\n此方案的缺点也很明显，要不限速的国内网盘的会员，同时断网的时候也不能进行观看。\n最后分享几个我个人在用的资源站：\n【收费】哆咪｜高清影音分享平台｜里面有大量蓝光原盘演唱会视频和高解析音乐｜主要收录着日语歌\n【免费】音范丝｜老牌4K蓝光原盘电影分享平台\n【免费】蜜柑计划｜全网最全的番剧资源网站\n【免费】SeedHub｜比较综合的一个资源站\n【免费但需要登陆】NULLBR｜目前电影近12w+部，剧集4.5w+部。99%提供磁力下载链接。7w+网盘分享\n","date":"2026-01-30","externalUrl":null,"permalink":"/posts/new_media/","section":"Posts","summary":"经过一番折腾，我实现了在轻量服务器上部署可以播放4K蓝光原盘电影的Emby项目。","title":"【教程】因为买不起内存，我使用了树莓派+115网盘+Strm搭建了家庭影音库（踩坑实录）","type":"posts"},{"content":"","date":"30 January 2026","externalUrl":null,"permalink":"/en/tags/115-cloud-drive/","section":"Tags","summary":"","title":"115 Cloud Drive","type":"tags"},{"content":"","date":"2026-01-30","externalUrl":null,"permalink":"/tags/115%E7%BD%91%E7%9B%98/","section":"Tags","summary":"","title":"115网盘","type":"tags"},{"content":"","date":"2026-01-30","externalUrl":null,"permalink":"/tags/docker/","section":"Tags","summary":"","title":"Docker","type":"tags"},{"content":"","date":"2026-01-30","externalUrl":null,"permalink":"/tags/emby/","section":"Tags","summary":"","title":"Emby","type":"tags"},{"content":"","date":"2026-01-30","externalUrl":null,"permalink":"/tags/openlist/","section":"Tags","summary":"","title":"OpenList","type":"tags"},{"content":"","date":"2026-01-30","externalUrl":null,"permalink":"/categories/projects/","section":"Categories","summary":"","title":"Projects","type":"categories"},{"content":"","date":"30 January 2026","externalUrl":null,"permalink":"/en/tags/raspberry-pi/","section":"Tags","summary":"","title":"Raspberry Pi","type":"tags"},{"content":"","date":"2026-01-30","externalUrl":null,"permalink":"/tags/%E6%A0%91%E8%8E%93%E6%B4%BE/","section":"Tags","summary":"","title":"树莓派","type":"tags"},{"content":" 这是第一篇hugo博客 # ","date":"2026-01-9","externalUrl":null,"permalink":"/posts/hello-world/","section":"Posts","summary":"","title":"Hello World","type":"posts"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"}]