nginx的口都access_log默认只写在http块里，server块不写就继承——很多人栽在这上面。加上上周帮一个电商客户排查问题，访问他们新上的日志活动页面半夜卡成PPT，查了半天，口都发现那个server块压根没开访问日志。加上所有请求都像掉进黑洞，访问连个影子都留不下。日志

你得理解nginx的口都配置继承逻辑。http块是加上全局的，server块如果没单独写access_log，访问就沿用http里的日志。但一旦某个server块里写了别的口都日志路径，其他没写的加上server就麻烦了——它们会继承那个被改过的配置，而不是访问你最初设的默认值。这坑我踩过不止一次。

具体到端口，80和443要分开记。别图省事全塞一个文件里。我见过有人把80端口和443端口的日志混着写，结果排查HTTPS证书问题时，得在一堆HTTP明文请求里翻半天。分开写，每个端口一个日志文件，出问题直接grep对应端口，效率翻倍。

日志格式也别偷懒。默认的combined格式够用，但如果是API服务，我建议加上$request_time和$upstream_response_time。有一次客户说接口慢，我看日志里$request_time全是0.8秒以上，但$upstream_response_time只有0.1秒——说明瓶颈在nginx和上游之间的网络，而不是后端代码。这俩字段不写，这种问题得靠猜。

还有个细节，日志要带端口号本身。比如log_format里加上$server_port，这样即使你多个server块共用同一个日志文件，也能一眼看出请求打在哪个端口上。别嫌冗余，生产环境出问题的时候，多一个字段就多一条线索。

有人觉得访问日志占磁盘，想省。省可以，但你得知道省的是什么。我见过一个团队把日志级别调到warn，结果线上出故障时，连最基本的请求记录都没有，只能靠猜。访问日志是你排查问题的第一手现场，省了这个，等于蒙着眼睛修车。

实操层面，每个server块里都明确写一行access_log，别依赖继承。哪怕路径跟http块一样，也写出来。这样后来接手的人一看就知道这个端口有日志，不用去翻父配置。我习惯这么写：

server {  listen 8080; access_log /var/log/nginx/8080.access.log main; ... } 

最后说一句，日志轮转也要跟上。不轮转的话，文件涨到几个GB，nginx写日志都变慢，影响性能。logrotate配上，按天切分，保留30天，够了。

端口没日志，出问题就是两眼一抹黑。写上行代码的事，别等出了事故再补。