服务端面试题手册

Referer 校验能作为 CSRF 防护的一层辅助判断，但不适合当唯一防线。它的做法是对会改变状态的请求，服务端读取 Referer 请求头，确认发起页面来自可信站点；如果来自陌生域名、格式非法或缺失，就拒绝或进入更严格校验流程。它能挡住不少粗糙的跨站表单攻击，但受浏览器隐私策略、Referrer-Policy、HTTPS/HTTP 跳转、代理和客户端实现影响。追问Referer 和 Origin 有什么区别？Origin 只包含协议、域名和端口，不包含完整路径，隐私暴露更少，也更适合安全校验。Referer 信息更完整，但更容易被策略裁剪。没有 Referer 的请求要不要拒绝？管理后台、转账、改密等敏感操作建议拒绝。普通业务可以要求 CSRF Token 通过，并记录日志观察误杀比例。验证 Referer 最常见绕过点是什么？把 includes('example.com') 当安全判断，可能被 example.com.evil.com 绕过。应解析 URL 后比较 hostname。Referrer-Policy 会影响吗？会。no-referrer 可能完全不发 Referer，strict-origin-when-cross-origin 跨站只发源信息。上线前要检查站点策略。写段代码const url = new URL(req.get('referer') || '');if (url.protocol !== 'https:' || !TRUSTED.has(url.hostname)) return res.sendStatus(403);

双重提交 Cookie 防护 CSRF 的核心是：服务端生成随机 token，同时让浏览器把它放在 Cookie 里，并要求前端在表单字段或请求头里再提交一份。真正的同站页面能读到这份非 HttpOnly 的 CSRF Cookie，所以能把 token 放进请求；恶意站点虽然能诱导浏览器自动带上 Cookie，却读不到目标站 Cookie，也就很难提交同一份 token。服务端比较两边是否一致，就能拦住大多数跨站伪造请求。追问它和传统 CSRF Token 有什么区别？传统 Token 通常保存在服务端 Session 里，请求来了拿提交值和 Session 值比对。双重提交 Cookie 不存服务端状态，更适合分布式和无状态接口，但要更小心 XSS、子域名和 Cookie 覆盖问题。Cookie 能不能设置 HttpOnly？普通双重提交模式下不能，因为前端需要读取 Cookie 后放进请求头或表单字段。更安全的变体是签名双重提交，避免攻击者伪造结构正确的 token。为什么不建议把 token 放 URL？URL 会进入浏览器历史、代理日志、服务端访问日志和第三方统计系统。Token 更适合放请求头或 POST body。最容易踩什么坑？Domain 配太宽，任意子域问题都可能影响主站；只判断字符串相等，没有处理缺失、长度不等和异常输入，也会留下边界问题。写段代码res.cookie('csrf_token', token, { httpOnly:false, secure:true, sameSite:'lax', path:'/' });if (req.cookies.csrf_token !== req.get('x-csrf-token')) return res.sendStatus(403);

在 React、Vue、Angular 里做 CSRF 防护，关键不是框架语法，而是把服务端发的 CSRF Token 稳定带到每个状态变更请求里。只要登录态依赖 Cookie，前端就要配合后端完成 Token 获取、请求头注入、过期重试和错误提示；如果认证完全使用 Authorization 头，CSRF 压力会小很多，但 XSS 和 Token 存储风险会变高。追问前端应该从哪里拿 CSRF Token？常见方式是服务端在首屏 HTML meta 标签写入 Token，或提供 /csrf-token 接口初始化获取。也可用非 HttpOnly 的 XSRF-TOKEN Cookie。React、Vue、Angular 差异大吗？差异主要在封装位置，不在安全原理。React/Vue 通常在 axios 或 fetch wrapper 统一加头，Angular HttpClient 有 XSRF 支持。SPA 里 Token 过期怎么办？服务端返回 419 或 403 时，可以刷新一次 Token 后重放请求；支付、转账、删除这类非幂等操作不要自动重放。CORS 配好了还需要 CSRF 吗？需要。CORS 控制脚本读取响应，不阻止浏览器发出带 Cookie 的写请求。写段代码axios.interceptors.request.use(config => { const token = document.querySelector('meta[name="csrf-token"]')?.content; if (!['get','head','options'].includes((config.method || 'get').toLowerCase())) config.headers['X-CSRF-Token'] = token; config.withCredentials = true; return config;});

企业级 CSRF 防护不要只靠某个接口临时加 Token，应该做成统一安全能力：入口层先挡明显跨站请求，应用层校验会话和 Token，高风险业务再做二次确认。架构上要兼顾多域名、SSO、微服务、灰度发布和审计，否则规则一上线就可能误伤登录、支付或第三方集成。追问校验放网关还是业务服务？最好两层都做。网关做通用拦截，如 Fetch Metadata 和 Origin 白名单；业务服务做 Token 是否绑定当前用户、租户和操作。Token 应该怎么存？服务端状态 Token 可放 Redis，便于吊销和一次性使用；双提交 Cookie 性能好，但密钥轮换和重放控制要设计清楚。SSO 和多域名会影响 SameSite 吗？会遇到边界。跨站登录跳转可能需要 SameSite=None; Secure，但业务写操作仍要校验 Origin 和 Token。落地最大坑是什么？没有资产清单就全站强制。老系统可能有跨域表单、WebView、第三方回调，应先观测日志再分级灰度。写段配置if ($http_sec_fetch_site = "cross-site") { set $csrf_block 1; }if ($request_method !~ ^(GET|HEAD|OPTIONS)$) { set $csrf_block "${csrf_block}1"; }if ($csrf_block = "11") { return 403; }

移动应用通常不容易遇到传统 CSRF，因为原生 App 不会像浏览器那样自动把站点 Cookie 带到任意跨站请求里。但如果 App 使用 WebView、共享 Cookie、深链唤起、第三方登录页，或者后端同时服务 Web 和 App，就仍然要检查“请求是不是用户真实发起”。追问原生 App 用 Bearer Token 还需要 CSRF Token 吗？大多数情况下不需要，因为 Bearer Token 不会被浏览器自动附加。但 Token 存储不安全会转成账号接管风险。WebView 为什么要特别小心？WebView 容易把 Web 的 Cookie 机制带回来，尤其是内嵌 H5、登录页和支付页。要限制可加载域名和不必要的 JavaScript Bridge。深链会引入什么风险？深链能成为触发器。危险操作不能打开链接后直接执行，必须让用户确认，并由服务端校验幂等号和权限。后端同时支持 Web 和 App 怎么分策略？Web 使用 Cookie + SameSite + Origin + CSRF Token；App 使用 Authorization 头和设备级安全存储。不要让 App 接口默认信任浏览器 Cookie。

CSRF 防护未来不会只靠一个 Token，而是会变成“浏览器默认安全能力 + 服务端显式校验 + 风险分层”的组合。现在规划时，优先把 SameSite、Origin/Referer、Fetch Metadata 和关键操作 Token 做成统一基线，再根据业务是否跨站、是否嵌入第三方页面、是否有移动端或开放 API 做例外配置。追问SameSite 变强后还需要 CSRF Token 吗？需要。SameSite=Lax 能挡住很多普通跨站请求，但挡不住所有复杂场景。Token 仍适合关键写操作。Fetch Metadata 能替代传统校验吗？不能完全替代，但适合网关低成本拦截。服务端可根据 Sec-Fetch-Site、Sec-Fetch-Mode 默认拒绝跨站危险方法。CHIPS 和分区 Cookie 会改变模型吗？会改变第三方嵌入场景，但不解决所有业务写操作授权问题。iframe、SSO、第三方插件要提前梳理 Cookie 策略。企业现在怎么改架构？把 CSRF 策略放到统一安全中间件或 API 网关，会话 Cookie 开 Secure、HttpOnly、SameSite=Lax，高风险操作再校验 Token。

