PS5版Minecraft卡加载：将微软HTTPS与游戏UDP分流
内容提要
PS5版Minecraft卡加载，抓包发现微软Azure的TCP 443认证响应超时，游戏UDP未启动，并非DNS或IPv6问题。解决方案：在OpenWrt上用ShellCrash仅对该PS5的MAC地址代理TCP 443，DNS和UDP 19132直连，规则需持久化，并移除无关的DNS改写和端口转发。
延伸解读
为何不应先改DNS
文章指出，BedrockConnect解决的是主机版如何进入自定义服务器的入口问题，并非加载慢的通用修复。DNS改写、透明代理或IPv6确实可能导致失败，但本例中即使恢复默认DNS，加载问题依旧。因此，在未抓包确认前，盲目改DNS可能掩盖真正原因，浪费排查时间。
控制面与数据面分离的排查思路
作者将Minecraft流量分为控制面（登录、授权、皮肤、资源下载，走TCP 443）和数据面（多人游戏流量，走UDP，Bedrock常用19132）。抓包显示卡加载时只有微软/Azure的TCP 443和TLS流量，且SYN-ACK延迟超一秒，UDP游戏流量未启动。这证明问题在控制面路径，而非游戏服务器不可达。
精准分流规则的关键设计
最终方案仅对PS5的MAC地址代理TCP 443，DNS和UDP 19132直连。脚本有三个刻意限制：只匹配单个设备MAC，不影响其他设备；只匹配TCP 443，不碰UDP 19132；先删除旧规则再插入新规则，避免重复累积。规则置于PREROUTING顶部，其余流量仍走直连。
持久化与验证要点
手动插入的iptables规则在重启、防火墙重载或ShellCrash重新初始化后会消失。作者将脚本放入ShellCrash任务目录，并在启动和防火墙钩子中调用。每次更改后需验证：iptables和ip6tables的PREROUTING规则、redir端口监听状态。然后完全退出并重开Minecraft，必要时重启PS5以清除旧会话。
Q&A
PS5版Minecraft卡加载，为什么不要先改DNS？
因为DNS不是根本原因。文章指出，即使恢复默认DNS，加载问题依然存在。BedrockConnect解决的是进入自定义服务器的入口问题，并非通用修复。真正的问题是微软Azure的TCP 443认证响应超时，而游戏UDP未启动。
如何诊断PS5 Minecraft卡加载是网络问题？
通过三层证据：1. 路由器无负载，Wi-Fi ping无丢包；2. 路由器直接HTTPS请求微软授权端点成功；3. 抓包显示DNS、TCP 443、TLS流量正常，但未进入UDP游戏流量，且SYN-ACK响应超过1秒。这定位到微软/Azure HTTPS直连路径差。
OpenWrt上如何为PS5单独代理TCP 443而保留UDP直连？
使用ShellCrash，通过iptables/ip6tables规则匹配PS5的MAC地址，将TCP 443重定向到ShellCrash的redir端口（如7892），同时不处理UDP 19132和DNS。规则需同时覆盖IPv4和IPv6，并先删除旧规则再插入新规则。
为什么手动添加的iptables规则重启后会失效？如何持久化？
手动插入的规则在重启、防火墙重载或ShellCrash重新初始化后会消失。应将脚本放入ShellCrash的任务目录，并在启动和防火墙钩子中调用，确保ShellCrash启动后和防火墙重载后各运行一次。
配置后如何验证规则是否生效？
运行以下命令检查：iptables -t nat -vnL PREROUTING 和 ip6tables -t nat -vnL PREROUTING 应看到针对PS5 MAC的443重定向规则；ss -lntp | grep 7892 应看到redir端口监听。然后完全退出并重开Minecraft，必要时重启PS5。
诊断过程中尝试过哪些无效规则，为什么应该移除？
尝试过DNS改写、端口转发和局域网服务器重定向，但证据表明它们不是当前原因。特别是将UDP 19132 DNAT到局域网主机的规则，当目标服务未运行时会造成黑洞，看起来像网络故障。应移除这些无关规则。
