自建短链转节点订阅链接无法正常跳转, cloudflare 报 502,但转其他网站的长链却成功, 是啥情况?

2022-12-01 02:01:51 +08:00
 winson030

TLDR:myurl 转换 subweb 的订阅长链接报 502 ,转换其他链接能正常跳转

起因

最近想自建短链,看到了 stilleshan 的项目,作者提供了完整的指南和配置文件,想着搭一个玩玩。根据作者的 docker-compose 文件,nginx 配置文件搭建好之后,尝试转换 subweb 的订阅链接,能转换成功返回短链,数据库也成功存储长链接数据,但通过短链访问长链确报 502 的错误,转换 Google ,bing 上别的网站的长链接能够正常跳转,甚至是作者自己搭建的短链也成功跳转(我的短链-->作者的短链-->长链),这让我非常困惑。

背景

域名在 cloudflare 上托管着,用的 nginx 做反向代理

排查

nginx

正常,可以接收短链的请求,有访问日志

ip.ip.ip.ip - - [30/Nov/2022:15:58:16 +0000] "GET /gpx3R8g HTTP/2.0" 502 559 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36 Edg/107.0.1418.56" "ip.ip.ip.ip"

配置文件如下

server {
    listen 80;

    server_name a.b.c;
    return 301 https://a.b.c$request_uri;
}

server {
    listen 443 ssl http2;

    server_name a.b.c;
    index index.php index.html index.htm default.php default.htm default.html;
  
    ssl_certificate /etc/nginx/ssl/a.b.c/fullchain1.pem;
    ssl_certificate_key /etc/nginx/ssl/a.b.c/privkey1.pem;
    gzip on;

    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4;
    ssl_ecdh_curve secp384r1;
    ssl_session_timeout 10m;
    ssl_session_cache builtin:1000 shared:SSL:10m;

    ssl_session_tickets off;
    resolver 8.8.8.8 8.8.4.4 valid=60s ipv6=off;
    resolver_timeout 5s;
    add_header Strict-Transport-Security "max-age=63072000" always;




    location / {
        proxy_redirect off;
        # proxy_http_version 1.1;
        proxy_pass http://a.b.c:8002;
        add_header 'Access-Control-Allow-Origin' '*';
   

        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Ssl on;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Frame-Options SAMEORIGIN;

        client_max_body_size 100m;
        client_body_buffer_size 128k;
    }

    # Pass PHP files to FPM.
    # location ~ \.php$ {
    #     try_files $uri =404;
    #     fastcgi_split_path_info ^(.+\.php)(/.+)$;
    #     fastcgi_pass unix:/var/run/php5-fpm.sock;
    #     fastcgi_index index.php;
    #     include fastcgi_params;
    # }

    # Deny hidden files.
    location ~ /\. {
        deny all;
    }

    # Forbidden files or directories
    location ~ ^/(\.user.ini|\.htaccess|\.git|\.svn|\.project|LICENSE|README.md) {
        return 404;
    }

    # Directory verification related settings for one-click application for SSL certificate
    location ~ \.well-known {
        allow all;
    }

    location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {
        expires 30d;
        error_log /dev/null;
        access_log off;
    }

    location ~ .*\.(js|css)?$ {

        expires 12h;
    }


    access_log /var/log/nginx/a.b.c.access.log main;
    error_log /var/log/nginx/a.b.c.error.log warn;
}

redis

正常,可以存储长链和短链

前端

正常,可以正确解析长链,返回短链

疑惑

目前将问题定位在 cloudflare 上,但 cloudflare 免费版能设置的也就零星几个选项,想知道该怎么设置才能解除报 502 ,正常跳转到长链接

1536 次点击
所在节点    Cloudflare
10 条回复
eason1874
2022-12-01 02:08:37 +08:00
你自己的 Nginx 都 502 ,说明不关 CF 的事,应该是短链接程序有 bug ,要看它的日志
winson030
2022-12-01 02:12:29 +08:00
@eason1874

