一、先搞懂面试官到底想考什么标题是“nginx和docker面试题”但凡是面过后端、运维或者DevOps岗的朋友都清楚这两个技术栈几乎是必考组合。Nginx是流量入口Docker是部署底座一个管“怎么把请求接进来”一个管“怎么把服务跑起来”两者一起问面试官真正想看的其实是你对现代Web服务从请求到部署整条链路的理解程度而不是单纯背几个配置文件。很多人在准备这类面试题时有个误区就是疯狂刷真题、背命令。我见过不少候选人能把docker run的参数倒背如流问到镜像分层机制就哑火也有人nginx配置背得滚瓜烂熟让他讲讲worker_processes到底设多少、为什么就支支吾吾。面试官不傻背出来的答案和一问就透的答案几分钟就能分辨出来。这篇文章我就按面试的高频考点来拆把nginx和docker分头讲透再讲两者联动的组合场景最后给一套排查思路和备考路径。内容不追求面面俱到但凡是高频考到的点我会尽量把原理、配置、坑都讲清楚保证你看完能应付大多数场子。二、Nginx核心考点从配置语法到进程模型2.1 反向代理和负载均衡不只是配个proxy_passNginx最核心的使用场景就是反向代理和负载均衡。面试时几乎必问“正向代理和反向代理有什么区别”或者“Nginx是怎么做负载均衡的”。前者背一下概念就能过后者需要你真懂。正向代理是代理客户端比如你在公司内网上不了外网通过一台代理服务器出去服务器不知道请求来自谁。反向代理是代理服务端客户端访问的是反向代理服务器它再把请求转发给后面的真实服务器客户端根本不知道真实服务器的存在。Nginx在Web架构里基本都是当反向代理用顺手承担负载均衡、SSL终止、静态资源托管这些活。负载均衡的配置极其简单一个upstream块加几行server指令就搞定upstream backend { server 192.168.1.101:8080 weight3; server 192.168.1.102:8080 weight1; server 192.168.1.103:8080 backup; } server { listen 80; server_name example.com; location / { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }但配置简单不代表原理简单。默认的负载均衡算法是轮询每个请求按时间顺序逐一分配到不同的后端服务器。weight参数可以调整权重权重高的服务器被分配更多的请求适合处理能力不等的服务器集群。backup标记的是备用服务器平时不参与服务只有当其他非备用服务器都挂掉时才接手流量。还有几种常见的调度算法ip_hash根据客户端IP的哈希结果分配服务器保证同一个IP的请求始终打到同一台后端解决Session共享问题least_conn优先分配给当前连接数最少的服务器适合请求处理时间差异大的场景。面试官如果追问“你项目中用的哪种算法为什么”一定要能说清楚选择依据而不是只会背名字。实际项目中我建议把proxy_set_header这几行默认加上。Host头如果不带后端拿到的是Nginx的地址而不是真实域名很多基于域名的虚拟主机应用会直接404X-Real-IP和X-Forwarded-For是给后端传递客户端真实IP的否则后端日志里全是Nginx的IP排查问题时会非常痛苦。2.2 location匹配规则最容易翻车的细节location是nginx配置里最容易被问细节的指令因为匹配规则多优先级容易记混。面试官常见的问法就是“location /和location /有什么区别”或者“给你一段配置问你某个请求会匹配到哪个location”。匹配规则一共五种优先级从高到低分别是location /uri精确匹配完全相等才命中location ^~ /uri前缀匹配命中后不再检查正则location ~ pattern正则匹配区分大小写location ~* pattern正则匹配不区分大小写location /uri普通前缀匹配这里有个关键点普通前缀匹配和正则匹配的优先级不是简单按顺序比较的。Nginx的处理逻辑是先遍历所有普通前缀匹配的location记住最长匹配的那一个然后再按顺序检查正则location如果某个正则匹配上了就覆盖前面选中的前缀匹配结果如果正则全没匹配上才用之前记下的最长前缀匹配。之所以^~要单独拎出来就是为了告诉Nginx“这个前缀匹配已经够了不用再去看正则了”。举个容易踩坑的例子location /api { proxy_pass http://backend_api; } location ~* \.php$ { proxy_pass http://backend_php; }请求/api/user.php会被哪个location处理答案是第二个正则匹配因为正则的优先级高于普通前缀匹配。如果你本意是让所有/api开头的请求都走backend_api那你必须写成location ^~ /api才行。这个坑我在实际项目里踩过接口时不时被莫名转发到PHP服务排查了半天才发现是location优先级的问题。2.3 进程模型与性能参数从Nginx原理到调优面试问到Nginx原理通常就两个方向为什么Nginx性能好以及怎么调优。要回答清楚绕不开进程模型。Nginx启动后会有一个master进程和多个worker进程。master负责读取配置、管理工作进程比如平滑加载配置、平滑升级二进制文件worker进程才是真正处理请求的每个worker都独立监听同一组端口。收到新连接时多个worker会通过锁机制竞争谁抢到谁处理不过Nginx 1.9.13之后默认开启了reuseport内核直接把新连接分发给不同的worker锁竞争的开销大幅下降。关于worker进程数量最稳妥的设置是设为服务器CPU核心数也可以直接用auto让Nginx自动检测。设少了浪费CPU设多了反而会因为上下文切换增加开销。worker_connections这个参数单看名字容易误解它不是单个worker能接受的连接总数而是单个worker能同时打开的最大连接数这个数值里还包括了Nginx与后端服务器之间的连接所以是同时包含“客户端到Nginx”和“Nginx到后端”两个方向的。综合起来Nginx的最大并发连接数大致等于worker_processes * worker_connections / 2之所以除2是因为每个客户端请求最少占用两条TCP连接。还有两个面试高频参数。keepalive_timeout控制客户端与Nginx之间的长连接超时时间Web界面通常建议65秒keepalive_requests设置单个长连接上最多能处理的请求数默认1000对于高并发的接口服务可以适当调大。但如果Nginx后面还有一层负载均衡器比如阿里云的SLB或腾讯云的CLBkeepalive的设置就要考虑多层设备之间的配合每层的超时时间要形成梯度避免出现连接被中间层断开的情况。性能调优这块面试官很少让人现场调参更多是问思路。你要能从进程模型讲到参数含义再讲到瓶颈分析比如用nginx -t验证配置语法用nginx -s reload平滑重载配置用stub_status模块查看实时连接数。这样一套下来基本能体现出你真正在用Nginx而不是只看过文档。三、Docker核心考点从镜像分层到容器生命周期3.1 镜像和容器的关系以及Dockerfile分层机制Docker的面试题范围很大但万变不离其宗最基础的那道必考题就是“镜像和容器的区别”。一句话版本是镜像是静态的模板容器是镜像运行时的实例。展开来镜像是一个只读的文件系统集合包含运行应用所需的一切代码、运行时、系统工具、库文件、配置全都有容器是在镜像之上加了一层可写层运行中的进程读写都发生在这一层。但如果面试官继续追问“那Docker的镜像分层机制是怎么回事为什么拉镜像时有些层能复用”你就需要把底层原理说清楚。Docker镜像由多层只读层组成每一层对应Dockerfile里的一条指令。比如FROM node:18-alpine WORKDIR /app COPY package.json ./ RUN npm install COPY . . CMD [node, server.js]这个Dockerfile会生成多层FROM是基础层WORKDIR修改工作目录并创建一层元数据COPY package.json把文件复制进去生成一层RUN npm install安装依赖又生成一层后面的COPY和CMD再各占一层。每层只记录与前一层的差异。分层机制最大价值是缓存和复用。同一个基础镜像在构建不同应用时可以被共享拉取时网络传输量也小本地构建时如果Dockerfile的前面几条指令没变Docker会直接复用之前构建的缓存层只有发生变更的层和它后面的层才会重新执行。这也是为什么我强烈建议把package.json和源码分开COPY先装依赖再复制代码这样只要package.json不变即源码变了也只会重新COPY源码那一层npm install直接走缓存构建速度能快不少。有一个很容易被忽视的坑RUN层缓存失效的问题。假设你在Dockerfile里写了RUN apt-get update apt-get install -y xxx如果上一个RUN指令的缓存没失效这个apt-get update很可能会被跳过导致安装的软件包版本不是最新的甚至在某些情况下会报404。解决办法是在更新源之后立刻安装中间不要插入其他会变化的内容。这也是经验老道的人写Dockerfile时特别注重的细节。3.2 容器网络模式不只是bridge和hostDocker的网络模式是面试高频题尤其是bridge、host、none三种基本模式的区别基本是送分题。bridge是默认模式容器通过虚拟网桥docker0与宿主机通信端口需要映射才能被外部访问host模式直接共享宿主机的网络命名空间容器内的端口就是宿主机的端口性能好但隔离性差none模式没有网络配置适合完全不需要网络的场景。容易被追问的是自定义bridge网络。默认的bridge网络下容器之间只能通过IP访问而且每次容器重建IP会变化非常不实用。自定义bridge网络自带DNS解析同一网络内的容器可以直接通过容器名互相访问这才是多容器协作的正确姿势。比如nginx容器要反向代理一个名叫app的容器proxy_pass http://app:8080就能直接解析完全不需要关心容器的IP。docker network create mynet docker run -d --name app --network mynet myapp:latest docker run -d --name nginx --network mynet -p 80:80 nginx:latest还有一个必须掌握的点docker run -p 80:8080后面的端口到底是谁的。很多新手会搞反前者是宿主机端口后者是容器内端口。容器的端口映射在隔离网络里才能把服务暴露给外部这是面试考网络时的常客。3.3 数据持久化与容器状态管理容器是无状态的容器删了里面的数据就没了这是Docker面试里非常基础且重要的认知。面试官很爱问“容器删了数据还在吗”以及“如何做数据持久化”答案就是volume数据卷或bind mount绑定挂载。volumes由Docker管理推荐用于数据库数据、日志等需要可靠持久化的场景docker volume create pgdata docker run -d --name postgres -v pgdata:/var/lib/postgresql/data -p 5432:5432 postgres:15这里pgdata可以是命名的volumeDocker会自动创建也可以直接用宿主机路径的bind mount写法是-v /宿主机路径:/容器路径。bind mount的好处是宿主机上直接能编辑文件适合配置文件、开发环境的热更新坏处是宿主机和容器耦合度高迁移不灵活。还有两条高频命令需要辨析docker commit和docker save。docker commit把容器当前状态打包成新镜像可以理解为快照但生产环境不推荐用这种方式发布镜像因为它无法复现构建过程docker save是把镜像导出成tar文件用于离线迁移。两个命令名字像但一个是容器到镜像一个是镜像到归档文件考的就是这种细节区别。四、组合场Nginx和Docker联动的高频场景4.1 Nginx容器化部署的几个关键细节Nginx本身也能容器化运行这是Docker和Nginx组合最直接的场景。标准写法是docker run -d --name nginx \ -p 80:80 -p 443:443 \ -v /data/nginx/conf.d:/etc/nginx/conf.d \ -v /data/nginx/html:/usr/share/nginx/html \ -v /data/nginx/logs:/var/log/nginx \ nginx:alpine挂载conf.d目录之后宿主机上新放一个*.conf文件执行docker exec nginx nginx -s reload就能生效不用重新构建镜像也不用重启容器。这是Nginx容器化最核心的操作思路镜像本身不可变但配置要可挂载、可热更新。需要注意的口径是nginx官方镜像里/etc/nginx/conf.d/下面默认有一个default.conf里面配置了listen 80的默认站点。如果你把自己的站点配置也挂载到conf.d两个文件可能会出现端口冲突。解决方法是挂载前先把默认的default.conf删掉或者干脆用-v /宿主机站点配置:/etc/nginx/conf.d/default.conf覆盖掉它。另一个常见坑是日志时区问题。nginx容器默认使用UTC时间宿主机是北京时间的话容器日志时间和宿主机时间会差8个小时。排查问题时对不上时间特别难受。解决方法很简单挂载时把宿主机的/etc/localtime也挂进去-v /etc/localtime:/etc/localtime:ro。4.2 容器编排中的Nginx角色定位当服务变成多个容器比如前端一个容器、后端两个容器、数据库一个容器Nginx的角色就变成容器环境里的入口网关。使用docker compose编排时典型的配置是version: 3.8 services: nginx: image: nginx:alpine ports: - 80:80 - 443:443 volumes: - ./nginx/conf.d:/etc/nginx/conf.d depends_on: - app1 - app2 app1: build: ./app expose: - 8080 app2: build: ./app expose: - 8080nginx配置文件里的proxy_pass直接指向服务名upstream app_servers { server app1:8080 weight2; server app2:8080 weight1; } server { listen 80; location / { proxy_pass http://app_servers; } }这是docker compose自带DNS解析的典型用法nginx容器和app容器处于同一个网络直接通过服务名访问对应容器。注意expose只是声明容器对外暴露的端口号并不发布到宿主机真正发布端口只有nginx容器的ports这样就实现了外部流量只进nginx内部服务不直接暴露。这个组合模式现在几乎是生产标准的雏形。面试官问到“你在项目中怎么部署多个服务的”如果你能说出这套方案并且解释清楚为什么nginx要作为唯一的入口说明你对容器网络和流量模型是有完整认知的。4.3 健康检查与优雅重启生产可用的关键操作容器编排里Nginx作为入口必须配合健康检查机制才能保证高可用。docker compose里可以这样配置services: app1: healthcheck: test: [CMD, curl, -f, http://localhost:8080/health] interval: 10s timeout: 3s retries: 3nginx的upstream块中也可以配置被动健康检查比如upstream app_servers { server app1:8080 max_fails2 fail_timeout30s; server app2:8080 max_fails2 fail_timeout30s; }max_fails表示允许失败的次数fail_timeout表示在多少秒内算作失败窗口以及失败后标记不可用的时长。这个参数的意义在于当某台后端容器异常退出或接口报错达到阈值nginx会在一段时间内不再把请求转发给它等它恢复后再自动加回来。这一套机制在容器重启、应用发布期间能极大减少对用户的影响。优雅重启也是生产环境的必考题。docker方式下nginx配置变更后的标准操作是docker exec nginx nginx -s reload这个命令会让nginx的master进程重新加载配置然后平滑地重启worker进程。因为是平滑重载正在处理的请求不会中断新请求才走新配置这是nginx最实用的特性之一。注意不要用docker restart nginx去重启那会断开所有连接造成流量抖动。五、面试必备的高频题与实操模板5.1 手写nginx配置的“标准答案”模板面试中经常出现“现场写一个nginx配置实现反向代理到后端服务”这种题。我建议背熟一套结构完整、有注释的模板考试时直接套用再根据题意增减。worker_processes auto; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; # 日志格式 log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for; upstream backend_servers { server 10.0.0.2:8080 weight3; server 10.0.0.3:8080 weight1; keepalive 32; } server { listen 80; server_name www.example.com; access_log /var/log/nginx/access.log main; location / { proxy_pass http://backend_servers; proxy_http_version 1.1; proxy_set_header Connection ; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /static/ { alias /data/www/static/; expires 7d; } } }这套模板里隐藏了几个加分点。proxy_http_version 1.1和proxy_set_header Connection 配合upstream里的keepalive 32是让nginx和后端服务器之间复用长连接的关键配置。默认情况下nginx和后端通信用的是HTTP/1.0每次请求都新建TCP连接大量请求时握手开销很浪费改成长连接以后性能和延迟都有明显改善。这个点属于“配置谁都会写但只有真做过的人才知道为什么要写”。location /static/配合alias和expires 7d是静态资源缓存优化面试官看到你对静态资源分离有意识印象分会明显提升。5.2 Dockerfile书写的经验与优化方法手写Dockerfile也是高频题。面试官给的场景一般就是“把一个Node/Java应用容器化”考察点除了能写出来还有是否懂得优化。一个合理的Node应用Dockerfile应该是FROM node:18-alpine AS builder WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci --onlyproduction FROM node:18-alpine WORKDIR /app COPY --frombuilder /app/node_modules ./node_modules COPY . . USER node EXPOSE 3000 CMD [node, server.js]这里面有几组关键优化技巧。npm ci比npm install更严格会严格按照锁文件安装保证构建可复现。多阶段构建可以分离依赖安装和运行环境减小最终镜像体积。COPY --frombuilder只复制需要的产物。USER node避免使用root用户运行容器安全加固。面试官如果往下追问“怎么给镜像瘦身”可以回答两条路径一是使用轻量基础镜像比如alpine或者带-slim后缀的版本二是清理构建缓存和临时文件比如RUN npm install npm cache clean --force。如果你能说出一条关键判断标准比如“体积大一般出在基础镜像选型和安装包缓存上”基本上这题就是稳过。5.3 经典排查题502 Bad Gateway、404、连接拒绝面试官很喜欢用线上故障场景来考察实战能力nginx docker场景下的经典报错就那么几个背熟答案和排查路径就够用。502 Bad Gateway是出现率最高的。nginx向后端发起请求时后端没有给出正常响应。排查顺序一般是先确认后端容器是否在运行docker ps再看后端服务日志docker logs确认应用是崩溃还是接口超时然后看nginx错误日志/var/log/nginx/error.log里有没有connect() failed或者upstream prematurely closed connection的字样。如果是connection refused说明后端端口监听有问题如果是timed out说明后端处理太慢nginx等待超时可能需要调大proxy_read_timeout。404则分两种情况。如果是根路径访问404先确认nginx里的location /是否配置正确proxy_pass后面的路径是否带了/这个细节很多人会忽略。打个比方proxy_pass http://backend;会把原始URI完整传给后端而proxy_pass http://backend/;URI中的匹配部分会被替换成/两种行为完全不同。如果是带路径的接口404要重点检查后端的路由是否匹配得上因为nginx没有改URI的话是不应该404的。连接拒绝还有一种情况是容器没有暴露端口。比如后端容器运行了但忘记用-p映射端口宿主机上访问对应端口就会报connection refused。这类问题的排查思路是先用docker port 容器名查看端口映射这是检验Docker基本功很好的题目。排查题能答好比背任何八股都有说服力因为面试官知道只有真正处理过线上故障的人才能有这么清晰的排查路径。六、备考思路与私房经验准备nginx和docker面试题不建议按题海战术刷。面试题是无限的但知识点是有限的重要的是建立知识之间的关联。我自己的方法是把整套知识画成一个模型外部请求进来经过nginx这一层它负责路由、负载、转发、缓存请求到了docker容器层它负责隔离环境、提供运行依赖、管理生命周期。两个技术栈本质是协作关系理解了这个协作逻辑面试题再怎么变都跑不出这个框架。还有一个经验是面试时如果被问住了不要慌尝试用“排查思路”来替代“标准答案”。比如问“Nginx worker_processes你们设了多少”如果你没看过自己项目的配置完全可以说生产环境我一般先设成CPU核心数或者auto然后在压测时观察每个worker的CPU利用率和连接数根据瓶颈调整。这样做比瞎给一个数值靠谱得多面试官反而会觉得你真的在思考。从我面试别人的经验来看回答技术问题时能主动说出“为什么”的候选人特别稀缺。比如讲到docker网络时说“自定义bridge网络自带DNS解析所以容器之间能用名字互通”的人比只会列命令的人强出不少。所以备考时每记住一个知识点都问自己一句“为什么是这样”这比多背十道题都管用。最后再分享一个小技巧面试现场让手写配置时不要急着写先把整体结构在脑子里过一遍再动笔。写出结构完整的配置框架比写一堆零碎命令更抓分。我个人在实际面试中看候选人写nginx配置最看重的就是有没有那种“整块思维”而不是东一句西一句地堆指令。