做石器时代H5内购版的手工搭建，说难不算难，但琐碎是真琐碎。我前前后后给朋友搭过几套类似的项目，踩了不少坑，今天趁周末把整套流程整理出来，从环境准备到服务端启动，再从数据库导入到前端适配，尽量把每一步的“为什么这么做”也讲清楚。这篇东西不吹不黑，完全是我自己实操过的路径记录，照着走基本能跑通。

先说结论：这套经典2DMMORPG手游的H5内购版，本质上是“网页端游戏 + 独立服务端 + 数据库 + 内购支付模块”的组合体。你要做的事情，就是把这四块在服务器上拼起来，让它对外提供游戏服务。整个过程涉及Linux基础操作、数据库导入导出、Nginx站点配置、进程守护这些常规运维技能，只要你用过宝塔面板或者敲过几行Linux命令，就能搞定。

这篇教程适合谁？手里有一台云服务器、想把石器时代H5跑起来自己玩或者做小范围运营测试的爱好者，以及想搞明白H5游戏服务端原理的入门运维。不涉及任何商业运营的灰色部分，纯粹是技术向的记录分享。

1. 项目整体拆解与搭建思路

1.1 这套H5端到底是什么形态

石器时代这个IP在2D回合制MMORPG里算是很经典的了，宠物捕捉、骑乘、回合战斗这些核心玩法辨识度极高。H5版的意思，是客户端跑在浏览器里，不需要安装App，打开网址就能进游戏。这对服务端的考验反而不小——因为所有逻辑都在服务端跑，客户端只是做了个表现层的映射。

内购版加了个关键模块：充值、礼包、支付回调。也就是说，服务端里除了游戏逻辑进程，还有一个面向支付的接口服务。玩家在网页里点充值，前端请求服务端下单，服务端跟支付渠道对接，支付成功后渠道回调服务端，服务端再给玩家的角色发放对应的货币或道具。

理解这个链路很重要。很多人在搭建时只盯着游戏主进程，结果充值模块怎么都到不了账，其实问题往往出在回调接口没通、商户号配置错、或者回调地址被Nginx拦截了。后面我会专门用一章讲内购部分。

1.2 手工搭建的整体架构图

整套系统跑起来以后，请求路径大概是这样的：

浏览器（H5前端） ↓ Nginx（80/443端口，托管H5静态文件 + 反代游戏接口） ↓ 游戏服务端进程（LoginServer / GameServer / GMServer 等，按源码实际结构来） ↓ MySQL数据库（账号、角色、日志、充值记录） ↓ 内部回调模块（内购版特有：支付渠道 -> Nginx -> 服务端回调接口 -> 发奖）

我搭过的这套，服务端进程区分比较清晰，有负责登录鉴权的，有专门跑游戏逻辑的，还有一个是GM后台和充值发放。进程之间通过内部端口通信，对外只暴露必要的端口给Nginx。

1.3 为什么选择手工搭建而不是一键脚本

说实话，网上确实有一键安装包，解压完跑个脚本就能起来。但我不推荐直接用，至少我踩过太多次一键脚本埋的坑：路径写死、端口冲突、数据库密码硬编码、进程守护缺失，出了问题连排查的头绪都没有。

手工搭建最核心的价值，是一步一步搞清楚服务端和前端是怎么对接的。比如前端页面里的服务器IP配置是写在config.js里的，数据库连接是写在服务端的settings文件里的，这两处如果不匹配，前端永远提示“连接服务器失败”。这东西嘴上说了没用，自己配一遍比看十篇文章都管用。

另外手工搭建还是有不少好处的：

• 可以自定义端口和路径，避免跟服务器上其他服务冲突。
• 数据库账号密码可以按自己的规范来，而不是用死的root/root。
• 出了问题知道从哪个环节查起，不至于对着黑屏干瞪眼。
• 后期要做服务器迁移、多区部署，理解过一遍手工流程会轻松非常多。