```shell
root@debian ~/myurls# docker logs myurls
[GIN] 2022/11/30 - 17:15:27 | 200 | 704.002µs | a.b.c.d | GET "/"
2022/11/30 17:15:38 Hit cache: gpx3R8g
[GIN] 2022/11/30 - 17:15:38 | 200 | 1.762924ms | a.b.c.d | POST "/short"
[GIN] 2022/11/30 - 17:15:43 | 301 | 988.202µs | a.b.c.d | GET "/gpx3R8g"
[GIN] 2022/11/30 - 17:18:34 | 301 | 5.359253ms | a.b.c.d | GET "/gpx3R8g"
[GIN] 2022/11/30 - 17:22:29 | 301 | 1.425363ms | a.b.c.d | GET "/gpx3R8g"
```
docker 上的日志是这样的,没看出啥毛病呀?
winson030
2022-12-01 02:14:00 +08:00
@eason1874

如果不是 cloudflare 的配置问题,那就麻烦了,又要重新排查。
eason1874
2022-12-01 02:21:19 +08:00
@winson030 我不了解这些程序。你可以在服务器内直接请求 docker 看是不是正常,像这样

curl -i http://a.b.c:8002/gpx3R8g
winson030
2022-12-01 02:26:27 +08:00
@eason1874 试了下,返回了下面这些信息

```shell
HTTP/2 502
server: nginx/1.23.2
date: Wed, 30 Nov 2022 18:23:35 GMT
content-type: text/html
content-length: 157

<html>
<head><title>502 Bad Gateway</title></head>
<body>
<center><h1>502 Bad Gateway</h1></center>
<hr><center>nginx/1.23.2</center>
</body>
</html>
```
这里能看出什么问题吗?
eason1874
2022-12-01 02:33:35 +08:00
@winson030 你直接请求 docker 访问地址也报 502 ,就证实了问题出 docker 其中程序。你可以进去 shell 查看里面的日志,如果没有记录日志,你就打开后再请求然后再看。我没用过这个短链接,只能说个思路了,具体操作你得自己做
winson030
2022-12-01 02:47:07 +08:00
@eason1874

```shell
2022/11/30 18:40:59 [error] 237#237: *353 upstream sent too big header while reading response header from upstream, client: a.b.c.d, server: a.b.c.d, request: "GET /W8yuvkA HTTP/2.0", upstream: "http://a.b.c.d:8002/W8yuvkA", host: "a.b.c.d"
2022/11/30 18:41:24 [error] 237#237: *353 upstream sent too big header while reading response header from upstream, client: a.b.c.d, server: a.b.c.d, request: "GET /W8yuvkA HTTP/2.0", upstream: "http://a.b.c.d:8002/W8yuvkA", host: "a.b.c.d"
2022/11/30 18:41:55 [error] 237#237: *353 upstream sent too big header while reading response header from upstream, client: a.b.c.d, server: a.b.c.d, request: "GET /W8yuvkA HTTP/2.0", upstream: "http://a.b.c.d:8002/W8yuvkA", host: "a.b.c.d"

```

看到 nginx 的报错说 " upstream sent too big header while reading response header from upstream",感觉是长链接的字节流太大了?这种情况不知道要咋整?
eason1874
2022-12-01 02:52:57 +08:00
@winson030 这是 docker 外的报错信息吧,那你可以把 proxy_buffer_size 调大试试

proxy_buffers 8 16k;
proxy_buffer_size 32k;
winson030
2022-12-01 02:55:25 +08:00
@winson030

查到问题根源了,是 nginx 反向代理的代理缓冲问题,subweb 的长链接太长了导致 nginx 报 502 ,解决方案是将反向代理缓存的相关内容设置得大一些。
```nginx
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
```
winson030
2022-12-01 02:56:29 +08:00
@eason1874 长链接在配置完代理缓冲区后成功加载了!感谢!

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/899218

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX