如果你正在寻找一款能同时处理常规代理与游戏加速的 OpenWrt 插件，FullCombo Shark 的部署思路值得直接照做。这份 FullCombo Shark 分步部署教程围绕官方 README 可直接确认的信息展开，目标是让路由器上的 LuCI 界面出现可配置入口，并把 FullCone 相关设置准确落到列表与规则中。整个操作不依赖猜测，只使用 Fantastic Packages 预编译仓库与 GitHub 上的源码仓库两条真实路径。下面从环境要求开始，逐步完成安装与基础配置。
环境要求与可用来源
FullCombo Shark 以 LuCI 应用形式提供，包名为 luci-app-fchomo。运行它需要 OpenWrt 24.10 或更高版本，并且防火墙组件必须使用 firewall4。对于仍在旧版 OpenWrt 或使用 iptables 风格防火墙的环境，不应直接套用本教程中的命令。
实际获取插件有两个来源。第一个来源是 Fantastic Packages，属于预编译 ipk 仓库，适合已经确定目标设备软件包格式的读者。仓库说明中明确提到 GitHub 上有 prebuilt-ipks 链接，进入 Fantastic Packages 对应的 GitHub 页面后，可以找到预编译软件包入口。从 Fantastic Packages 进入后，只需按页面给出的目录结构查找 luci-app-fchomo 及其依赖包，无需自行编译。第二个来源是官方源码仓库，适合需要从 x86_64 SDK 自行构建的场景。下面的构建顺序只针对 README 明确写出的 x86_64 SDK，不扩展到其他路由器芯片或另类交叉编译工具链。
从 x86_64 SDK 构建 luci-app-fchomo
如果选择源码构建，先要准备 OpenWrt 的 x86_64 SDK。拿到 SDK 压缩包后，第一步是解包 SDK。解包完成后进入 SDK 根目录，后续所有命令都在这个根目录执行。
第二步运行 make menuconfig。这个命令会打开文本式配置界面，为后续选择 LuCI 应用做准备。不要跳到其他目录，也不需要在 menuconfig 中搜索设备架构信息。
第三步执行更新并安装 feeds。该步骤让 SDK 获得可用软件包列表，保证后续克隆的插件能进入构建候选范围。
第四步将仓库克隆到 package/openwrt-fchomo。目标路径为 package 目录下的 openwrt-fchomo 子目录，按 README 原样执行即可。克隆完成后，插件源码就位于 SDK 可识别的包目录中。
第五步再次进入配置界面，在 LuCI -> Applications 下选择 luci-app-fchomo。选中后保存配置，然后编译该包。SDK 会只处理 luci-app-fchomo 及其依赖，而不是整个固件。构建成功后，可在 SDK 输出位置找到生成的 ipk 文件。对于已经用 Fantastic Packages 直接取包的用户，不需要执行上述任何 SDK 命令。
初次安装后的资源文件补充
README 提到，初次安装后如果资源文件下载遇到问题，可以上传 initial resource pack。这个补充机制只用于资源文件下载受阻的情况。README 没有给出具体文件路径、资源包内容、上传按钮位置或具体的故障提示文案，因此操作时只需要知道存在 initial resource pack 这个可选补救手段。不要在 LuCI 界面中逐项寻找“资源文件下载失败”的栏目，而是等实际安装完成后再观察插件能否正常进入配置页。
配置 FullCone Direct 与 Proxy 规则
安装完成后，重点配置 Global 与 Network 下的几组列表和规则。FullCombo Shark 的 FullCone 行为依赖列表匹配与防火墙规则共同作用，不能只开启一个总开关就认为游戏流量会自动走 FullCone。
Global > Access Control 下有两个自定义列表。Custom Direct list 用于指定直连条件，Custom Proxy list 用于指定代理条件。两者都支持基于目标地址与端口的匹配。README 中提到 Custom Proxy list 与 Dst-address/Dst-port 相关，说明代理列表可按目标地址和目标端口写条件。对于 Custom Direct list，同样要使用地址与端口来描述哪些流量不进入代理。两个列表的优先级和命中顺序以界面实际展示的全局访问控制逻辑为准，不要假定直连列表天然优先于代理列表。
域名匹配需要额外注意。README 指出，若要按域名进行匹配，需要安装 dnsmasq-full。普通 dnsmasq 不具备此类域名匹配能力，因此涉及域名的直连或代理条目应在确认 dnsmasq-full 已安装后再添加。使用纯 IP 或 CIDR 的条目则不依赖 dnsmasq-full。
Network > Firewall > Traffic Rules 是 FullCone 生效的另一处关键位置。流量规则需要在防火墙中建立对应条目，才能把匹配到的连接按 FullCone 方式处理。这里的 Traffic Rules 不是全局 NAT 开关，而是与访问控制列表配合的规则集合。创建规则时只依据 README 列出的界面路径，不在防火墙自定义规则框中手动粘贴未记载的脚本。
Routing Control > Routing port (UDP) 进一步限定 UDP 路由端口。该设置针对 UDP 流量生效，对于依赖 UDP 的游戏通信或语音传输，这个端口范围会参与路由决策。不要把 Routing port (UDP) 理解成 TCP 端口，也不要把它与代理端口混为一谈。
Client > Routing rule 是客户端维度的路由规则。该处允许为指定客户端设置独立路由策略，适合区分游戏主机、PC 或其他需要不同代理策略的设备。设置客户端规则时仍要回到上面两个自定义列表中补充对应地址与端口条件，否则客户端规则可能缺少匹配对象。
上游连接是否具备 Fullcone 也需要满足。README 写明，上游连接需 Fullcone。这意味着仅路由器本机启用 FullCone 相关规则还不够，出口节点或上游链路本身必须支持 Fullcone。对于自建出口，需要在服务端确认 NAT 类型；对于第三方出口，则要依据出口提供方的说明判断是否具备 Fullcone 能力。
以上配置项共同组成 FullCone Direct/Proxy 的基本流程。Custom Direct list 与 Custom Proxy list 负责分流，Traffic Rules 负责防火墙匹配，Routing port (UDP) 处理 UDP 路由端口，Client Routing rule 指定客户端范围，dnsmasq-full 支撑域名条件，上游 Fullcone 保证连接最终行为。每一步都有明文界面路径，不需要在 SSH 中额外执行未记载的命令。完成这些设置后，返回插件主界面保存并应用即可。所有操作都来自 README 中可直接确认的说明，可作为 FullCombo Shark 分步部署教程的完整执行依据。
功能范围与术语澄清
近期围绕 FullCombo Shark 的描述中存在一些超出原始说明的推断，有必要回到 README 本身，区分哪些内容是明确列出的能力，哪些只是读者自行补充的解释。FullCombo Shark 是 OpenWrt 上用于灵活定制 Mihomo 的 LuCI 应用。界面依据 Mihomo 文档提供可视化配置。这里所说的“可视化配置”，指的是把 Mihomo 的文本配置项转化为图形表单，不涉及运行时的流量走向或设备鉴权过程。
README 分别列出两类访问控制能力。访问控制支持白名单与黑名单，这一表述对应应用内的规则组织方式，而非描述某台设备是否被允许接入网络。换句话说，白名单与黑名单是配置层面的概念，属于 Mihomo 规则匹配的一部分，不能推导出网关层面的接入许可或拒绝行为。同样，DNS 劫持在 README 中的定位是“用于阻止绕过网关的 53 端口查询行为”。这是一个功能意图的说明，而不是对实际拦截流程或解析先后顺序的描述。读者不应当把“阻止绕过”理解为已接入设备之后发生的某种强制动作。
路由控制依据端口、IP 与域名。这三个维度同样是配置界面提供的筛选条件，属于规则编写时的匹配依据，并非对数据包实际走向的说明。DNS 请求可依据 EDNS-Client-Subnet 或策略进行智能路由。这里提到的是 README 中的能力条目，它说明该应用支持按 ECS 信息或策略选择路径，但不涉及公共 DNS、固定 DNS 设置或具体的解析链路。所有这些表述都停留在“可以提供什么配置项”的层面，而不是“系统如何执行”的层面。
综上，把 FullCombo Shark 的 README 条目当作网络行为的完整描述是不准确的。它的功能列表面向配置管理：访问控制、路由依据、DNS 劫持意图、智能路由条件。至于已接入之后的设备状态、DNS 与目标连接的先后关系、公共 DNS 的固定与否，这些内容并未出现在原始说明中。理解该应用时，应当把术语放回各自的配置主题下，避免用机制细节去填补文档未写明的空白。