服务端在 NAS 里跑起来，和 Windows 客户端真正玩上，其实是两件事。

这次我把 OpenMU 放进家里的绿联 NAS，原本以为端口一通就结束了。结果 Windows 客户端先后经历了运行库缺失、显卡报错、中文路径乱码、游戏资源不全、服务器列表断开，最后还碰到了旧客户端对 Connect Server 端口的硬编码判断。

一路排下来，最终能稳定看到服务器组、登录账号、创建角色并进入地图。

这是一次家庭局域网里的个人技术实践。客户端、游戏数据、贴图和美术资源应使用自己合法持有并获授权的版本。本文不提供客户端、数据包、账号或授权文件的下载，也不讨论对外运营和收费。

先看最后的连接链路

这次不是简单地把客户端指向 NAS 就结束了。最终链路是这样：

Windows 客户端
  ↓ 127.0.0.1:44391
Windows 本地端口转发
  ↓ NAS_LAN_IP:18406
OpenMU Connect Server
  ↓ NAS_LAN_IP:18451
OpenMU Game Server
  ↓
登录、选角色、进入地图

NAS_LAN_IP 是我家里 NAS 的局域网地址。文章里不写真实地址，部署时替换成自己的即可。

为什么中间多了一层本地转发？后面会详细讲。它不是常规架构，而是为了兼容这个旧客户端的一处端口判断。

第一关：先确认 NAS 三个端口真的通

客户端连不上时，不要一开始就重装客户端。先在 Windows PowerShell 做最基础的连通性检查：

Test-NetConnection NAS_LAN_IP -Port 18443
Test-NetConnection NAS_LAN_IP -Port 18406
Test-NetConnection NAS_LAN_IP -Port 18451

三个结果都应为：

TcpTestSucceeded : True

分别代表：

如果 Web 端口能通、游戏端口不通，说明不是客户端本身的问题，应先检查 Docker 映射和 OpenMU 内部监听。反过来，三个端口都通，但客户端仍断开，再去看 IP 解析和协议端点。

第二关：NAS 端这三个状态必须正确

客户端能不能进游戏，NAS 端至少要满足三个条件。

1. 三个容器都正常运行

绿联 Docker 里，qijimu-web、qijimu-game、qijimu-db 都应是运行状态，OpenMU 容器最好显示 healthy。

2. IP 解析必须返回家庭局域网地址

进入 OpenMU 管理后台：

游戏配置 → 系统

设置为：

IP 地址解析方式：自定义
自定义 IP / 主机名：NAS_LAN_IP

这里我踩过一个很容易忽略的坑：只在“自定义 IP”输入框里填写地址，却没有把上方下拉框从“局域网”切换成“自定义”。看起来配置有值，实际不会按自定义模式生效。

如果这里返回 Docker 的 172.x.x.x，客户端能看到服务器列表，但点进去就会断。

3. Server 0 必须有 Open Source Client 端点

MuMain 使用的是开源客户端协议。Server 0 只有 GMO 端点时，客户端仍可能连上 Connect Server，却在选服后断开。

我最终保留了两个端点：

这三项都确认后，再回到 Windows 客户端。

第三关：补齐 Windows 运行库

第一次双击启动脚本时，客户端连续提示：

找不到 MSVCP140.dll
找不到 VCRUNTIME140.dll
找不到 VCRUNTIME140_1.dll

这不是 NAS 的问题，也不是游戏文件损坏。客户端缺少 Microsoft Visual C++ 2015–2022 x64 运行库。

可以直接用 Windows 包管理器安装：

winget install --id Microsoft.VCRedist.2015+.x64 --exact

安装完重启 Windows。这里不建议从 DLL 下载站单独抓文件，单独替换 DLL 很容易带来版本和依赖问题。

第四关：路径必须是纯英文

运行库补齐后，客户端又弹出：

install the latest graphics card driver

一开始我也以为真是 Intel 显卡驱动太旧。打开客户端目录里的 MuError.log 后，看到的内容却是：

SDL_gpu -- device driver: direct3d12
shader blob not found

也就是说，D3D12 设备已经创建成功，真正失败的是找不到着色器。而日志中的路径变成了：

C:\Users\...\浼犲MU\...\shaders\basic_textured.vert.dxil

中文目录名被旧客户端解析成了乱码。

