先谈谈我对 Nginx 常用命令的真实感受很多新手同行拿到服务器第一件事就是搜“Nginx 常用命令”照着教程敲一遍能启动就以为完事了。实际上命令只是最外面的一层真正决定线上服务稳不稳的是你对 Nginx 工作模型、配置语义和部署流程的理解。这篇文章我想换个角度不写成指令手册的搬运而是把从第一次接触 Nginx 到后来独立维护线上网关这一路上的关键认知、常用命令的真实用法、静态站点和反向代理的完整部署链路以及踩过的坑都串起来。适合刚入门的运维、全栈开发以及那些已经能跑通 Nginx 但遇到问题不知道从哪下手的同学。1. 先搞清楚 Nginx 在服务器上到底扮演什么角色1.1 它解决的核心问题不只是网页服务器四个字很多人把 Nginx 简单理解成和 Apache 一样的网页服务器这个理解没错但太窄了。Nginx 的核心价值在于事件驱动的异步非阻塞模型。传统进程模型下每个连接就要占用一个进程或线程连接一多内存和上下文切换开销就跟着爆炸。Nginx 用一个 master 进程管理一组 worker 进程每个 worker 通过事件循环处理成千上万个连接所以它能在单台低配机器上扛住很高的并发连接数。我最早接手一台只有 2G 内存的云主机上面跑了一个某高校实验平台的静态页面和一个模拟项目X的后端服务。当时用的是默认配置照样能扛住几百人同时访问。后来把连接数压到几千发现内存几乎没有明显上涨这才真正体会到为什么大家说 Nginx 是轻量级高并发的代名词。这个选型背后的逻辑是如果你的业务是大量短连接、静态资源或者网关转发Nginx 的模型天然合适但如果你需要跑复杂的业务逻辑该用后端语言做的事就不要硬塞给 Nginx。1.2 Nginx 与其他 Web 服务的取舍这里不贬低谁只说我在实际选型时的判断标准。对比项NginxApacheCaddy并发模型事件驱动异步非阻塞进程/线程模型为主事件驱动但依赖 Go 运行时配置复杂度中等语法灵活偏复杂指令多极简适合个人站点动态模块加载不支持运行时加载需编译支持部分支持生态资料最多几乎任何问题都有答案老牌资料同样丰富相对较少适合场景生产环境网关、静态服务、反代传统企业环境个人项目、快速部署我现在的习惯是凡是需要长期维护、涉及复杂路由、要做负载均衡和 HTTPS 统一收口的场景一律选 Nginx。Caddy 我也拿来做过个人演示站确实快但真到了生产环境想调 worker 和连接池的时候它的抽象层会让你有力使不出。Apache 在传统企业环境里的模块生态很成熟但新项目里我几乎不会再选它。1.3 理解 Nginx 处理请求的完整链路配置 Nginx 之前先在脑子里建立一条请求链路客户端发起请求 - DNS 解析到你的服务器 IP - 请求到达 80/443 端口 - Nginx 的 master 进程派发给空闲 worker - worker 根据 server_name 和 location 匹配规则选择处理逻辑 - 如果是静态文件直接读磁盘返回如果是代理请求转发给上游服务 - 拿到上游响应后按规则做缓存、压缩、改写最后返回给客户端。这个链路里最容易出问题的是 server_name 匹配和 location 匹配。很多线上事故都是 server_name 没配对请求走到了默认站点或者 location 的正则写错导致所有请求进了同一个处理逻辑。后面我会用案例专门展开。为什么强调先在脑子里过一遍链路因为出了问题你能快速定位是 DNS 层、端口层、匹配层还是转发层的问题而不是瞎试配置。这是我和新手最大的区别。2. 环境准备与安装三条路线各有各的坑2.1 包管理器安装生产环境最推荐的路线不同系统的包管理器命令略有差异但思路一致。Debian/Ubuntu 系sudo apt update sudo apt install nginx -y sudo systemctl status nginxRHEL/CentOS 系sudo yum install epel-release -y # 部分版本需要 sudo yum install nginx -y sudo systemctl status nginx这里多说一句装完之后第一件事不是改配置而是先确认默认页面能访问。你用curl -I http://127.0.0.1看到200 OK说明安装本身没问题后面改配置出错也知道是改出来的问题而不是环境的问题。这个习惯能帮你省掉大量排查时间。包管理器安装的最大好处是目录结构规范、systemd 管理文件已经配好、启动和开机自启都帮你处理完了。但要注意 Debian 系和 RHEL 系的默认配置路径不完全一样Debian 系会把主配置文件拆成/etc/nginx/sites-available和/etc/nginx/sites-enabled两个目录RHEL 系则更多直接写在/etc/nginx/conf.d下面。别拿着 Ubuntu 的习惯去 CentOS 上找sites-enabled找不到就开始怀疑人生其实只是目录约定不同。2.2 Docker 方式适合实验环境和快速编排如果只是本地做个实验或者整个服务栈已经容器化用 Docker 跑 Nginx 是最快的docker run -d --name nginx-demo -p 80:80 -v /path/to/html:/usr/share/nginx/html nginx:stable在编排环境里我通常把 Nginx 作为网关容器通过内部网络连到后端的应用容器配置用挂载卷的方式注入。这样做的好处是环境可复现、回滚方便坏处是调试日志不如宿主机方便docker logs拿到的日志格式和宿主机文件日志不完全一样。我的建议是容器化场景把日志输出到 stdout让编排平台统一收集宿主机部署则老老实实写文件日志。2.3 源码编译只有需要特殊模块时才值得做源码编译安装的最大动机是加入官方发行版里没带或没开启的模块比如你需要一个较新的 HTTP/3 支持或者要编译进第三方的过滤模块。这类需求用包管理器装完再折腾非常痛苦源码编译反而是路径最短的。wget https://nginx.org/download/nginx-1.24.0.tar.gz tar -zxvf nginx-1.24.0.tar.gz cd nginx-1.24.0 ./configure --prefix/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module make -j2 make install这里提醒两个容易翻车的点编译参数一旦确定后面加新模块必须重新编译不能在现有二进制上直接加载新模块。所以编译前把./configure --help的输出认真看一遍把以后可能用上的模块先列进去。编译装出来的是纯二进制没有 systemd 管理文件。你需要手动写一个/etc/systemd/system/nginx.service或者用 nginx 自带的脚本做启停。普通业务场景我建议直接apt install nginx源码编译留给有明确需求的人。2.4 安装完先做的目录盘点不管哪条路线装完都建议执行一次目录盘点ls -l /etc/nginx/ ls -l /etc/nginx/conf.d/ nginx -Vnginx -V的输出里带着编译参数和模块列表很多隐秘问题看一眼这个就能定位。我遇到过一台机器上 Nginx 没有--with-http_realip_module结果所有真实客户端 IP 都显示成了内网网关 IP排查了半天才知道是编译时少了模块。装完先留底后面出问题就少绕路。3. 常用命令的真实用法与最容易翻车的细节3.1 最核心的一组命令建议直接背下来Nginx 常用命令其实不多关键在于知道每条命令触发了什么行为。nginx -t # 检查配置文件语法 nginx -s stop # 立即停止不处理完当前请求 nginx -s quit # 优雅停止等当前请求处理完再停 nginx -s reload # 平滑重载配置不中断服务 nginx -s reopen # 重新打开日志文件常用于日志切割 nginx -V # 查看编译参数和模块版本我最常用的是nginx -s reload。它做的事情是让 master 进程重新读取配置文件、启动新的 worker 进程然后逐步把旧的 worker 进程替换掉。整个过程对客户端几乎无感所以线上改配置根本不需要 stop 再 start。注意nginx -t只是语法检查不代表配置的业务逻辑一定正确。它检查的是这段配置能不能被解析而不是这段配置是不是你想要的行为。比如你把server_name写成了另一个域名语法完全没问题nginx -t照样提示syntax is ok但实际请求就是不进你的站点。3.2 systemctl 与原生命令的使用边界现在主流发行版都用 systemd 管理服务于是很多人混着用systemctl restart nginx和nginx -s reload。这里有个细节经常被忽略操作本质适用场景systemctl start/stop/restart nginx通过 systemd 控制服务生命周期首次启动、彻底重启、开机自启管理nginx -s reload向 master 进程发信号重载配置日常改配置后平滑生效nginx -t语法校验每次改配置后、reload 前必做systemctl reload nginx等价于 nginx -s reload当你习惯用 systemctl 管理时我的习惯是日常更新配置用nginx -t nginx -s reload一条命令搞定语法检查和平滑重载绝对不用 restart。restart 会导致连接瞬间断开如果当时有正在上传的大文件或者长轮询请求直接断掉线上很容易被投诉。改配置的业务量级再大reload 也就一瞬间完成旧 worker 换新 worker。当然如果改了监听端口、改了 worker 数量这种无法热加载的参数reload 不一定生效这时候才需要 restart。判断标准很简单nginx -s reload之后用curl验证一下行为是否符合预期不符合再看 error.log 里有没有提示配置项仅在启动时生效。3.3 信号量日志切割场景下最实用的一组知识Nginx 常用命令里藏着信号量的逻辑-s参数只是对信号量的封装。如果你需要做更精细的操作可以直接用kill向 master 进程发送信号。我项目里最常用的是日志切割# 先把当前日志改名再让 Nginx 重新打开新日志文件 mv /var/log/nginx/access.log /var/log/nginx/access.log.20250101 kill -USR1 $(cat /var/run/nginx.pid)USR1信号让 master 重新打开日志文件这样旧日志已经被挪走新请求会写进新建的 access.log你就拿到了一份干净的切割日志。配合 crontab 每天凌晨执行日志管理基本不用人工操心。USR2信号可以平滑升级二进制比较冷门但理解它的思路对排查问题有帮助——Nginx 所有的平滑操作本质上都是 master 进程 fork 新 worker 再逐步替换旧 worker而不是简单粗暴地杀进程重来。3.4 配置校验和 reload 前必做的检查清单长期跟 Nginx 打交道我给自己定了一条铁律任何配置改动上线前必须按这个顺序过一遍。cp备份旧配置防止改错回不去。修改配置文件后用nginx -t检查语法。确认syntax is ok后执行nginx -s reload。reload 后用curl -I访问几个关键路径确认返回状态符合预期。观察 error.log 一到两分钟确认没有异常告警。很多人改完配置直接 reload报错了才想起看 log这其实是在用线上流量给自己当测试环境。把检查清单固定下来之后我的 Nginx 相关线上事故率基本降到了零。这个习惯花不了两分钟但能拦住绝大多数低级错误。4. 部署详解静态站点与前端项目的完整上线链路4.1 最小可用配置先跑通再说优化假设你有一个静态站点目录/var/www/mysite里面放了index.html。在/etc/nginx/conf.d/mysite.conf里写server { listen 80; server_name mysite.example.com; root /var/www/mysite; index index.html; location / { try_files $uri $uri/ 404; } }这里最关键的是try_files $uri $uri/ 404这一行。它的意思是先按请求的 URI 找文件找不到就按目录找还找不到就返回 404。很多新手直接写location / { }空规则结果访问子路径时全部 404就是因为没让 Nginx 去尝试目录下的 index 文件。server_name决定了哪个域名进入这个站点。如果你本机测试不想配域名可以用server_name _;表示默认站点或者用server_name localhost;测试。生产环境千万别用下划线默认值接收所有域名因为那会把别人解析到你 IP 的未知域名也导进你的站点容易出安全问题也容易被搜索引擎收录奇怪的内容。4.2 前端项目打包部署history 路由的必须配置现在主流前端项目构建后都会生成一堆带 hash 或不带 hash 的静态文件。直接扔进上面那个配置里首页能开但一刷新子路由就 404。比如你访问https://mysite.example.com/dashboard前端路由是 history 模式浏览器会向服务器请求/dashboardNginx 在磁盘上找不到这个文件直接返回 404。解决办法是加一条回退规则location / { root /var/www/mysite; index index.html; try_files $uri $uri/ /index.html; }注意最后一项从404变成了/index.html。意思是找不到对应文件或目录时把所有请求都送回index.html由前端路由接管。这个配置是前端单页应用部署的标配但我见过太多人漏了它导致项目一刷新就白屏或 404。如果你部署的是 Vue 或 React 项目并且用了 history 路由几乎必定会遇到这个问题。同时要处理静态资源的缓存策略。带 hash 的文件名比如app.8f3k2.js内容一变名字就变可以放心长缓存不带 hash 的index.html必须禁用缓存否则用户更新后看到的还是老页面。location /assets/ { root /var/www/mysite; expires 30d; add_header Cache-Control public, immutable; } location / { root /var/www/mysite; try_files $uri $uri/ /index.html; add_header Cache-Control no-cache; }这样配置之后用户每次打开都是新 index.html再加载带 hash 的静态资源旧资源已经被本地缓存命中速度和更新体验都兼顾了。这个组合拳是我认为前端部署里性价比最高的优化。4.3 压缩与传输优化直接照着抄就能提升首屏速度静态站点部署里性价比最高的优化就是开启 gzip。Nginx 默认没开或者只开了部分类型。推荐一段我常用的配置gzip on; gzip_vary on; gzip_comp_level 5; gzip_min_length 1k; gzip_proxied any; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xmlrss text/javascript image/svgxml;gzip_comp_level 5是我实测过后性价比最高的档位。1 到 9 之间数字越大压缩率越高但 CPU 消耗也越大到 6 以上压缩率提升已经不明显了反而拖慢响应。gzip_min_length 1k的意思是小于 1KB 的文件不压缩因为压完可能更大。图片本身已经是压缩格式就不要放进 gzip_types 里浪费 CPU 了SVG 除外SVG 是文本压缩收益很大。如果站点已经上了 HTTPS还可以考虑开启 HTTP/2把listen 443 ssl http2;配置在 server 块里多路复用对大量小文件的加载场景提升非常明显。我在一个图片较多的门户站上实测开启 HTTP/2 后首屏加载时间大约降了 30%这个收益是实打实的。4.4 发布与权限最容易翻车的最后一公里配置文件写好了把静态文件放到服务器上是部署的最后一公里。这里有个常年踩坑的点Nginx 的 worker 进程以nginx用户运行如果站点目录属于 root 且权限是 700Nginx 就读不到文件浏览器直接 403 Forbidden。我验证过的一个标准做法sudo mkdir -p /var/www/mysite sudo chown -R $USER:$USER /var/www/mysite # 你用自己的账号上传文件 sudo chmod 755 /var/www/mysite # 目录要能进入上传文件建议用 rsync 而不是直接覆盖整个目录断点续传和差异对比都更可靠rsync -avz --delete dist/ userserver:/var/www/mysite/--delete会把目标目录里服务器上多余的文件删掉保证线上内容和你构建产物完全一致。第一次用这个参数的人都会慌怕误删其实只要源目录是完整的构建产物这就是最干净的发布方式。我现在的发布脚本基本是构建完自动 rsync 上去全程手动操作反而容易漏。5. 反向代理与负载均衡案例一组后端服务的统一入口5.1 反向代理的本质和最小配置对于后端服务Nginx 最常见的角色是反向代理。后端服务一般监听内网端口比如 Node 服务跑在127.0.0.1:3000Nginx 监听 80 端口接收外部请求再转发给 3000。server { listen 80; server_name api.example.com; location / { proxy_pass http://127.0.0.1:3000; 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; } }proxy_pass是转发目标proxy_set_header把真实客户端信息传给后端。没有X-Real-IP和X-Forwarded-For的话后端日志里看到的全部是 Nginx 所在机器的 IP排查用户来源时一片茫然。这个细节在审计和风控场景里尤其要命。5.2 proxy_pass 结尾斜杠的致命陷阱反代配置里我见过最多的问题不是语法错而是proxy_pass的 URI 拼接规则。很多人分不清这两行# 写法 A不带 URI location /api/ { proxy_pass http://127.0.0.1:3000; } # 请求 /api/users 会转发成 http://127.0.0.1:3000/api/users # 写法 B带 URI location /api/ { proxy_pass http://127.0.0.1:3000/; } # 请求 /api/users 会转发成 http://127.0.0.1:3000/users规律是proxy_pass后面只要带了路径哪怕只是一个/location 匹配到的部分就会被替换成 proxy_pass 里的路径。写法 B 是很多后端接口设计的常规需求——前端统一走/api/前缀但后端服务不需要这个前缀。这个坑不会报错但接口全 404新手排查半小时起步。我在一个模拟项目X里就犯过这个错误前端所有请求都在报错后端日志却干净得很最后才发现是转发路径里多了一个斜杠。5.3 完整案例某模拟项目X的前端 多实例后端为了把案例串起来我设计一个常见场景某模拟项目X前端静态文件部署在 Nginx 上后端有两个实例一个主实例、一个备用实例分别监听127.0.0.1:8081和127.0.0.1:8082数据库独立部署。完整配置如下upstream projectx_backend { server 127.0.0.1:8081 weight2; server 127.0.0.1:8082 backup; keepalive 32; } server { listen 80; server_name projectx.example.com; root /var/www/projectx; index index.html; gzip on; gzip_types text/plain text/css application/javascript application/json; gzip_comp_level 5; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://projectx_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; proxy_connect_timeout 5s; proxy_read_timeout 10s; } }这里讲几个关键设计upstream定义后端服务器池weight2表示 8081 分担双倍流量backup表示 8082 平时不接流量只有 8081 挂了才顶上。这是主备 权重的典型写法既能保证正常流量集中在性能更好的机器上又能在故障时自动切换。keepalive 32配置了 Nginx 到后端的空闲连接池能显著降低频繁建立 TCP 连接的开销。注意keepalive指令只在upstream块里有效很多人把它写到location里完全不生效。这个参数对短请求特别多的 API 网关场景提升非常明显。proxy_connect_timeout 5s是连接后端的超时单位默认是秒。如果后端服务启动很慢或者经常处于过载状态这个参数要调大一点否则网关会直接返回 502。5.4 502 和 504 的完整排查链路反代场景里502 Bad Gateway 和 504 Gateway Timeout 是最常见的。遇到 502 先别慌按下面的链路查先看后端进程是否存活curl http://127.0.0.1:8081/health如果后端自己都连不上问题在后端不在 Nginx。如果后端活着但 Nginx 还是 502多半是 Nginx 的 worker 进程连不上后端端口。用ss -tnp | grep 8081确认监听状态。再查 Nginx 错误日志tail -f /var/log/nginx/error.log。常见的报错会有connect() failed (111: Connection refused)或者upstream prematurely closed connection。确认防火墙规则有没有误伤iptables -L -n看看本机端口是否被挡。最后确认/etc/nginx/conf.d/下的配置语法没问题nginx -t过一遍。我遇过一次很有意思的 502后端服务没挂但系统文件句柄数满了Nginx 无法建立新连接。ulimit -n一看是 1024流量一旦上来就爆。后来把worker_rlimit_nofile调大并把系统的LimitNOFILE改掉才彻底解决。所以 502 不一定只是后端挂了也可能是资源限制。504 则通常是proxy_read_timeout太短。后端接口本身要跑几十秒Nginx 默认 60 秒以内还好但如果接口是报表导出、批量任务这类耗时操作90 秒也是常事需要按接口特性单独放宽location /api/export/ { proxy_pass http://projectx_backend/; proxy_read_timeout 300s; proxy_send_timeout 300s; }长耗时接口单独加长超时其他接口保持短超时让故障能快速暴露而不用傻等这是一种很实用的运维思维。不要图省事把所有接口的超时都调到 300 秒那样一旦后端出问题用户要等五分钟才看到错误页面体验会更差。6. HTTPS 配置与部署上线的最后一次检查6.1 用免费证书把站点切到 HTTPS现在的应用基本都要求 HTTPS配置思路是先拿到证书文件然后在 Nginx 里加一个 443 的 server 块再把 80 端口的请求重定向到 443。证书推荐用 ACME 客户端自动申请和续期整个过程可以做到全自动。网上各家 CA 签发教学流程都差不多这里只说 Nginx 侧的关键配置server { listen 443 ssl http2; server_name projectx.example.com; ssl_certificate /etc/nginx/ssl/projectx.example.com.pem; ssl_certificate_key /etc/nginx/ssl/projectx.example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers on; # 其余 location 配置和 80 端口保持一致复制过来即可 }配置里ssl_session_cache也建议开起来对重复握手的性能提升很明显ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m;80 端口那边做一条永久重定向server { listen 80; server_name projectx.example.com; return 301 https://$host$request_uri; }return 301比rewrite更干净处理这个需求首选它。配完之后记得检查一遍证书有效期ACME 客户端通常会自动续期但续期后有时需要 reload 才能生效。在 crontab 里加一条续期后执行nginx -s reload的命令可以避免证书更新了但 Nginx 还持有旧证书的问题。我见过不止一次证书文件明明过期了Nginx 却一直用着内存里的旧证书用户浏览器报安全错误最后 reload 一下立刻恢复。6.2 一个稳健的安全加固清单上线前的最后一步我习惯按这份清单过一遍server_tokens off;关闭版本号泄露防止别人根据版本挖已知漏洞。add_header X-Content-Type-Options nosniff;防止浏览器对响应内容做 MIME 类型嗅探。对上传目录限制执行权限比如location /uploads/ { location ~ \.php$ { deny all; } }防止上传文件被当作脚本执行。隐藏.git、.env、备份文件等敏感路径location ~ ^/(\.git|\.env|.*\.bak|.*\.swp) { deny all; return 404; }这里用return 404而不是deny all的原因是deny all会返回 403等于告诉对方这个路径存在但不给看return 404则是假装不存在信息泄露更少。还有一种情况是开发时的临时文件被一起传上去了比如nginx.conf.bak这种文件里经常带着密码或者内网路径务必要在发布脚本里做一次清理。如果接口只接受 JSON可以在location /api/里只允许 GET/POST并把其他请求方法挡掉if ($request_method !~ ^(GET|POST)$) { return 405; }这些措施不一定每条都适用但属于投入产出比极高的基础加固。很多团队出安全事故查下来无非就是版本号泄露、敏感文件可访问、上传目录可执行这几类。把这些基础的做好了再往上谈纵深防御才有意义。6.3 日志里的运维线索两条命令解决大多数问题Nginx 的 access.log 和 error.log 是排错的两大宝库。我排错时的习惯是先看 error.log 定位系统级错误再看 access.log 看请求是否真的到达了 Nginx。# 实时看错误日志请求异常时能立刻看到 tail -f /var/log/nginx/error.log # 看最近几分钟内返回 5xx 的请求 tail -50 /var/log/nginx/access.log | awk $9 500 {print $0}日志格式也可以在配置里自定义加上响应时间和上游耗时对性能分析非常有用log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for $request_time $upstream_response_time; access_log /var/log/nginx/access.log main;$request_time是 Nginx 处理整个请求的总耗时$upstream_response_time是后端服务的响应耗时。两者差得大说明瓶颈在 Nginx 到后端的链路或者 Nginx 自身两者接近瓶颈基本就在后端。这个字段组合帮我定位过好几次前端说接口慢后端说我没慢的扯皮问题拿数据说话比什么都管用。最后再分享一条我自己的操作习惯每次改完 Nginx 配置一定要在浏览器无痕窗口里完整走一遍核心功能而不是只在服务器上 curl 首页。因为 curl 只能验证响应状态验证不了真实用户场景下的路由跳转、静态资源加载、HTTPS 证书链路这些更深的问题。前几年我改过一次安全响应头把Content-Security-Policy写得太严curl 200页面却全被浏览器拦截无法显示所有用户都在骂。那次之后我就把无痕窗口全流程验证写进了每次上线的固定动作里。Nginx 这门手艺说难不难说简单也不简单。命令就那么几条配置指令再多也有章可循真正拉开差距的是你对请求链路的理解深度以及排错时有没有一套稳定的方法。希望这篇从命令到部署再到案例的完整梳理能让你少走几步我曾经走过的弯路。