FCHomo 访问控制配置常被当作一个页面入口来理解，但它背后至少涉及 Access Control、Routing ports (TCP/UDP)、Custom Direct List 与 Custom Proxy List 等界面项。该项目是用于在 OpenWrt 上灵活定制 Mihomo 的 LuCI 应用包，包名 luci-app-fchomo；README 列出网关透明代理与网关 FullCone NAT，并说明访问控制支持白名单与黑名单、路由控制可依据端口、IP 与域名。本文只从这些名称和项目说明出发，说明每个界面项能确定什么、不能确定什么，避免把某一个 FullCone 场景的字段当成通用规则。
FCHomo 访问控制配置的界面边界
global.js 显示 Access Control、Routing ports (TCP/UDP)、Custom Direct List 与 Custom Proxy List 等界面项。它们出现在同一套 LuCI 视图中，并不等于所有条目都归 Access Control 一个开关管理。更稳妥的理解是：Access Control 是访问控制相关设置的入口界面项，Routing ports (TCP/UDP) 指向端口维度的路由配置，Custom Direct List 与 Custom Proxy List 则是两个列表界面项。这些名称名称不同，填写的对象也不同，不能因为都在 Global 附近就互相替代。
这里要先划清一条边界：README 能确认的是白名单与黑名单两种访问控制方式，以及路由控制可按端口、IP、域名进行。这些名称本身不展开匹配顺序或作用范围；要了解具体字段，应查阅 README 中与该界面项对应的段落，而不是只凭界面名称推断。界面名称的作用是命名一个配置入口，它既不宣告条目之间的先后关系，也不说明某个条目会覆盖另一条目。把名称当作“路标”而非“规则全文”，才能避免在填写时把不同场景的字段混在一起。
FCHomo 访问控制方式：白名单与黑名单
FCHomo 白名单黑名单配置的核心，是项目说明中明确出现的两种访问控制方式。白名单与黑名单是并列的名称，不应把其中一个当成另一个的别名，也不应仅凭名称推断条目会如何匹配、优先级如何排列、是否自动回退。就现有项目说明而言，能确定的是“支持白名单与黑名单”；更细的字段、适用范围和与自定义列表的关系，需要回到 README 对应段落查阅。
这也是访问控制配置中容易混淆的地方：管理员往往希望从一个界面项直接推出完整行为，但名称只负责命名入口，不负责解释所有条件。把白名单、黑名单与 Custom Direct List、Custom Proxy List 混为一谈，会让后续填写 Dst-address 时失去场景边界。更合理的做法是确认当前要处理的是访问控制方式，还是某个 FullCone 场景中的目标列表，再决定查哪一段说明。白名单与黑名单只说明“有这样两种方式”，并不代表它们与两个自定义列表之间存在可自行补写的对应关系；这种对应关系若未被 README 写明，就不应被当作事实使用。
FCHomo 端口 IP 域名路由：Routing ports (TCP/UDP)
FCHomo 端口 IP 域名路由对应 README 所述的路由控制能力：可依据端口、IP 与域名进行路由。global.js 中的 Routing ports (TCP/UDP) 界面项把端口维度直接写在名称里，提醒读者这里存在 TCP 与 UDP 的区分；但名称本身不展示某条规则应填 TCP 还是 UDP，也不展示它与域名条件如何组合。端口、IP、域名是三类可用的判断依据，不等于每个界面字段都同时接受这三种输入。
在 FullCone Proxy 的 README 配置说明中，出现的是 Global > Access Control > Routing Control > Routing port (UDP) 的 Dst-port，而不是笼统的“端口”一词。这个细节说明：具体场景会指定协议与字段位置，不能把 Routing ports (TCP/UDP) 的复数界面项直接等同于某一条 UDP 端口规则。管理员在填写前应查阅对应场景的 README 段落，并保留 Routing port (UDP)、Dst-port 等英文界面项原样，避免在界面中找错层级。换言之，Routing ports (TCP/UDP) 表达的是“端口维度存在路由配置”，而 Routing port (UDP) 与 Dst-port 表达的是“某个场景里某条 UDP 端口字段的位置”，两者粒度不同，不能互相替换。
Custom Direct List 与 Custom Proxy List 的字段位置
Custom Direct List 与 Custom Proxy List 是 global.js 中显示的两个列表界面项。README 的 FullCone Direct 配置说明涉及 Global > Access Control > Custom Direct list 的 Dst-address；FullCone Proxy 配置说明涉及 Global > Access Control > Custom Proxy list 的 Dst-address。两处都指出，域名形式的 Dst-address 需要 dnsmasq-full。这说明两个列表虽然都使用 Dst-address 字段，但分别出现在 Direct 与 Proxy 的配置说明中，不能互相搬用条目。
需要强调的是，以上对应关系来自 FullCone Direct 与 FullCone Proxy 的各自说明，不应被泛化为所有访问控制功能都按同一路径填写。Custom Direct List 与 Custom Proxy List 是列表界面项，Dst-address 是这些说明中出现的字段；某个域名条目会影响哪些流量、与白名单黑名单如何共同作用，不应只凭界面项自行补写。配置时应以 README 的场景段落为准，不把“列表名称”当成“完整策略”。两个列表都使用同名 Dst-address 字段这一事实，恰恰是最容易引发误搬的地方：字段名相同不代表归属相同，Direct 说明中的条目属于 Direct 场景，Proxy 说明中的条目属于 Proxy 场景，各自的域名形式都注明需要 dnsmasq-full，这一依赖说明也只应放在对应场景中理解。
FCHomo 路由控制说明：FullCone 场景的字段对应
FCHomo 路由控制说明在 FullCone Direct 与 FullCone Proxy 中并不是同一组字段。Direct 场景的 README 说明涉及 Global > Access Control > Custom Direct list 的 Dst-address、Network > Firewall > Traffic Rules 接受 Dst-port，以及上游 Fullcone 条件；Proxy 场景则涉及 Global > Access Control > Custom Proxy list 的 Dst-address、Global > Access Control > Routing Control > Routing port (UDP) 的 Dst-port，以及 Client > Routing rule 指定 Fullcone Proxy group/Outbound node。
这些字段分布在 Global、Network 与 Client 等不同位置，说明 FullCone 场景的配置边界不只在 Access Control 页面内。尤其是 Direct 场景中的 Firewall Traffic Rules 与上游 Fullcone 条件，属于该场景说明的一部分，不能自动套到 Proxy 场景；Proxy 场景中的 Client > Routing rule 指定 Fullcone Proxy group/Outbound node，也不应被说成所有访问控制规则都需要填写。把场景与字段一一对应，比记住一堆界面名称更重要。可以看到，同样是 Dst-port，Direct 场景把它放在 Network > Firewall > Traffic Rules 的“接受”语境中，Proxy 场景把它放在 Global > Access Control > Routing Control > Routing port (UDP) 之下；字段名相同而位置不同，正是需要按场景阅读 README 的原因。
配置边界与注意事项
- Access Control 是入口界面项，白名单与黑名单是项目说明中支持的两种访问控制方式；不要从名称推断匹配顺序、默认行为或未写明的效果。
- Routing ports (TCP/UDP) 表示端口维度的路由界面项，但具体场景可能只写 Routing port (UDP) 与 Dst-port；协议和字段位置应按 README 对应段落查阅。
- Custom Direct List 与 Custom Proxy List 的 Dst-address 出现在不同 FullCone 说明中，域名形式均注明需要 dnsmasq-full；不要在两个列表之间直接复制条目。
- FullCone Direct 还涉及 Network > Firewall > Traffic Rules 接受 Dst-port 与上游 Fullcone 条件；FullCone Proxy 还涉及 Client > Routing rule 指定 Fullcone Proxy group/Outbound node。这些是场景字段，不是通用访问控制步骤。
- 界面项可见不等于策略自动生效，也不构成速度或连通性承诺。配置前查阅项目 README 的场景段落与 global.js 的界面项命名，保留英文 UI 界面项，能减少把不同场景混写的机会。
把界面名称当作“路标”而不是“规则全文”，是理解这套访问控制配置的更稳妥方式：Access Control 是入口界面项，白名单与黑名单说明访问控制方式，Routing ports (TCP/UDP) 指向端口路由，Custom Direct List 与 Custom Proxy List 承载各自场景的 Dst-address。场景不同，字段位置也不同；阅读项目说明时把场景与字段放在一起看，比从界面项名称外推更可靠。当 Direct 与 Proxy 两个场景共享某个字段名时，先确认它出现在哪一段 README 说明里，再决定填写位置；当某个界面项带有协议或层级信息时，先确认具体场景是否把它细化为单独的字段名，再动手配置。按这一思路处理每个界面项，访问控制配置就从“猜界面”变成“读说明、对场景、填字段”的连续过程。
延伸阅读：部署指南、FCHomo DNS 故障排查、安装包来源