解决办法很直接：把整个客户端移到只有英文、数字和短横线的目录，例如：

C:\Games\MuMain-CN-v1.3-FullData

不要放在桌面上的中文文件夹里，也不要把 Main.exe 单独拖出来。整个目录里的配置、DLL、Data、fonts 和 shaders 要一起移动。

第五关：客户端资源必须完整

图形初始化通过后，我又连续遇到：

LoadBitmap Failed:
Data\interface\newui_scrollbar_up.tga

Data\Local\slide.bmd - File not exist

一开始以为补一个滚动条文件就行，后来发现根因是运行包的数据目录不完整，只有一部分本地化资源，没有完整界面和公共数据。

最后我用自己合法持有的完整数据目录补齐了：

Data\
fonts\
shaders\

再补上语言目录缺少的几个公共 BMD 文件，客户端才稳定进入登录界面。

这里有一条实用经验：客户端的所有资源提示都去看 MuError.log，它一般写在 Main.exe 所在目录。比起只盯着弹窗标题，日志能直接把问题定位到文件、着色器和图形后端。

第六关：连接中断不是端口关闭

当客户端终于显示服务器列表，我点进 Server 0，又遇到了：

与服务器连接中断

这时再次做端口测试，NAS 的 18406 和 18451 都是 True。所以问题不在防火墙，也不在 Docker 断线。

继续看 MuMain 的网络实现，发现一处旧代码：

客户端通过端口范围判断 Connect Server 是否加密。
只有 44288–44543 范围内的端口，才会被当作未加密的 Connect Server。

我们为了让端口不常见，把 Connect Server 设置成了 18406。服务端没意见，客户端却把它误判成了 Game Server 一类，使用了错误的连接处理方式。

我采用的兼容办法

我不想为了一个旧判断去改已经稳定的 NAS 数据，于是在 Windows 上加了一个只监听本机的端口转发。

先以管理员身份打开 PowerShell：

Set-Service iphlpsvc -StartupType Manual
Start-Service iphlpsvc

netsh interface portproxy add v4tov4 `
  listenaddress=127.0.0.1 `
  listenport=44391 `
  connectaddress=NAS_LAN_IP `
  connectport=18406

检查转发是否生效：

netsh interface portproxy show v4tov4
Test-NetConnection 127.0.0.1 -Port 44391

这里的 44391 落在旧客户端认可的端口范围里，但只在本机监听，不会暴露到局域网或公网。

用启动参数验证整条链路

进入客户端目录：

cd "C:\Games\MuMain-CN-v1.3-FullData"

手动启动：

.\Main.exe connect /u127.0.0.1 /p44391

这时客户端先连接本机 44391，Windows 再转到 NAS 的 18406。选服后，OpenMU 返回的是自定义配置里的 NAS_LAN_IP:18451，客户端继续连接真正的 Game Server。

验证成功时，服务器选择界面可以正常出现并进入登录：

登录后创建角色，进入地图，移动和战斗都正常：

最后固定启动脚本

验证通过后，可以把客户端目录里的 Start-MU.cmd 改为：

@echo off
cd /d "%~dp0"
Main.exe connect /u127.0.0.1 /p44391
if errorlevel 1 pause

以后双击它即可。

如果以后换了已经修复端口判断的客户端版本，可以删除本机转发：

netsh interface portproxy delete v4tov4 `
  listenaddress=127.0.0.1 `
  listenport=44391

再恢复成直接连接 NAS 的 Connect Server。

我把这次故障整理成了一张表

部署完成后别忘了收尾

这套服务只放在家庭局域网里使用，管理入口和游戏端口都没有直接开放到公网。

另外，初始化阶段生成的测试账号只适合第一次联机验证。确认能登录、能创建角色以后，应改成自己的正式测试账号，并删除或停用默认测试账号。

回头再看，这次最值得记住的不是那几条命令，而是排查顺序：

1. 先测端口。
2. 再确认 OpenMU 是否真的监听。
3. 然后检查 IP 解析和 Server 0 协议端点。
4. 客户端报错时看 MuError.log。
5. 最后才处理运行库、资源、路径和旧客户端的端口兼容。

服务端在 NAS、客户端在 Windows，中间隔着 Docker 网络、反向代理、端口映射和应用层协议。只要把每一层都单独验证，原本看起来毫无头绪的“连接中断”，最后都能变成一个可以解决的问题。