2. 服务端环境准备与服务器选型

2.1 服务器配置和系统怎么选

石器时代H5这套服务端对硬件要求不算夸张，但也不是随便一台乞丐机就能扛住的。我自己用的配置是4核8G的云服务器，带宽5M起步。如果你只是自己拉三五个人测试，2核4G也能跑，不过开服之后随着在线人数上来，响应会明显变慢。

系统方面，我用的是CentOS 7（64位）。这套服务端的很多底层依赖在CentOS系上最稳，尤其是PHP和MySQL的旧版本兼容性比新系统好。如果你手头是Ubuntu或Debian，也完全可以跑，就是部分依赖的包名有差异，装的时候稍微注意一下。

注意：尽量别用Windows Server跑这套服务端。不是说跑不起来，而是很多启动脚本是sh格式的，还得折腾模拟环境，费那劲儿不如直接上Linux。

2.2 安装宝塔面板还是纯命令行

两个方案都用过，我的经验是：新手强烈建议用宝塔面板，熟练的可以不用。宝塔的好处是Nginx、MySQL、PHP这些组件用图形界面就能装好，省去了命令行的编译时间。而且文件管理、数据库导入导出、端口放行这些操作都有界面，对手工搭建来说容错率高很多。

装宝塔的命令各家版本不一样，装好之后在浏览器里打开面板地址，用初始账号密码登录。然后在“软件商店”里安装：

• Nginx 1.18以上版本
• MySQL 5.7（这套端用5.7稳，8.0的认证方式跟老代码兼容性差）
• PHP 5.6或7.0之间选一个（具体看你的服务端程序要求）

如果服务端程序里含Node.js部分，再装一个PM2管理器，用PM2守护Node进程。

2.3 编译工具和基础依赖

有些服务端程序带的是编译好的二进制，但有的模块（比如某个加密so、自定义扩展）需要现编。保险起见装一下基础工具链：

yum install -y gcc gcc-c++ make cmake wget tar unzip zip yum install -y openssl-devel zlib-devel libxml2-devel curl-devel

这些工具装起来不亏，后面解压源码、编译扩展、处理文件权限都会用到。我搭第一套的时候没装编译工具，结果某个PHP扩展加载不了，服务端直接报错，白白浪费了一个晚上才排查出来。

2.4 端口规划和防火墙放行

服务端一般会开这么几类端口：

端口的具体数字请以你拿到手的那套服务端里的配置文件为准，不要死记我写的这组。我见过很多教程统一写死某个端口，结果人家手里版本不一样，照抄就翻车。

宝塔面板放行端口的位置在“安全”里，添加规则。云服务商控制台的防火墙或者安全组也要同步放行，两边缺一个都会导致外部连不上。腾讯云和阿里云在这里的名字不一样，但都在控制台网络那块找。

3. 服务端文件部署与数据库初始化

3.1 拿到文件后先做什么

假设你手头已经有一套石器时代H5内购版的完整服务端压缩包，解压之前先做三件事：

1. 放到一个不含中文、不含空格的路径下，比如/data/shiqi。
2. 用unzip解压包，解压后看一下目录结构，不要急着启动。
3. 找到服务端目录下的config、server、sql、web这类文件夹，把每个目录的作用搞明白。

我见过有人解压后不管三七二十一直接跑start.sh，结果报了一堆错才发现SQL文件没导入、配置文件里数据库密码还是旧库的，整个白忙。手工搭建最重要的一点就是先花十分钟摸清楚你的服务端有哪些组成部分，这十分钟后面能省一小时。

以下是一个典型目录结构的参考：

/data/shiqi/ ├── server/ # 游戏服务端程序，含login、game等子目录 ├── sql/ # 数据库初始化脚本 ├── web/ # H5前端代码（静态页面） ├── tool/ # 批量导入、GM工具等辅助脚本 ├── start.sh # 一键启动脚本 ├── stop.sh # 停止脚本 └── README.txt # 附带说明，先读它

3.2 数据库搭建与导入

先在宝塔里创建一个数据库，数据库名按你服务端的要求来，一般是shiqidb或者sr_game之类。创建的时候顺便记下数据库名、用户名、密码，后面配置文件要用，别跟宝塔默认的搞混。

然后进到sql目录，看有哪些.sql文件。常见的命名规则跟用途对应：

• account.sql：账号登录相关的库
• role.sql/char.sql：角色数据
• log.sql：日志库
• pay.sql：充值订单记录（内购版关键）

导入的方式有两种。宝塔里可以直接在数据库的“导入”里上传文件，方便但慢；文件多的话我更推荐命令行导入：

mysql -u你的用户名 -p你的密码 你的数据库名 < /data/shiqi/sql/account.sql

多张表分布在多个sql文件里的，就逐个导入，顺序按依赖关系来，先导基础表再导业务表，否则外键关联会报错。

3.3 修改核心配置文件

导入完成后进入重点环节——配置文件修改。这个步骤里改错一个值，服务端就起不来或者前端连不上。我把自己踩过的坑和正确改法列一遍。

服务端的配置文件一般叫config.ini、server.ini、.env、config.php这种，位置可能有一个总配置加多个子配置。核心要改的是：

1. 数据库连接：host填127.0.0.1，port填3306，user和password改成你自己的。
2. 监听地址：一般填0.0.0.0，让所有网卡都能访问；如果填了127.0.0.1，外部玩家就连不上。
3. 开放端口：确认login和game用的端口跟前面规划的一致。
4. 加密密钥/签名key：内购版的支付回调签名在这里配置，改成自己生成的随机字符串。

注意：配置文件里的密码如果带特殊字符（如#、&），有的程序会解析截断，导致连接失败。密码尽量用字母数字组合，别自找麻烦。

3.4 启动服务端进程

配置文件改完以后，就可以尝试启动了。不建议直接挂在前台跑，建议用后台方式：

cd /data/shiqi chmod +x *.sh ./start.sh

启动完成后第一时间看进程和端口：

ps -ef | grep java(或你的服务端程序名) netstat -tlnp | grep 游戏端口

如果进程起来了，端口也监听正常，说明程序基本跑通了。这时候别急着关掉，再去日志目录看看有没有刷报错：