在 Angular 里，RxJS 主要用来处理会随时间变化的数据：HTTP 请求、路由参数、响应式表单、组件事件和应用状态。HttpClient 返回 Observable，路由的 paramMap、表单的 valueChanges 也是 Observable，所以 Angular 项目不是额外引入 RxJS，而是日常开发天然会碰到它。追问HTTP 为什么返回 Observable 而不是 Promise？Observable 可以取消、组合，也能和表单、路由这些流保持同一套写法。单次 HTTP 看起来和 Promise 差不多，但需要重试、超时、取消旧请求时更顺手。AsyncPipe 解决了什么问题？它自动订阅 Observable，并在组件销毁时退订，减少内存泄漏。复杂副作用仍应放在组件或服务中组织。表单搜索一般怎么写？监听 valueChanges，先过滤空值，再防抖、去重，最后用 switchMap 请求接口。关键是旧请求要能被取消。BehaviorSubject 适合做全局状态吗？小型状态可以，比如当前用户、筛选条件、侧边栏开关。状态变多或需要调试时，NgRx、Signal Store 更稳。写段代码results$ = this.form.controls.keyword.valueChanges.pipe( filter(v => !!v && v.length >= 2), debounceTime(300), distinctUntilChanged(), switchMap(q => this.api.search(q)));

SSH 不是“把密码加密后发给服务器”这么简单。它先通过 TCP 连接到服务端 22 端口，双方确认协议版本和可用算法，再用密钥交换算法协商出临时会话密钥；后续真正传输命令、文件和端口转发数据时，主要靠对称加密保证速度，靠 MAC 或 AEAD 保证完整性。服务器会拿出自己的主机公钥证明“我就是你上次连过的那台机器”，客户端再用密码、公钥或键盘交互完成用户认证。追问为什么 SSH 既用非对称加密又用对称加密？非对称加密适合身份验证和安全协商，但计算成本高，不适合持续传输大量数据。SSH 用它安全商量密钥，之后切到 AES、ChaCha20 这类对称算法。known_hosts 文件有什么用？known_hosts 记录服务器主机公钥指纹，用来发现你是否连到了同一台服务器。生产环境指纹突然变化，要先确认是否重装、迁移或被中间人劫持。公钥登录比密码登录安全吗？通常更安全，因为私钥不需要发到网络上，服务端只验证签名结果。边界是私钥文件必须有口令和合理权限。SSH 能防住所有中间人攻击吗？前提是客户端正确校验服务器主机指纹。第一次连接就接受了伪造指纹，SSH 也无法凭空知道对方是假的。写段配置PasswordAuthentication noPermitRootLogin noAllowUsers deployPubkeyAuthentication yes

SSH 公钥认证的核心不是“把公钥当密码”，而是服务器用公钥验证客户端是否持有对应私钥。登录时私钥不会离开本机，客户端只用私钥对服务器给出的挑战做签名；服务器拿 authorized_keys 里的公钥验签，通过才放行。相比密码认证，它更抗撞库，也更适合自动化。追问Ed25519、RSA、ECDSA 选哪个？新环境优先 Ed25519，密钥短、速度快、安全边界清晰。需要兼容老系统时再考虑 RSA 4096。私钥还需要密码短语吗？需要，尤其是笔记本或开发机上的私钥。密码短语能在文件被复制走时多挡一层，配合 ssh-agent 使用也不会频繁输入。authorized_keys 有公钥仍失败怎么办？先查权限，目录或文件可写范围太大时 sshd 会拒绝使用。再用 ssh -vv 看客户端是否提供了对应私钥。禁用密码认证前注意什么？先确认至少有一个普通用户能用密钥登录，并保留当前会话。云主机还要确认控制台救援方式可用。写段命令ssh-keygen -t ed25519 -C "deploy@company" -f ~/.ssh/id_ed25519_prodssh-copy-id -i ~/.ssh/id_ed25519_prod.pub user@hostchmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys

SSH 端口转发就是用 SSH 连接临时搭一条加密通道，把某个端口流量转到另一个网络位置。常见参数是 -L、-R、-D：-L 是本地端口转发，-R 是远程端口转发，-D 是动态 SOCKS 代理。先判断流量入口在哪一端，就不容易选错。追问-L、-R、-D 一句话怎么区分？-L 是本机开入口访问远端资源；-R 是远端开入口访问本地资源；-D 是本机开 SOCKS 代理，目标动态决定。为什么建议绑定 127.0.0.1？绑定本地只允许本机访问，安全边界更小。绑定 0.0.0.0 可能让局域网甚至公网用户连上这个端口。端口被占用怎么办？先用 lsof -i :3307 或 ss -tlnp 找占用进程。临时调试可以换端口，不要随便杀不认识的进程。和反向代理有什么区别？SSH 转发偏临时、按连接建立；Nginx/Caddy 适合长期对外服务，有 TLS、日志、限流和路由能力。写段命令ssh -N -L 127.0.0.1:3307:db.internal:3306 user@jumpssh -N -R 8080:localhost:3000 user@publicssh -N -D 127.0.0.1:1080 user@jump

