☰

企业官网建设流程全解析

首页 / 建站日记 / 企业官网建设流程全解析
Nginx CORS配置详解与最佳实践
2026/10/24 5:30:05 网站建设 项目流程

1. 跨域访问与CORS核心原理

当你在浏览器控制台看到"已拦截跨源请求：同源策略禁止读取位于xxx(原因：CORS头缺少'Access-Control-Allow-Origin')"这样的报错时，说明你遇到了典型的跨域问题。现代Web开发中，前后端分离架构已成为主流，这就使得跨域访问成为每个开发者必须面对的挑战。

同源策略（Same-Origin Policy）是浏览器最基本的安全机制之一，它要求脚本只能访问与文档同源的资源。这里的"同源"指的是协议、域名和端口号完全相同。例如：

  • https://example.com/app1和https://example.com/app2是同源
  • http://example.com和https://example.com不同源（协议不同）
  • example.com和api.example.com不同源（域名不同）
  • example.com:80和example.com:8080不同源（端口不同）

CORS（Cross-Origin Resource Sharing）机制就是为了在保证安全的前提下，解决跨域访问问题而设计的。它的核心思想是：服务器通过特定的HTTP头部告诉浏览器，哪些外部源可以访问自己的资源。

重要提示：CORS是浏览器的安全机制，服务器之间直接通信（如cURL、Postman）不会触发CORS限制。这也是为什么你在Postman测试API正常，但在浏览器中却报错的原因。

2. Nginx中的CORS配置详解

2.1 基础CORS配置

在Nginx中配置CORS主要通过在响应中添加特定的HTTP头实现。以下是一个最基本的配置示例：