tail -f /data/shiqi/server/log/*.log

常见启动失败的原因，我在第6章统一列出排查办法，这里先不展开。

4. H5前端与Nginx站点配置

4.1 前端文件放哪里

服务端起来了，接下来要让浏览器能打开游戏页面。前端代码就是web目录里的那堆静态文件，你要把它们托管到Nginx站点下。我习惯的做法是把整个web目录复制到Nginx默认站点目录的根目录下，跟站点同名：

cp -r /data/shiqi/web /www/wwwroot/h5/

然后配置一个站点，绑定你的域名或者服务器IP。如果暂时没域名，直接用服务器IP加端口访问也行，但生产环境强烈建议上域名，后面支付回调、微信内置浏览器访问都会涉及域名是否可信的问题。

4.2 前端配置文件的改动

前端目录里几乎必有一个config.js或settings.js，里面的内容长这样（按你实际看到的来）：

var GAME_SERVER = { "serverIP": "127.0.0.1", // 改成你的公网IP或域名 "serverPort": 9001, // 改成服务端登录网关端口 "payCallback": "https://你的域名/pay/notify" };

前端连接服务端的逻辑就是拿着这个IP和端口去连。这里有个新手特别容易踩的坑：改完把文件保存了，但浏览器缓存了旧的js，打开页面还是被指向旧地址。解决方法是改完以后，在Nginx配置里给前端js加个版本号参数，或者在浏览器里强制刷新。

4.3 Nginx反代接口与HTTPS配置

如果你的服务端接口是HTTP请求，且需要跟你的前端同域，最简单的方式是在Nginx里加一条反向代理规则：

location /api/ { proxy_pass http://127.0.0.1:游戏进程端口/; proxy_set_header X-Real-IP $remote_addr; }

这样前端就不需要直连游戏端口，统一走80/443，再由Nginx转发给后端的游戏进程。好处是端口少暴露，被攻击面小很多。

HTTPS按现在的环境来说基本是刚需，尤其是微信内置浏览器里打开的页面，非HTTPS地址经常被拦截。宝塔里配置证书很简单，一键申请或上传已有证书都行。

重要提示：如果你要接入微信系能力（比如企业微信客服、公众号菜单跳转等），域名必须是备案过的HTTPS域名，并且一会儿还要用到文件校验、JS接口安全域名配置，这些都依赖一个能正常访问的HTTPS站点。

5. 内购版核心：支付回调与充值发放

5.1 内购版和普通版到底差在哪

标题里明确写了“内购版”，这块必须重点讲。普通版光有游戏逻辑就行，内购版额外多了三块东西：

• 商品表配置（礼包、月卡、首充的物品和时间）
• 支付接口下单模块（跟渠道对接，生成订单号）
• 回调接收模块（渠道支付成功之后通知服务端，服务端处理发货）

这三块如果配置不对，最常见的现象就是：玩家在网页上付了钱，钱从渠道出去了，但游戏里没到账。这种问题还特别难排查，因为中间隔了好几层。

5.2 配置支付参数

支付参数在服务端的pay或recharge配置里，一般要填这些：

• 商户号（渠道给你的）
• 商户密钥（签名用的，别泄露）
• 回调通知地址（必须是公网可访问的HTTPS地址）
• 下单接口的签名规则

每家渠道的字段名略有差异，原则是一样的：先确认商户号密钥填对了，再确认回调地址是公网能访问的。我第一次搭内购版的时候，商户号填反了两位数字，结果支付单一直创建不了，排查了一个多小时才找到。

5.3 从支付成功到发奖的全链路

完整链路如下：

1. 玩家在H5页点充值按钮。
2. 前端请求服务端的下单接口，服务端生成本地订单号。
3. 前端跳转或拉起支付页面，带着本地订单号去渠道支付。
4. 渠道完成扣款，向服务端的回调地址发送HTTP通知。
5. 服务端收到通知，验签通过后核对本地订单。
6. 订单匹配成功，向角色数据库写入对应货币/道具。
7. 游戏内玩家收到发放结果。

在这个链路里，最脆弱的两个环节是第4步和第5步：

• 回调地址不通：渠道通知不到你的服务端，钱只能躺着。
• 验签失败：通知到了但签名校验不过，服务端直接丢弃。

要检测是不是这两个环节出问题，最直接的办法是看服务端日志里有没有支付回调相关的记录。另一个笨办法是自己在服务器上用curl模拟一个回调请求：

curl -X POST https://你的域名/pay/notify \ -H "Content-Type: application/json" \ -d '{"order_id":"test123","amount":"6.00","trade_no":"fake20241101"}'

这个请求发过去看返回码和服务端日志变化，就能判断回调接口本身通不通。验签伪签过不了是正常的，重点看接口有没有被Nginx拦截、进程有没有接收到。

5.4 GM工具与手动补发

内购版一般都会附带一个GM后台，我用过的那套是独立于游戏进程的，地址通常在http://域名/gm/，登录后可以给指定角色发货币、发道具、调整等级。

这个GM工具在生产环境里最好限制来源IP，否则谁拿到地址谁就能乱改数据。宝塔的“安全”里加一条仅允许你自己的IP访问GM端口的规则，能挡掉绝大多数陌生人乱入的风险。

6. 常见问题与排查技巧实录

6.1 数据库连接失败

报错长这样：Failed to connect to database或者SQLSTATE[HY000] [1045] Access denied。

排查顺序按这个来：

1. 先用命令行试一下数据库能不能连：mysql -u账号 -p密码 -h127.0.0.1。
2. 如果命令行也连不上，就是账号密码错了或者没有远程授权。
3. 命令行能连但服务端报错，大概率是配置文件里的host、port、dbname写错了。
4. 检查数据库权限——有些库默认只许root从localhost访问，服务端进程如果用别的用户就连不上。

6.2 服务端启动几分钟后进程消失

这是最气人的问题：启动脚本跑完显示OK，进程起来了一会儿又自动退了。查这个优先看日志，因为进程退出一定会有日志留下。

我见过的主因有两个：

• 内存不够被系统kill了。用dmesg | tail看有没有OOM字样。2G内存跑全套服务端确实紧张，加Swap能缓解。
• 服务端程序的数据库连接掉了。有的程序不会重连，MySQL服务重启过它就静默崩溃。

另外确认一下你启动用的用户有没有文件写权限。用root启动一般没事，但如果用普通用户，日志目录创建失败也会悄悄退出。

6.3 前端打开了但一直卡在登录界面

先问一句：前端显示的内容有没有正常加载？如果页面都出来了、能输入账号密码，说明前端和Nginx正常。问题是登录请求一直转圈，这时按顺序排查：

1. 检查前端config.js里的IP是不是公网IP或域名。
2. telnet测试一下游戏端口通不通：telnet 服务器IP 端口。
3. 如果本机通但外网不通，查防火墙和安全组。
4. 如果端口通但还是报连接失败，看登录进程日志，可能是协议版本不匹配或数据库查不到该账号。

6.4 常见问题速查表

6.5 避坑建议

这套项目我前后搭了好几遍，总结出几个特别容易省时间的地方：

• 服务端目录权限：直接给chmod -R 777是最快的，虽然是懒办法，但测试环境完全够用。
• 保持版本一致性：前端代码、服务端程序、数据库脚本最好是同一个包里出的。混搭不同来源的文件，轻则报错，重则数据错乱。
• 改配置前先备份：配置文件改炸了是常事，备份一份原始文件能让你随时回滚，不至于一条路走到黑。
• 日志是唯一可信的：不看日志瞎猜配置是最浪费时间的操作。不管什么问题，先tail -f日志再动手。

7. 上线运营前要做的几项优化

7.1 进程守护

手工启动的服务端不会说从崩溃里自己爬起来。上线前用supervisord或者宝塔的“进程守护管理器”把每个关键进程守护起来，进程挂了自动拉起，能省掉半夜起来重启服务器的糟心事。

7.2 定时备份

数据库是整个服务的命根子。配置一个每天凌晨3点的定时任务，把MySQL数据导出来存到另一个盘，甚至传到对象存储。我是用宝塔的定时备份功能跑的，操作起来简单，速度也快。

7.3 修改默认端口

服务端的GM端口、内部通讯端口如果都走默认值，很容易被扫描软件盯上。在不影响游戏运行的前提下，把GM后台端口改成一个高位随机端口，再加上IP白名单，安全性会好很多。

7.4 性能参数调整

如果是CentOS 7，建议把系统的文件打开数上限调高，不然连接多了会出too many open files：

ulimit -n 65535

MySQL的innodb_buffer_pool_size在内存允许的情况下也调大一点，我4G内存的机器给它分了2G，查询速度肉眼可见变快。

这套搭建流程写下来，基本就是我从零到一把服务端跑通的完整路线。回头再看，手工搭建的价值不在那几步操作本身，而在操作过程中建立起来的“全局认知”——知道哪个文件管哪块、哪个端口扔哪条数据，后面无论做调优还是排查，心里都有底。

最后再分享一个小技巧：搭建过程中每做完一个阶段（比如数据库导入完成、服务端启动成功、前端能登录），就截个图或者写几行笔记记录结果。这套端如果过两三个月再维护，光靠记忆很容易漏掉关键步骤，一份当时顺手写的部署记录能帮你节省大量重新梳理的时间。