ASP.NET Core 试题 49：反向代理与容器部署
0961 在 转发头信任 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 公网请求带 X-Forwarded-For 时应用应无条件把它当真实 IP
- B. Forwarded Headers 中间件可根据可信代理恢复客户端 IP、Scheme 和 Host
- C. 应配置 KnownProxies、KnownNetworks 和 ForwardLimit，防止客户端伪造头
- D. 观察到“攻击者绕过基于来源地址的策略”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 转发头信任 的主规则：Forwarded Headers 中间件可根据可信代理恢复客户端 IP、Scheme 和 Host。选项“应配置 KnownProxies、KnownNetworks 和 ForwardLimit，防止客户端伪造头”是使用规则时要验证的边界，不是规则本身；“公网请求带 X-Forwarded-For 时应用应无条件把它当真实 IP”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0962 攻击者绕过基于来源地址的策略。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“应配置 KnownProxies、KnownNetworks 和 ForwardLimit，防止客户端伪造头”，再依据“Forwarded Headers 中间件可根据可信代理恢复客户端 IP、Scheme 和 Host”判断实现是否符合契约。
- B. 直接按“公网请求带 X-Forwarded-For 时应用应无条件把它当真实 IP”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“应配置 KnownProxies、KnownNetworks 和 ForwardLimit，防止客户端伪造头”。
- D. 以一次成功请求作为结论，不再确认“Forwarded Headers 中间件可根据可信代理恢复客户端 IP、Scheme 和 Host”是否成立。
查看答案与解析
正确答案A
场景“攻击者绕过基于来源地址的策略”指向 转发头信任，但症状本身不能证明根因。正确排查应先确认边界“应配置 KnownProxies、KnownNetworks 和 ForwardLimit，防止客户端伪造头”，再用主规则“Forwarded Headers 中间件可根据可信代理恢复客户端 IP、Scheme 和 Host”解释证据。直接采用误区“公网请求带 X-Forwarded-For 时应用应无条件把它当真实 IP”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0963 关于 转发头信任，以下哪项说法不成立？
难度： 实战
- A. Forwarded Headers 中间件可根据可信代理恢复客户端 IP、Scheme 和 Host
- B. 应配置 KnownProxies、KnownNetworks 和 ForwardLimit，防止客户端伪造头
- C. 出现“攻击者绕过基于来源地址的策略”时，应收集证据并同时核对主规则与适用边界。
- D. 公网请求带 X-Forwarded-For 时应用应无条件把它当真实 IP
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“公网请求带 X-Forwarded-For 时应用应无条件把它当真实 IP”正是 转发头信任 的典型误区。其余三项分别给出了主规则“Forwarded Headers 中间件可根据可信代理恢复客户端 IP、Scheme 和 Host”、适用边界“应配置 KnownProxies、KnownNetworks 和 ForwardLimit，防止客户端伪造头”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0964 针对“攻击者绕过基于来源地址的策略”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“公网请求带 X-Forwarded-For 时应用应无条件把它当真实 IP”修改实现，并把一次请求成功作为验收结果。
- B. 按“Forwarded Headers 中间件可根据可信代理恢复客户端 IP、Scheme 和 Host”修改代码后直接上线，不验证“应配置 KnownProxies、KnownNetworks 和 ForwardLimit，防止客户端伪造头”。
- C. 按“Forwarded Headers 中间件可根据可信代理恢复客户端 IP、Scheme 和 Host”修正实现，并用测试或遥测验证“应配置 KnownProxies、KnownNetworks 和 ForwardLimit，防止客户端伪造头”。
- D. 只验证“应配置 KnownProxies、KnownNetworks 和 ForwardLimit，防止客户端伪造头”，但实现仍继续依赖“公网请求带 X-Forwarded-For 时应用应无条件把它当真实 IP”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：Forwarded Headers 中间件可根据可信代理恢复客户端 IP、Scheme 和 Host；并确认 应配置 KnownProxies、KnownNetworks 和 ForwardLimit，防止客户端伪造头。继续接受“公网请求带 X-Forwarded-For 时应用应无条件把它当真实 IP”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“攻击者绕过基于来源地址的策略”这一生产场景能否安全上线。
0965 在 PathBase 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 设置 PathBase 只影响日志，不影响路由与生成链接
- B. 代理重写规则、静态资源 URL、Cookie Path 和回调地址必须一起验证
- C. 代理把应用挂在子路径时，可通过 PathBase 或转发前缀协调路由和链接生成
- D. 观察到“部署在 /app 后页面资源仍请求根路径”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 PathBase 的主规则：代理把应用挂在子路径时，可通过 PathBase 或转发前缀协调路由和链接生成。选项“代理重写规则、静态资源 URL、Cookie Path 和回调地址必须一起验证”是使用规则时要验证的边界，不是规则本身；“设置 PathBase 只影响日志，不影响路由与生成链接”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0966 部署在 /app 后页面资源仍请求根路径。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“代理重写规则、静态资源 URL、Cookie Path 和回调地址必须一起验证”，再依据“代理把应用挂在子路径时，可通过 PathBase 或转发前缀协调路由和链接生成”判断实现是否符合契约。
- B. 直接按“设置 PathBase 只影响日志，不影响路由与生成链接”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“代理重写规则、静态资源 URL、Cookie Path 和回调地址必须一起验证”。
- D. 以一次成功请求作为结论，不再确认“代理把应用挂在子路径时，可通过 PathBase 或转发前缀协调路由和链接生成”是否成立。
查看答案与解析
正确答案A
场景“部署在 /app 后页面资源仍请求根路径”指向 PathBase，但症状本身不能证明根因。正确排查应先确认边界“代理重写规则、静态资源 URL、Cookie Path 和回调地址必须一起验证”，再用主规则“代理把应用挂在子路径时，可通过 PathBase 或转发前缀协调路由和链接生成”解释证据。直接采用误区“设置 PathBase 只影响日志，不影响路由与生成链接”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0967 关于 PathBase，以下哪项说法不成立？
难度： 实战
- A. 代理把应用挂在子路径时，可通过 PathBase 或转发前缀协调路由和链接生成
- B. 设置 PathBase 只影响日志，不影响路由与生成链接
- C. 代理重写规则、静态资源 URL、Cookie Path 和回调地址必须一起验证
- D. 出现“部署在 /app 后页面资源仍请求根路径”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“设置 PathBase 只影响日志，不影响路由与生成链接”正是 PathBase 的典型误区。其余三项分别给出了主规则“代理把应用挂在子路径时，可通过 PathBase 或转发前缀协调路由和链接生成”、适用边界“代理重写规则、静态资源 URL、Cookie Path 和回调地址必须一起验证”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0968 针对“部署在 /app 后页面资源仍请求根路径”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“设置 PathBase 只影响日志，不影响路由与生成链接”修改实现，并把一次请求成功作为验收结果。
- B. 按“代理把应用挂在子路径时，可通过 PathBase 或转发前缀协调路由和链接生成”修改代码后直接上线，不验证“代理重写规则、静态资源 URL、Cookie Path 和回调地址必须一起验证”。
- C. 只验证“代理重写规则、静态资源 URL、Cookie Path 和回调地址必须一起验证”，但实现仍继续依赖“设置 PathBase 只影响日志，不影响路由与生成链接”。
- D. 按“代理把应用挂在子路径时，可通过 PathBase 或转发前缀协调路由和链接生成”修正实现，并用测试或遥测验证“代理重写规则、静态资源 URL、Cookie Path 和回调地址必须一起验证”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：代理把应用挂在子路径时，可通过 PathBase 或转发前缀协调路由和链接生成；并确认 代理重写规则、静态资源 URL、Cookie Path 和回调地址必须一起验证。继续接受“设置 PathBase 只影响日志，不影响路由与生成链接”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“部署在 /app 后页面资源仍请求根路径”这一生产场景能否安全上线。
0969 在 容器端口 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 应用监听 localhost 时宿主端口映射仍能从容器外访问
- B. Kestrel 必须监听容器可达接口，平台映射和健康探针也要指向正确端口
- C. 容器内监听地址和端口与宿主发布端口是两个层次
- D. 观察到“容器运行正常但服务端口连接被拒绝”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 容器端口 的主规则：容器内监听地址和端口与宿主发布端口是两个层次。选项“Kestrel 必须监听容器可达接口，平台映射和健康探针也要指向正确端口”是使用规则时要验证的边界，不是规则本身；“应用监听 localhost 时宿主端口映射仍能从容器外访问”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0970 容器运行正常但服务端口连接被拒绝。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“应用监听 localhost 时宿主端口映射仍能从容器外访问”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“Kestrel 必须监听容器可达接口，平台映射和健康探针也要指向正确端口”。
- C. 以一次成功请求作为结论，不再确认“容器内监听地址和端口与宿主发布端口是两个层次”是否成立。
- D. 先验证“Kestrel 必须监听容器可达接口，平台映射和健康探针也要指向正确端口”，再依据“容器内监听地址和端口与宿主发布端口是两个层次”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“容器运行正常但服务端口连接被拒绝”指向 容器端口，但症状本身不能证明根因。正确排查应先确认边界“Kestrel 必须监听容器可达接口，平台映射和健康探针也要指向正确端口”，再用主规则“容器内监听地址和端口与宿主发布端口是两个层次”解释证据。直接采用误区“应用监听 localhost 时宿主端口映射仍能从容器外访问”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0971 关于 容器端口，以下哪项说法不成立？
难度： 实战
- A. 容器内监听地址和端口与宿主发布端口是两个层次
- B. 应用监听 localhost 时宿主端口映射仍能从容器外访问
- C. Kestrel 必须监听容器可达接口，平台映射和健康探针也要指向正确端口
- D. 出现“容器运行正常但服务端口连接被拒绝”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“应用监听 localhost 时宿主端口映射仍能从容器外访问”正是 容器端口 的典型误区。其余三项分别给出了主规则“容器内监听地址和端口与宿主发布端口是两个层次”、适用边界“Kestrel 必须监听容器可达接口，平台映射和健康探针也要指向正确端口”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0972 针对“容器运行正常但服务端口连接被拒绝”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“容器内监听地址和端口与宿主发布端口是两个层次”修正实现，并用测试或遥测验证“Kestrel 必须监听容器可达接口，平台映射和健康探针也要指向正确端口”。
- B. 按“应用监听 localhost 时宿主端口映射仍能从容器外访问”修改实现，并把一次请求成功作为验收结果。
- C. 按“容器内监听地址和端口与宿主发布端口是两个层次”修改代码后直接上线，不验证“Kestrel 必须监听容器可达接口，平台映射和健康探针也要指向正确端口”。
- D. 只验证“Kestrel 必须监听容器可达接口，平台映射和健康探针也要指向正确端口”，但实现仍继续依赖“应用监听 localhost 时宿主端口映射仍能从容器外访问”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：容器内监听地址和端口与宿主发布端口是两个层次；并确认 Kestrel 必须监听容器可达接口，平台映射和健康探针也要指向正确端口。继续接受“应用监听 localhost 时宿主端口映射仍能从容器外访问”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“容器运行正常但服务端口连接被拒绝”这一生产场景能否安全上线。
0973 在 优雅终止 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 收到 SIGTERM 后进程会等待所有业务无限期完成
- B. 应用 ShutdownTimeout、负载均衡摘流和平台 terminationGracePeriod 要协调
- C. 观察到“滚动发布时长请求被强制中断”即可把一次现象当成完整框架契约。
- D. 编排平台发送终止信号后，宿主停止接流量并在宽限期内取消后台服务
查看答案与解析
正确答案D
正确答案直接描述 优雅终止 的主规则：编排平台发送终止信号后，宿主停止接流量并在宽限期内取消后台服务。选项“应用 ShutdownTimeout、负载均衡摘流和平台 terminationGracePeriod 要协调”是使用规则时要验证的边界，不是规则本身；“收到 SIGTERM 后进程会等待所有业务无限期完成”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0974 滚动发布时长请求被强制中断。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“收到 SIGTERM 后进程会等待所有业务无限期完成”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“应用 ShutdownTimeout、负载均衡摘流和平台 terminationGracePeriod 要协调”。
- C. 先验证“应用 ShutdownTimeout、负载均衡摘流和平台 terminationGracePeriod 要协调”，再依据“编排平台发送终止信号后，宿主停止接流量并在宽限期内取消后台服务”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“编排平台发送终止信号后，宿主停止接流量并在宽限期内取消后台服务”是否成立。
查看答案与解析
正确答案C
场景“滚动发布时长请求被强制中断”指向 优雅终止，但症状本身不能证明根因。正确排查应先确认边界“应用 ShutdownTimeout、负载均衡摘流和平台 terminationGracePeriod 要协调”，再用主规则“编排平台发送终止信号后，宿主停止接流量并在宽限期内取消后台服务”解释证据。直接采用误区“收到 SIGTERM 后进程会等待所有业务无限期完成”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0975 关于 优雅终止，以下哪项说法不成立？
难度： 实战
- A. 收到 SIGTERM 后进程会等待所有业务无限期完成
- B. 编排平台发送终止信号后，宿主停止接流量并在宽限期内取消后台服务
- C. 应用 ShutdownTimeout、负载均衡摘流和平台 terminationGracePeriod 要协调
- D. 出现“滚动发布时长请求被强制中断”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“收到 SIGTERM 后进程会等待所有业务无限期完成”正是 优雅终止 的典型误区。其余三项分别给出了主规则“编排平台发送终止信号后，宿主停止接流量并在宽限期内取消后台服务”、适用边界“应用 ShutdownTimeout、负载均衡摘流和平台 terminationGracePeriod 要协调”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0976 针对“滚动发布时长请求被强制中断”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“收到 SIGTERM 后进程会等待所有业务无限期完成”修改实现，并把一次请求成功作为验收结果。
- B. 按“编排平台发送终止信号后，宿主停止接流量并在宽限期内取消后台服务”修正实现，并用测试或遥测验证“应用 ShutdownTimeout、负载均衡摘流和平台 terminationGracePeriod 要协调”。
- C. 按“编排平台发送终止信号后，宿主停止接流量并在宽限期内取消后台服务”修改代码后直接上线，不验证“应用 ShutdownTimeout、负载均衡摘流和平台 terminationGracePeriod 要协调”。
- D. 只验证“应用 ShutdownTimeout、负载均衡摘流和平台 terminationGracePeriod 要协调”，但实现仍继续依赖“收到 SIGTERM 后进程会等待所有业务无限期完成”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：编排平台发送终止信号后，宿主停止接流量并在宽限期内取消后台服务；并确认 应用 ShutdownTimeout、负载均衡摘流和平台 terminationGracePeriod 要协调。继续接受“收到 SIGTERM 后进程会等待所有业务无限期完成”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“滚动发布时长请求被强制中断”这一生产场景能否安全上线。
0977 在 容器持久状态 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 容器文件系统通常是临时的，密钥、上传和业务状态应使用持久卷或外部服务
- B. 把 Data Protection 密钥写入镜像层可在运行时安全轮换
- C. 多副本还需共享或隔离策略，不能只给每个副本挂独立临时目录
- D. 观察到“重建容器后所有登录票据失效”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 容器持久状态 的主规则：容器文件系统通常是临时的，密钥、上传和业务状态应使用持久卷或外部服务。选项“多副本还需共享或隔离策略，不能只给每个副本挂独立临时目录”是使用规则时要验证的边界，不是规则本身；“把 Data Protection 密钥写入镜像层可在运行时安全轮换”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0978 重建容器后所有登录票据失效。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“把 Data Protection 密钥写入镜像层可在运行时安全轮换”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“多副本还需共享或隔离策略，不能只给每个副本挂独立临时目录”。
- C. 先验证“多副本还需共享或隔离策略，不能只给每个副本挂独立临时目录”，再依据“容器文件系统通常是临时的，密钥、上传和业务状态应使用持久卷或外部服务”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“容器文件系统通常是临时的，密钥、上传和业务状态应使用持久卷或外部服务”是否成立。
查看答案与解析
正确答案C
场景“重建容器后所有登录票据失效”指向 容器持久状态，但症状本身不能证明根因。正确排查应先确认边界“多副本还需共享或隔离策略，不能只给每个副本挂独立临时目录”，再用主规则“容器文件系统通常是临时的，密钥、上传和业务状态应使用持久卷或外部服务”解释证据。直接采用误区“把 Data Protection 密钥写入镜像层可在运行时安全轮换”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0979 关于 容器持久状态，以下哪项说法不成立？
难度： 实战
- A. 容器文件系统通常是临时的，密钥、上传和业务状态应使用持久卷或外部服务
- B. 多副本还需共享或隔离策略，不能只给每个副本挂独立临时目录
- C. 出现“重建容器后所有登录票据失效”时，应收集证据并同时核对主规则与适用边界。
- D. 把 Data Protection 密钥写入镜像层可在运行时安全轮换
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“把 Data Protection 密钥写入镜像层可在运行时安全轮换”正是 容器持久状态 的典型误区。其余三项分别给出了主规则“容器文件系统通常是临时的，密钥、上传和业务状态应使用持久卷或外部服务”、适用边界“多副本还需共享或隔离策略，不能只给每个副本挂独立临时目录”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0980 针对“重建容器后所有登录票据失效”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“把 Data Protection 密钥写入镜像层可在运行时安全轮换”修改实现，并把一次请求成功作为验收结果。
- B. 按“容器文件系统通常是临时的，密钥、上传和业务状态应使用持久卷或外部服务”修正实现，并用测试或遥测验证“多副本还需共享或隔离策略，不能只给每个副本挂独立临时目录”。
- C. 按“容器文件系统通常是临时的，密钥、上传和业务状态应使用持久卷或外部服务”修改代码后直接上线，不验证“多副本还需共享或隔离策略，不能只给每个副本挂独立临时目录”。
- D. 只验证“多副本还需共享或隔离策略，不能只给每个副本挂独立临时目录”，但实现仍继续依赖“把 Data Protection 密钥写入镜像层可在运行时安全轮换”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：容器文件系统通常是临时的，密钥、上传和业务状态应使用持久卷或外部服务；并确认 多副本还需共享或隔离策略，不能只给每个副本挂独立临时目录。继续接受“把 Data Protection 密钥写入镜像层可在运行时安全轮换”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“重建容器后所有登录票据失效”这一生产场景能否安全上线。