SSH 配置文件要分清两类：~/.ssh/config 管客户端怎么连，/etc/ssh/sshd_config 管服务器允许谁连。客户端重点是减少手输参数、隔离不同环境密钥；服务端重点是关掉高风险入口，如 root 登录、密码登录、无用转发。不要整段复制加固清单，应该按访问路径逐项验证。追问sshconfig 和 sshdconfig 最大区别是什么？前者是客户端读的，影响你发起连接时带哪些参数；后者是服务端读的，决定连接是否被允许以及认证策略。为什么不建议关闭 StrictHostKeyChecking？它会让客户端不再认真校验主机指纹，中间人攻击时更难发现。自动化脚本应预先分发 known_hosts。改端口能提升安全吗？只能减少低级扫描噪声，不是真正安全。核心仍是禁用密码、限制用户、控制来源 IP 和保留审计日志。修改服务端配置怎样避免锁外面？保留当前 SSH 会话，另开新终端测试登录。修改前跑 sudo sshd -t，通过后再 reload。写段配置Host prod HostName prod.example.com User deploy IdentityFile ~/.ssh/id_ed25519_prod IdentitiesOnly yes ServerAliveInterval 60PermitRootLogin noPasswordAuthentication noPubkeyAuthentication yes

SSH 密钥交换负责让客户端和服务器在不可信网络上协商出同一个会话密钥，重点不是传输密钥，而是双方各自算出相同结果。现代 SSH 通常优先 curve25519-sha256，它速度快、实现成熟，并具备前向保密。传统 diffie-hellman-group1-sha1、group14-sha1 不建议继续启用。追问密钥交换和公钥认证有什么区别？密钥交换是建立加密信道，发生在登录认证之前。公钥认证是证明“你是谁”，不负责生成会话密钥。Curve25519 为什么常被推荐？它计算快、密钥短，实现上不容易踩参数选择坑。新版 OpenSSH 兼容性也足够好。禁用 SHA-1 会影响老客户端吗？会。老系统可能只支持 group14-sha1，若必须兼容，建议给遗留入口单独开策略。前向保密解决什么问题？它防的是长期私钥后来泄露，也不能直接解过去抓到的流量；但不解决当前服务器被入侵的问题。写段配置KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512ssh -Q kexssh -vv user@host

SSH 加密算法主要分三类：会话数据用对称加密保护，身份和签名用非对称算法完成，完整性由 MAC 或 AEAD 兜底。实际配置时优先保留现代 OpenSSH 支持的组合：aes256-gcm@openssh.com、chacha20-poly1305@openssh.com、aes256-ctr。CBC、3DES 只适合遗留系统，不应出现在新服务器默认列表里。追问AES-GCM 和 ChaCha20-Poly1305 怎么选？有 AES-NI 的服务器优先 AES-GCM，吞吐通常更好。ARM 或老 CPU 上，ChaCha20-Poly1305 往往更稳定。为什么不建议 CBC 和 3DES？CBC 历史上暴露过填充相关攻击面，3DES 块大小和性能都不适合现代长连接。只配置 Ciphers 就够了吗？不够，SSH 安全还依赖 KEX、HostKey、MAC。使用 CTR 时，MAC 建议选 *-etm@openssh.com。改配置最容易踩什么坑？可能把旧客户端挡在门外。生产应保留备用会话，sshd -t 通过后再 reload。写段配置Ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctrMACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com

