# 80 → 301 → 443
server {
    listen 80;
    listen [::]:80;
    server_name app-api.shaguabijia.com;
    return 301 https://$host$request_uri;
}

# 443 SSL 反代到本地 uvicorn (127.0.0.1:8770)
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name app-api.shaguabijia.com;

    ssl_certificate     /etc/nginx/ssl/app-api.shaguabijia.com.pem;
    ssl_certificate_key /etc/nginx/ssl/app-api.shaguabijia.com.key;

    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ssl_session_cache   shared:SSL:10m;

    # 上传接口(反馈/上报截图、头像)业务上限 = 最多 6 张 × 每张 5MB
    # (见 app _MAX_IMAGES / AVATAR_MAX_BYTES)≈ 30MB,留余量设 32m。
    # 低于此值时带截图的反馈会在到达 uvicorn 前就被 nginx 413,表现为「提交经常失败」
    # (纯文字反馈体积小、不受影响 → 呈现为「时好时坏」)。根治仍需客户端上传前压缩。
    client_max_body_size 32m;

    # JSON 响应压缩。nginx 默认 gzip off,且就算 on 了 gzip_types 也只含 text/html、
    # gzip_proxied 默认 off(反代来的响应一律不压)—— 三个默认值凑一起 = 我们所有接口都在裸奔。
    # 比价记录列表这种一次 50 条、字段名 + 中文店名/菜名高度重复的 JSON,gzip 压缩比稳定在 8~10 倍
    # (几百 KB → 几十 KB),弱网下省的就是首屏那几秒。
    # 只压 JSON:APK 直链(/media/shaguabijia.apk)、图片本身已是压缩格式,再压纯浪费 CPU。
    gzip              on;
    gzip_proxied      any;      # 反代响应也压(默认 off = 对我们这套反代等于没开)
    gzip_types        application/json;
    gzip_min_length   1024;     # 小响应压了反而更大(gzip 头开销),不值当
    gzip_comp_level   5;        # 5 是体积/CPU 的常用折中点,再往上收益递减
    gzip_vary         on;       # 给 CDN/中间缓存正确按 Accept-Encoding 分桶

    location / {
        proxy_pass http://127.0.0.1:8770;
        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_read_timeout 30s;
    }
}