server { listen 80; server_name api.example.com; location / { # 允许所有来源访问（生产环境应限制为特定域名） add_header 'Access-Control-Allow-Origin' '*'; # 允许的HTTP方法 add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; # 允许的请求头 add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range'; # 预检请求结果缓存时间 add_header 'Access-Control-Max-Age' 1728000; # 允许浏览器在跨域请求中暴露响应头 add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range'; # 处理OPTIONS预检请求 if ($request_method = 'OPTIONS') { add_header 'Access-Control-Allow-Origin' '*'; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range'; add_header 'Access-Control-Max-Age' 1728000; add_header 'Content-Type' 'text/plain; charset=utf-8'; add_header 'Content-Length' 0; return 204; } # 其他代理配置... proxy_pass http://backend; } }

2.2 生产环境安全配置

上述配置中使用了通配符*允许所有来源访问，这在生产环境中是不安全的。更安全的做法是动态匹配允许的域名：

map $http_origin $cors_origin { default ""; "~^https://([a-z0-9-]+\.)?example\.com$" $http_origin; "~^https://([a-z0-9-]+\.)?myapp\.com$" $http_origin; } server { # ...其他配置 location / { if ($cors_origin) { add_header 'Access-Control-Allow-Origin' $cors_origin; add_header 'Access-Control-Allow-Credentials' 'true'; } # ...其他CORS配置 } }

这个配置使用了Nginx的map指令，只允许来自example.com和myapp.com及其子域的请求，同时支持携带凭据（如cookies）。

2.3 处理带凭据的请求

当前端请求需要携带cookies等凭据时，需要额外配置：

add_header 'Access-Control-Allow-Credentials' 'true';

重要限制：当Access-Control-Allow-Credentials为true时，Access-Control-Allow-Origin不能使用通配符*，必须指定具体域名。

3. 高级配置与性能优化

3.1 预检请求缓存

预检请求（OPTIONS）会增加请求延迟，可以通过设置Access-Control-Max-Age来缓存预检结果：

add_header 'Access-Control-Max-Age' 1728000; # 20天（单位：秒）

3.2 动态CORS配置

对于需要根据请求动态调整CORS策略的场景，可以使用Nginx的变量和条件判断：

set $allow_origin ""; if ($http_origin ~* (https?://[^/]*\.example\.com(:[0-9]+)?)$) { set $allow_origin $1; } location / { if ($allow_origin != "") { add_header 'Access-Control-Allow-Origin' "$allow_origin"; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE'; add_header 'Access-Control-Allow-Headers' 'Authorization,Content-Type'; add_header 'Access-Control-Allow-Credentials' 'true'; } # ...其他配置 }

3.3 与反向代理配合

当Nginx作为反向代理时，需要注意CORS头可能被后端覆盖的问题：

location /api/ { proxy_pass http://backend; # 确保后端不会覆盖CORS头 proxy_hide_header 'Access-Control-Allow-Origin'; proxy_hide_header 'Access-Control-Allow-Methods'; proxy_hide_header 'Access-Control-Allow-Headers'; # 重新添加CORS头 add_header 'Access-Control-Allow-Origin' $http_origin always; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always; add_header 'Access-Control-Allow-Headers' 'Content-Type,Authorization' always; # ...其他配置 }

4. 常见问题排查与解决方案

4.1 CORS配置不生效的可能原因

  1. 缓存问题：浏览器可能缓存了之前的响应。解决方案：

    • 强制刷新页面（Ctrl+F5）
    • 在开发工具中禁用缓存
    • 在Nginx配置中添加add_header Cache-Control 'no-store, no-cache'（仅限开发环境）

  2. 配置位置错误：CORS头必须添加到正确的location块中。确保：

    • 对于API请求，配置在API的location块中
    • 对于静态资源，配置在相应的静态文件location块中

  3. 头被覆盖：当Nginx作为反向代理时，后端可能覆盖了CORS头。解决方案：

    • 使用proxy_hide_header隐藏后端发送的CORS头
    • 使用add_header ... always确保Nginx总是添加CORS头

4.2 特定场景问题解决

问题1：POST请求变成OPTIONS请求，返回405 Method Not Allowed

原因：这是CORS预检请求，需要在Nginx中正确处理OPTIONS方法

解决方案：

location / { if ($request_method = 'OPTIONS') { add_header 'Access-Control-Allow-Origin' '$http_origin'; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; add_header 'Access-Control-Allow-Headers' 'Content-Type,Authorization'; add_header 'Access-Control-Max-Age' 1728000; add_header 'Content-Type' 'text/plain; charset=utf-8'; add_header 'Content-Length' 0; return 204; } # ...其他配置 }

问题2：前端收到CORS错误，但Postman测试正常

原因：Postman等工具不受同源策略限制，浏览器才会强制执行CORS

解决方案：

  • 确保Nginx配置了正确的CORS头
  • 检查请求是否携带了非常规头（需要在Access-Control-Allow-Headers中声明）

4.3 安全加固建议

  1. 限制允许的方法：只开放必要的HTTP方法

    add_header 'Access-Control-Allow-Methods' 'GET, POST';

  2. 限制允许的头：只声明必要的请求头

    add_header 'Access-Control-Allow-Headers' 'Content-Type,Authorization';

  3. 使用Vary头：当根据Origin动态返回不同的CORS头时，应该添加Vary头

    add_header 'Vary' 'Origin';

  4. 日志监控：记录跨域请求以便审计

    log_format cors_log '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" "$http_origin"'; server { access_log /var/log/nginx/cors.log cors_log; # ...其他配置 }

5. 实际案例：为前后端分离项目配置CORS

假设我们有一个前后端分离的项目：

  • 前端：https://app.example.com
  • API：https://api.example.com

5.1 Nginx配置示例

map $http_origin $allow_origin { default ""; "~^https://app\.example\.com$" "$http_origin"; "~^https://([a-z0-9-]+\.)?example\.com$" "$http_origin"; } server { listen 443 ssl; server_name api.example.com; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; location / { if ($allow_origin != "") { add_header 'Access-Control-Allow-Origin' "$allow_origin"; add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS'; add_header 'Access-Control-Allow-Headers' 'Authorization,Content-Type,X-Requested-With'; add_header 'Access-Control-Allow-Credentials' 'true'; add_header 'Access-Control-Expose-Headers' 'X-Total-Count'; add_header 'Vary' 'Origin'; } if ($request_method = 'OPTIONS') { add_header 'Access-Control-Allow-Origin' "$allow_origin"; add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS'; add_header 'Access-Control-Allow-Headers' 'Authorization,Content-Type,X-Requested-With'; add_header 'Access-Control-Max-Age' 1728000; add_header 'Content-Type' 'text/plain; charset=utf-8'; add_header 'Content-Length' 0; return 204; } 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; } }

5.2 前端代码适配

前端需要相应配置：

// Axios示例 const api = axios.create({ baseURL: 'https://api.example.com', withCredentials: true, // 如果需要发送cookies headers: { 'Content-Type': 'application/json' } }); // Fetch API示例 fetch('https://api.example.com/data', { method: 'GET', credentials: 'include', // 如果需要发送cookies headers: { 'Authorization': 'Bearer token123' } })

5.3 测试与验证

使用curl测试CORS配置：

# 测试OPTIONS预检请求 curl -X OPTIONS -H "Origin: https://app.example.com" \ -H "Access-Control-Request-Method: GET" \ -H "Access-Control-Request-Headers: Authorization" \ -I https://api.example.com/data # 预期响应头应包含： # Access-Control-Allow-Origin: https://app.example.com # Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS # Access-Control-Allow-Headers: Authorization,Content-Type,X-Requested-With

6. 性能优化与最佳实践

6.1 减少预检请求

  1. 使用简单请求：符合以下条件的请求不会触发预检：

    • 方法为GET、HEAD或POST
    • 仅包含以下头：Accept、Accept-Language、Content-Language、Content-Type
    • Content-Type为：text/plain、multipart/form-data、application/x-www-form-urlencoded

  2. 延长预检缓存时间：

    add_header 'Access-Control-Max-Age' 86400; # 1天

6.2 静态资源的CORS优化

对于静态资源（如图片、字体），可以设置更宽松但安全的策略：

location ~* \.(eot|ttf|woff|woff2|png|jpg|jpeg|gif|ico|svg)$ { add_header 'Access-Control-Allow-Origin' '*'; add_header 'Access-Control-Allow-Methods' 'GET'; expires 30d; access_log off; }

6.3 监控与告警

配置Nginx日志记录CORS相关请求：

log_format cors_log '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' '"$http_origin" "$upstream_http_access_control_allow_origin"'; server { location / { access_log /var/log/nginx/cors.log cors_log; # ...其他配置 } }

然后可以设置监控，对异常的跨域请求（如大量不同Origin的请求）进行告警。

7. 安全风险与防护措施

7.1 CORS相关的安全风险

  1. 过度宽松的配置：

    • 使用Access-Control-Allow-Origin: *可能允许恶意网站访问你的API
    • 解决方案：严格限制允许的源

  2. 凭据泄露风险：

    • 当允许凭据且Origin配置不当时，可能导致用户凭据泄露
    • 解决方案：精确配置Access-Control-Allow-Origin，避免使用通配符

  3. CSRF攻击：

    • 即使有CORS限制，某些请求（如简单请求）仍可能被恶意网站利用
    • 解决方案：结合使用CSRF Token

7.2 安全加固配置

# 只允许特定域名访问 map $http_origin $cors_origin { default ""; "~^https://(www\.)?example\.com$" "$http_origin"; "~^https://app\.example\.com$" "$http_origin"; } server { location /api/ { # 基础安全头 add_header X-Frame-Options "SAMEORIGIN"; add_header X-Content-Type-Options "nosniff"; add_header X-XSS-Protection "1; mode=block"; # 严格的CORS策略 if ($cors_origin) { add_header 'Access-Control-Allow-Origin' "$cors_origin"; add_header 'Access-Control-Allow-Methods' 'GET, POST'; add_header 'Access-Control-Allow-Headers' 'Content-Type,Authorization'; add_header 'Access-Control-Allow-Credentials' 'true'; add_header 'Vary' 'Origin'; } # 拒绝非法的OPTIONS请求 if ($request_method = 'OPTIONS' && $cors_origin = "") { return 403; } # ...其他配置 } }

8. 调试技巧与工具

8.1 浏览器开发者工具

  1. 网络面板：

    • 查看请求和响应头，确认CORS头是否正确
    • 检查OPTIONS预检请求的响应

  2. 控制台：

    • 查看详细的CORS错误信息
    • 识别缺少哪些必要的CORS头

8.2 命令行工具

使用curl模拟跨域请求：

# 模拟简单跨域请求 curl -H "Origin: http://example.com" -I https://api.example.com/data # 模拟预检请求 curl -X OPTIONS -H "Origin: http://example.com" \ -H "Access-Control-Request-Method: POST" \ -H "Access-Control-Request-Headers: Content-Type" \ -I https://api.example.com/data

8.3 在线测试工具

  • CORS Tester：在线测试API的CORS配置
  • Postman：虽然不执行CORS检查，但可用于验证API基本功能

9. 与其他技术的集成

9.1 与WebSocket的CORS

WebSocket不受同源策略限制，但浏览器在建立连接时会检查Origin头：

location /ws/ { proxy_pass http://websocket_backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; # 验证WebSocket的Origin if ($http_origin !~* (https?://(www\.)?example\.com|https?://app\.example\.com)) { return 403; } }

9.2 与GraphQL的CORS

GraphQL通常使用单个端点，需要特殊处理：

location /graphql { # 处理OPTIONS预检请求 if ($request_method = 'OPTIONS') { add_header 'Access-Control-Allow-Origin' '$http_origin'; add_header 'Access-Control-Allow-Methods' 'POST, OPTIONS'; add_header 'Access-Control-Allow-Headers' 'Content-Type,Authorization'; add_header 'Access-Control-Max-Age' 1728000; add_header 'Content-Length' 0; return 204; } # 正常请求 add_header 'Access-Control-Allow-Origin' '$http_origin'; add_header 'Access-Control-Allow-Credentials' 'true'; proxy_pass http://graphql_backend; }

9.3 与JWT认证的集成

当使用JWT认证时，需要确保暴露Authorization头：

add_header 'Access-Control-Expose-Headers' 'Authorization';

10. 常见误区与正确实践

10.1 常见误区

  1. 认为CORS是服务器间的限制：实际上CORS是浏览器强制的安全机制
  2. 忽略Vary头：当动态返回CORS头时，应该包含Vary: Origin
  3. 过度使用通配符：生产环境应避免Access-Control-Allow-Origin: *
  4. 忽略凭据安全：Allow-Credentials为true时不能使用通配符Origin
  5. 忘记处理OPTIONS方法：导致预检请求失败

10.2 正确实践

  1. 开发环境：

    • 可以使用通配符方便开发
    • 配置详细的错误日志

  2. 生产环境：

    • 严格限制允许的源
    • 限制允许的方法和头
    • 启用凭据保护
    • 监控跨域请求

  3. 测试策略：

    • 自动化测试CORS配置
    • 定期安全审计
    • 模拟恶意源测试防护效果

11. Nginx配置维护建议

11.1 模块化配置

将CORS配置提取到单独文件便于维护：

# /etc/nginx/conf.d/cors.conf # CORS基础配置 map $http_origin $allow_origin { default ""; "~^https://([a-z0-9-]+\.)?example\.com$" "$http_origin"; "~^https://myapp\.com$" "$http_origin"; } # 主配置文件中包含 server { include conf.d/cors.conf; location / { if ($allow_origin) { add_header 'Access-Control-Allow-Origin' "$allow_origin"; # ...其他CORS头 } } }

11.2 版本控制

将Nginx配置纳入版本控制系统，特别是：

  • CORS允许的域名列表
  • 允许的方法和头
  • 安全相关配置

11.3 自动化测试

编写测试用例验证CORS配置：

#!/bin/bash # 测试有效源 curl -H "Origin: https://app.example.com" -I https://api.example.com | grep "Access-Control-Allow-Origin: https://app.example.com" || exit 1 # 测试无效源 curl -H "Origin: https://hacker.com" -I https://api.example.com | grep "Access-Control-Allow-Origin" && exit 1 # 测试OPTIONS方法 curl -X OPTIONS -H "Origin: https://app.example.com" -H "Access-Control-Request-Method: POST" -I https://api.example.com | grep "Access-Control-Allow-Methods: POST" || exit 1 echo "All CORS tests passed" exit 0

12. 性能影响评估

12.1 CORS对性能的影响因素

  1. 预检请求：

    • 增加一次额外的HTTP往返
    • 对延迟敏感的应用影响较大

  2. 头大小：

    • CORS头会增加响应头的大小
    • 对高并发小请求的应用影响较大

  3. 缓存效率：

    • 不同的Origin需要不同的响应头
    • 可能降低缓存命中率

12.2 优化建议

  1. 合理设置Access-Control-Max-Age：

    add_header 'Access-Control-Max-Age' 86400; # 1天

  2. 精简允许的头和方法：

    add_header 'Access-Control-Allow-Methods' 'GET, POST'; add_header 'Access-Control-Allow-Headers' 'Content-Type';

  3. CDN配置：

    • 在CDN边缘节点配置CORS
    • 减少回源请求

  4. 使用HTTP/2：

    • 多路复用可以减少预检请求的影响
    • 头部压缩减少CORS头的传输开销

13. 替代方案比较

13.1 JSONP

原理：通过<script>标签绕过同源策略
限制：

  • 仅支持GET方法
  • 安全性较差
  • 逐渐被淘汰

示例：

function handleResponse(data) { console.log(data); } const script = document.createElement('script'); script.src = 'https://api.example.com/data?callback=handleResponse'; document.body.appendChild(script);

13.2 反向代理

原理：让同源服务器代理跨域请求
实现：

location /api/ { proxy_pass https://api.example.com/; proxy_set_header Host api.example.com; }

优点：

  • 完全避免CORS问题
  • 可以隐藏真实API地址

缺点：

  • 增加服务器负担
  • 可能引入额外延迟

13.3 WebSocket

适用场景：实时双向通信
特点：不受同源策略限制，但可以验证Origin

13.4 CORS与替代方案的选择

方案适用场景安全性复杂度浏览器支持
CORS现代API高中全支持
JSONP旧系统兼容低低全支持
反向代理完全控制高高无影响
WebSocket实时应用中高现代浏览器

14. 未来趋势与演进

14.1 更严格的默认安全策略

  • 浏览器逐渐收紧默认安全策略
  • 可能需要更精确的CORS配置

14.2 新兴标准

Fetch Metadata：

  • 提供更多请求上下文信息
  • 帮助服务器做出更精细的CORS决策

COEP/COOP：

  • 跨源嵌入策略
  • 提供更强的隔离保护

14.3 服务端趋势

  • 更多框架内置CORS支持
  • 更精细的权限控制
  • 与身份验证更深度集成

15. 完整配置示例

以下是一个生产环境可用的完整Nginx CORS配置示例：

# /etc/nginx/conf.d/cors.conf # CORS配置 map $http_origin $allow_origin { default ""; "~^https://([a-z0-9-]+\.)?example\.com$" "$http_origin"; "~^https://([a-z0-9-]+\.)?myapp\.com$" "$http_origin"; } # 安全头 map $request_method $cors_method { OPTIONS "OPTIONS"; default "$allow_origin"; } server { listen 443 ssl; server_name api.example.com; ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem; # 全局安全头 add_header X-Frame-Options "SAMEORIGIN"; add_header X-Content-Type-Options "nosniff"; add_header X-XSS-Protection "1; mode=block"; add_header Referrer-Policy "strict-origin-when-cross-origin"; # API路由 location /api/ { # CORS头 if ($cors_method) { add_header 'Access-Control-Allow-Origin' "$allow_origin" always; add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always; add_header 'Access-Control-Allow-Headers' 'Authorization,Content-Type,X-Requested-With' always; add_header 'Access-Control-Allow-Credentials' 'true' always; add_header 'Access-Control-Expose-Headers' 'X-Total-Count' always; add_header 'Vary' 'Origin' always; } # 处理OPTIONS预检请求 if ($request_method = 'OPTIONS') { add_header 'Access-Control-Max-Age' 1728000; add_header 'Content-Type' 'text/plain; charset=utf-8'; add_header 'Content-Length' 0; return 204; } # 代理配置 proxy_pass http://backend; proxy_http_version 1.1; 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_connect_timeout 60s; proxy_read_timeout 60s; proxy_send_timeout 60s; } # 静态资源 location ~* \.(woff2?|ttf|eot|svg|png|jpg|jpeg|gif|ico|css|js)$ { add_header 'Access-Control-Allow-Origin' "*"; add_header 'Access-Control-Allow-Methods' 'GET'; expires 30d; access_log off; # 实际文件路径 root /var/www/static; } # 健康检查 location /health { access_log off; return 200 "OK"; } # 日志配置 access_log /var/log/nginx/api.access.log; error_log /var/log/nginx/api.error.log; }

16. 总结与个人实践建议

在实际运维中，我发现以下几点特别值得注意：

  1. 开发与生产环境分离：

    • 开发环境可以使用宽松的CORS策略
    • 生产环境必须严格限制允许的源

  2. 监控与告警：

    • 记录所有跨域请求
    • 对异常的Origin进行告警

  3. 文档化：

    • 记录允许的域名列表
    • 说明CORS配置的变更流程

  4. 测试策略：

    • 自动化测试CORS配置
    • 定期验证安全限制是否生效

  5. 性能考量：

    • 评估CORS对API性能的影响
    • 在CDN边缘节点处理CORS

最后，记住CORS配置不是一劳永逸的，随着应用的发展和安全需求的变化，需要定期审查和更新CORS策略。

标签： 网站建设 企业官网 项目流程 UI设计 前端开发

热门文章

文章分类

标签云

网站建设 响应式设计 用户体验 SEO优化 前端开发 小程序 电商平台 性能优化

相关文章

您可能感兴趣的其他内容

从零搭建智慧工地平台要多久？视频监控＋AI巡检＋考勤＋整改＋大屏的模板化实践
2026/10/24 5:30:03 网站建设

从零搭建智慧工地平台要多久？视频监控＋AI巡检＋考勤＋整改＋大屏的模板化实践

一、引言做过施工现场信息化的开发者&#xff0c;大概率都接过这样的需求&#xff1a;总部要一块能看到所有项目的大屏&#xff0c;项目部要管人员考勤和设备&#xff0c;安全员要把“未戴安全帽、通道堵塞”这类问题及时发现并跟踪到整改销项。单点功能都不难&#xff0c;难的…...

阅读更多 →
JGit 性能优化速查：围绕 jgit-cookbook 的完整提速实践
2026/10/24 5:25:32 网站建设

JGit 性能优化速查：围绕 jgit-cookbook 的完整提速实践

JGit 性能优化速查&#xff1a;围绕 jgit-cookbook 的完整提速实践 【免费下载链接】FactoryBluePrints 游戏戴森球计划的**工厂**蓝图仓库 项目地址: https://gitcode.com/GitHub_Trending/fa/FactoryBluePrints jgit-cookbook 是一套 JGit 用法示例集&#xff0c;里面…...

阅读更多 →
Mac 当主机，Linux 当服务器（17）告警规则，让 Prometheus 学会「喊人」
2026/10/24 5:25:30 网站建设

Mac 当主机，Linux 当服务器（17）告警规则，让 Prometheus 学会「喊人」

摘要：Grafana 再好看，也得有人看。这篇讲清 Prometheus 告警规则怎么写：expr / for / labels / annotations 四个字段各管什么、告警的三个状态 inactive → pending → firing 怎么走、ALERTS 指标怎么用 PromQL 查；再给你三条可以直接抄的常用规则（CPU / 内存 / 磁盘）和…...

阅读更多 →

需要专业的网站建设服务？

联系我们获取免费的网站建设咨询和方案报价，让我们帮助您实现业务目标

立即咨询