SSH Agent 是替你保管“已解锁私钥”的本地进程。它不会把私钥直接交给 ssh、git 或远程主机，而是在需要认证时完成签名，所以你不用每次连接都输入密钥密码。它解决效率问题，但 Agent 转发用错会放大安全风险。追问SSH Agent 和私钥文件是什么关系？私钥文件仍在磁盘上，Agent 只是把解锁后的密钥能力暂存在内存里。认证时 Agent 用私钥签名，不返回私钥内容。为什么不建议全局开启 ForwardAgent？远程机器可能使用转发过来的 agent socket。它偷不走私钥，但能在会话有效时冒用你的身份连接其他服务。Agent 转发和 ProxyJump 怎么选？只是通过跳板机连接内网服务器，用 ProxyJump 更干净。只有登录跳板机后还要 git pull 或 ssh internal，才考虑 Agent 转发。ssh-add 没有 identities 怎么办？说明 agent 正常但没加密钥。执行 ssh-add ~/.ssh/id_ed25519，再用 ssh-add -l 确认。写段命令eval "$(ssh-agent -s)"ssh-add -t 3600 ~/.ssh/id_ed25519ssh-add -lssh-add -D

SSH 隧道本质是把一段 TCP 流量塞进 SSH 加密连接里传输。常见类型有本地隧道 -L、远程隧道 -R、动态隧道 -D。选型先看入口在哪边：你在本地访问远端内网服务，用 -L；远端要访问你本地服务，用 -R；目标很多且不固定，用 -D 做 SOCKS 代理。追问本地隧道和远程隧道最大区别是什么？区别在入口端口开在哪里。-L 入口在本地，适合“我访问远端”；-R 入口在远端，适合“远端访问我”。远程隧道为什么别人访问不到？远端端口默认可能只监听 127.0.0.1。要检查 GatewayPorts、AllowTcpForwarding、安全组和防火墙。动态隧道和 VPN 怎么取舍？ssh -D 轻量临时，只代理支持 SOCKS 的应用；VPN 覆盖整机路由，更适合长期接入内网。长连接怎么稳定？加 ServerAliveInterval 和 ServerAliveCountMax，长期运行用 autossh 或 systemd 管理。写段命令ssh -L 3307:db.internal:3306 user@jumpssh -R 8080:localhost:3000 user@publicssh -D 127.0.0.1:1080 user@jump

SSH 故障排查不要一上来就改配置，先判断卡在哪一层：网络能不能到、端口有没有开、sshd 是否监听、认证是否通过、客户端是否选错密钥。timeout 多半是包没到服务端，refused 是端口没人接，Permission denied 则说明已经连到服务但认证失败。追问timeout 和 refused 有什么区别？timeout 优先看安全组、防火墙、路由和端口开放；refused 通常说明 sshd 没监听对应端口或服务没起来。先用 nc -zv host 22 验证。authorized_keys 有公钥还失败怎么办？最常见是权限太开放、用户名不对、客户端没用对应私钥。用 ssh -vvv 看实际尝试的 key，再查服务端 auth.log 或 journalctl。可以关闭 StrictHostKeyChecking 吗？不建议。它会绕过主机身份校验，遇到 DNS 污染或中间人攻击风险更高。自动化脚本应预先分发 known_hosts。改 sshd_config 最怕什么？最怕语法错误或禁掉当前登录方式后断开连接。修改前跑 sshd -t，保留当前会话，再开新窗口测试。写段命令nc -zv hostname 22ssh -vvv user@hostnamesudo systemctl status sshdsudo sshd -t

Vercel 是面向现代前端和全栈应用的部署平台。典型流程是代码推到 GitHub、GitLab 或 Bitbucket 后，Vercel 自动构建、生成预览地址，并把生产版本发布到全球边缘网络。它不是让你登录机器、装 Nginx、配证书的传统服务器，而是把构建、部署、CDN、SSL、预览环境和 Serverless 能力打包成一套工作流。追问Vercel 解决的核心问题是什么？它解决分支预览、证书域名、环境变量和自动部署这些前端团队常见痛点。提交 PR 就有预览地址，产品和测试可以直接验收真实页面。Vercel 只适合 Next.js 吗？不是，React、Vue、SvelteKit、Nuxt、Astro 都能部署。只是 Next.js 在 Vercel 上支持最完整，SSR、ISR、Route Handler、Middleware 的坑更少。Serverless Functions 能替代后端吗？能替代表单、Webhook、鉴权代理、简单聚合这类轻量接口。不适合长任务、持续连接、复杂队列消费和高状态依赖服务。什么时候不适合用 Vercel？如果系统依赖长时间运行后台服务、固定出口 IP、复杂内网或大量文件处理，就要谨慎。Vercel 更适合作为前端层和轻量 API 层。团队协作最大价值是什么？Preview Deployment 最明显。每个 PR 都能被真实访问，设计和产品不必只看截图或等测试环境排期。

