服务器能打开 Tomcat 首页，却打不开应用，说明网络入口和应用地址还需要继续区分。
本文使用Java Web 小项目的演示工程与协作场景。初入团队时，重要的不只是写出功能，还包括让别人能够复现、审查和接手。本文使用匿名任务说明工作方法，不指代某家公司的内部流程或真实交付成绩。
1. 从现象推到机制
主机监听端口决定能否到达容器，Web 上下文决定请求交给哪个应用，控制器映射再决定具体处理器。代理还可能修改路径和主机头。一个层级成功不能证明下一个层级正确。
图中的四个节点分别表示外部入口、容器监听、上下文路径、控制器映射。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
先从主机本地请求应用路径，再从代理入口比较。检查部署日志中的实际上下文名，不要仅凭 WAR 文件名推断所有配置。
1
2
3
curl -i http://127.0.0.1:8080/demo/health
# 再从已经配置的公共入口请求同一业务路径
# 对照代理日志与容器访问日志
示例命令需要在独立演示工程中执行，路径和服务均由读者准备。操作前保留当前版本与输入，修改后对照原来的问题验证，而不是只证明新代码能够编译。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 首页正常而业务路径四零四 | 优先核对上下文与映射 |
| 本地正常而代理失败 | 比较转发路径和监听入口 |
| 静态资源缺失 | 可能是基址与资源路径不一致 |
对照 1：首页正常而业务路径四零四
优先核对上下文与映射。观察时记录容器实际收到的请求路径。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：本地正常而代理失败
比较转发路径和监听入口。观察时记录两层访问日志的状态码。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：静态资源缺失
可能是基址与资源路径不一致。观察时记录浏览器实际请求的资源地址。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
健康接口只证明它所检查的范围。若只返回固定字符串，不能据此判断数据库、模板和写入业务都正常。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“静态资源缺失”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