Vercel 环境变量管理的核心，是把 Production、Preview、Development 三类环境隔离开。生产变量只给线上部署用，预览变量给分支和 PR，用来接测试库和沙箱服务，本地变量通过 vercel env pull 拉到 .env.local。真正容易出事故的不是不会添加变量，而是变量放错环境、前端误暴露密钥、改完变量后忘记重新部署。追问Production、Preview、Development 怎么取舍？Production 放真实数据库、正式支付密钥和线上 API。Preview 应该接测试库、沙箱支付和临时回调地址，避免 PR 预览页误操作生产数据。为什么变量改了页面还是旧配置？构建期读取的变量已经写进产物，改 Dashboard 不会改变旧部署。关键变量改完后要重新部署，或者确认代码是在运行时读取变量。前端变量为什么容易泄露？Next.js 中带 NEXT_PUBLIC_ 前缀的变量会打进浏览器端代码。数据库密码、私有 Token、Webhook Secret 绝不能加这个前缀。vercel.json 适合管什么？适合放构建命令、输出目录、重定向、headers、函数资源限制，不适合直接写敏感值。配置越多，迁移和排错成本越高。本地和线上变量不一致怎么排查？先执行 vercel env pull .env.local，再确认变量名大小写、环境选择、部署时间和本地服务是否重启。写段命令vercel env add MY_API_KEY productionvercel env add MY_API_KEY previewvercel env pull .env.local

Next.js 部署到 Vercel 省心，核心原因是框架能力和平台能力基本对齐。Vercel 能自动识别 Next.js 项目，处理构建命令、路由、静态资源、图片优化、ISR 缓存、API Routes 和中间件。开发者把代码推到 Git 后，就能得到 Production 和 Preview 两套部署链路。追问Vercel 是 Next.js 的唯一最佳选择吗？不是唯一，但通常是体验最顺的选择，尤其是使用 App Router、ISR、图片优化和预览部署时。其他平台也能部署，只是可能要手动适配。ISR 在 Vercel 上有什么优势？Vercel 能把 ISR 的缓存、后台再生成和 CDN 分发串起来。需要注意 revalidate 时间不能乱设，太短会增加回源压力。API Routes 都应该放在 Vercel 吗？轻量接口、鉴权回调和页面数据聚合适合；长任务、复杂事务、文件处理和高频数据库写入不一定适合。Preview Deployment 的价值是什么？每个 PR 都能生成独立预览地址，改 UI、验 SEO、看接口环境更快。坑在于 Preview 环境变量和数据库要隔离。

在 Vercel 配自定义域名，流程是进入项目 Settings 的 Domains，添加根域名或子域名，再按提示到 DNS 服务商添加记录。根域名通常指向 Vercel 的 A 记录，www、blog、app 这类子域名一般用 CNAME 指向 cname.vercel-dns.com。DNS 生效后，Vercel 会自动签发和续期 SSL 证书。追问根域名和 www 怎么选？两者都可以，但要选一个主域名，另一个做 301 跳转，避免搜索引擎看到重复页面。SSL 一直 Pending 怎么排查？先检查 DNS 记录是否和 Vercel 提示一致，再看是否有 CAA 记录阻止证书机构签发。Cloudflare 还要确认代理和 SSL 模式。Cloudflare 能和 Vercel 一起用吗？可以，但不要两边都做过多缓存和重写。常见做法是 Cloudflare 管 DNS 和安全策略，应用部署交给 Vercel。上线前最容易漏什么？常漏 301 跳转、旧 URL、Cookie Domain、OAuth 回调地址和搜索控制台验证。域名切换前逐项检查。