如何配置有身份验证和 ipv6 的网站

[CAB233]

1. 使用basic身份验证的网站的配置。

浏览器里通过验证的信息

2. ipv6的地址是这么填写吗？两个配置只有ip不同，只有ipv6的一直无法检测

[lyc8503]

1. 你应该使用 https://en.wikipedia.org/wiki/Basic_access_authentication#Client_side 这里的写法指定，应为 Authorization: Basic <user:pass计算Base64>
2. 这似乎是我写的一个 bug，忘记考虑 ipv6 这种方括号写法了，稍后我修复下（因为大部分人都直接用域名😂），感谢你指出问题。

[CAB233]

身份验证依然有问题，下面分别是Cloudflare的日志、我的相关配置、本地curl。部分敏感信息已隐去。 顺便问一下如何在本地进行调试，每次要等待云端构建完成才能看到结果有点慢。

{
  "message": [
    "[SLC] Checking test..."
  ],
  "level": "log",
  "timestamp": 1716030033785
},
{
  "message": [
    "test errored with AbortError: The operation was aborted"
  ],
  "level": "log",
  "timestamp": 1716030043795
},

{
  id: 'mytest',
  name: 'test',
  method: 'GET',
  target: 'https://example.com:1145',
  tooltip: '',
  statusPageLink: '',
  expectedCodes: [200],
  timeout: 10000,
  headers: {
    Authorization: 'Basic myBASE64',
  },
  responseKeyword: '',
  checkLocationWorkerRoute: '',
},

curl -v -H "Authorization: Basic myBASE64" https://example.com:1145

• Host example.com:1145 was resolved.
• IPv6: (none)
• IPv4: 1.2.3.4
• Trying 1.2.3.4:1145...
• Connected to example.com (1.2.3.4) port 1145
• ALPN: curl offers h2,http/1.1
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• CAfile: /etc/ssl/certs/ca-certificates.crt
• CApath: none
• TLSv1.3 (IN), TLS handshake, Server hello (2):
• TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
• TLSv1.3 (IN), TLS handshake, Certificate (11):
• TLSv1.3 (IN), TLS handshake, CERT verify (15):
• TLSv1.3 (IN), TLS handshake, Finished (20):
• TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
• TLSv1.3 (OUT), TLS handshake, Finished (20):
• SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / id-ecPublicKey
• ALPN: server accepted http/1.1
• Server certificate:
• subject: CN=example.com
• start date: Apr 16 04:08:48 2024 GMT
• expire date: Jul 15 04:08:47 2024 GMT
• subjectAltName: host "example.com" matched cert's "example.com"
• issuer: C=US; O=Let's Encrypt; CN=R3
• SSL certificate verify ok.
• Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using sha256WithRSAEncryption
• Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
• Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
• using HTTP/1.x

  GET / HTTP/1.1 Host: example.com:1145 User-Agent: curl/8.7.1 Accept: / Authorization: Basic myBASE64

• Request completely sent off
• TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
• TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
• old SSL session ID is stale, removing < HTTP/1.1 200 OK < Server: nginx/1.22.1 < Date: Sat, 18 May 2024 11:11:08 GMT < Content-Type: text/html;charset=utf-8 < Content-Length: 1153 < Connection: keep-alive < x-powered-by: Nuxt ...

[lyc8503]

理论上，在本地使用 wrangler dev 是可以进行本地的调试的，但配置环境有些许复杂，目前我仍然是在 Cloudflare 上调试的，可以使用 wrangler deploy 直接部署到 Cloudflare，无需等待 Actions 完整运行。

不过考虑到这可能会引入一些新的问题，我个人还是建议暂时使用 Actions 以确保一致的环境。抱歉，由于 Cloudflare 这边的平台限制，开发体验确实不是非常好，目前本地 Docker 容器部署也正在进展中，之后可能支持 Docker 容器部署。

---

至于你身份验证配置失败的问题，报错原因是 AbortError: The operation was aborted，代表是 worker 请求你的服务器超时了，你确定你的服务器从公网可以访问到吗，前端状态页的延迟图是怎样的？（如果一直是 5000/10000ms 代表全是连接超时，如果不是的话，请重新抓下日志看看）

[lyc8503]

IPv6 的问题已经修复了，现在你更新代码后 IPv6 监控应该能正常运行，issue 暂时关闭了，如果你配置上有其他问题可以在这里继续问~

[CAB233]

非常感谢您！ 关于身份验证我去确认了一下，我这台服务器是在国内的，上面跑的服务能公网访问，但前端页面延迟一直是10000ms。无论我是在本机（国内）、国外服务器、通过warp代理（排除屏蔽了cloudflare的可能）来分别curl请求都能正常返回200，其日志同上。

[lyc8503]

非常感谢您！ 关于身份验证我去确认了一下，我这台服务器是在国内的，上面跑的服务能公网访问，但前端页面延迟一直是10000ms。无论我是在本机（国内）、国外服务器、通过warp代理（排除屏蔽了cloudflare的可能）来分别curl请求都能正常返回200，其日志同上。

那您看下是否可能是这个问题 #9，目前监控过多的话，可能会导致靠后的监控超时。这个问题在原 issue 中已有 workaround，我现在也在尝试彻底解决这个问题。

如果不是的话，就比较奇怪... 如果方便的话，是否能给我一下服务器的地址（如果不方便公开的话，可以发我邮箱 me@lyc8503.site），我尝试复现一下。

[CAB233]

我没有遇到并发数限制的问题，因为上面有问题的配置是排在前面，其后的配置都是正常的。

我尝试了不同的的组合，似乎是某种神秘的网络问题=_= :

• 在国内另一台服务器上配置相同的 nginx basic 验证，这次 worker 里的报错变成了test responded with 403，同样的，国内和国外使用 curl 都能返回 200

• 在国外一台服务器上同样配置，这次检测就没有问题了

服务器信息稍后发送到您的邮箱

[lyc8503]

您好，感谢您提供的信息，我确实可以复现这个问题...

目前我测试的情况是这样的：

1. Worker 使用 https 访问你的网页，连接超时
2. Worker 使用 TCP 连接到你的 https 端口，连接正常
3. 从海外其他服务器，使用 https 访问你的网页，连接正常

和你所说的一致，所以似乎是华为云+Cloudflare组合产生的神秘问题...

这个问题真的就比较神奇了，你的服务器环境具体是怎样的，就是使用的普通的 Nginx 吗？ 有没有配置一些其他防火墙或者 WAF 之类的。

如果就是使用的最普通的 Nginx 的话... 那你是否方便在服务器上使用 tcpdump 抓包看看 1145 端口上是否能收到来自 Cloudflare 的请求，然后服务器是否应答了？顺便，我看到您服务器 IP 是上海的，您使用的是华为云的 ECS 还是 HECS，我有空尝试下复现服务端的环境。

至于你在国内另一台服务器上的配置，如果报错就是 responded with 403 的话，那应该就是源服务器返回了 403（如果身份验证错误应该返回 401 而不是 403），请检查下服务器相关的日志。

[lyc8503]

哦，关于 403 是不是你直接使用了 ip:port 的形式进行了 https 的监测，目前 Cloudflare 的 fetch 还不允许这种行为，你需要一个域名。

[CAB233]

有没有配置一些其他防火墙或者 WAF 之类的。

只有服务器实例的安全组规则，放行特定的流量入端口。没有开通任何「云防火墙」相关的服务。

如果就是使用的最普通的 Nginx 的话... 那你是否方便在服务器上使用 tcpdump 抓包看看 1145 端口上是否能收到来自 Cloudflare 的请求，然后服务器是否应答了？

神奇的是没有任何来自 cloudflare 的请求，只有我自己的流量记录...结合上面所说的，cloudflare 的流量在到达我的服务器前就已经被「神秘的东西」滤掉了。因此目前我能想到的就是华为云对未备案域名或者对 cloudflare 有什么特殊的处理=_=

我看到您服务器 IP 是上海的，您使用的是华为云的 ECS 还是 HECS，我有空尝试下复现服务端的环境。

用的华为云 HECS，系统使用 bin456789/reinstall 重新安装的官方 debian12 镜像。安装的是 debian 仓库里的 nginx，仅在原配置项中加入以下配置：

 server {
    server_name example.com;
    listen 1145 ssl;
    ssl_certificate /etc/nginx/example.com.pem;
    ssl_certificate_key /etc/nginx/example.com.key;
    ssl_protocols TLSv1.2 TLSv1.3;

    auth_basic "Basic Http Auth";
    auth_basic_user_file /etc/nginx/passwd;

    location / {
        proxy_redirect off;
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

关于 403 是不是你直接使用了 ip:port 的形式进行了 https 的监测，目前 Cloudflare 的 fetch 还不允许这种行为，你需要一个域名。

使用 ip:port https 检测的是我的阿里云服务器，但我的域名并没有备案而且阿里管的很严，就只能使用 ip 进行访问。

整个情况不是很有头绪，不如到此为止吧

[lyc8503]

行，我是不知道是怎么回事，暂时就让神秘力量背锅，如果后续有更多相关的报告再说。

[catsimple]

联通家宽公网 worker直接连接https 非标端口 报错 aborted tcping连接对应的https非标端口则正常

[lyc8503]

联通家宽公网 worker直接连接https 非标端口 报错 aborted tcping连接对应的https非标端口则正常

上面提到了 https 非标端口可能不能直接用 IP:port 的形式检测, 你有使用 DDNS 域名吗?

[catsimple]

联通家宽公网 worker直接连接https 非标端口 报错 aborted tcping连接对应的https非标端口则正常

上面提到了 https 非标端口可能不能直接用 IP:port 的形式检测, 你有使用 DDNS 域名吗?

用的域名+端口的形式

[lyc8503]

用的域名+端口的形式

看起来这是上游的限制 https://github.com/cloudflare/workers-sdk/issues/1320

暂时我也没有办法, 对于非标的 http/https 端口, 似乎要求你访问的域名必须托管在 Cloudflare 上. (you should be able to make fetch requests to a custom port within your own Cloudflare zone)

[catsimple]

看起来这是上游的限制 cloudflare/workers-sdk#1320

暂时我也没有办法, 对于非标的 http/https 端口, 似乎要求你访问的域名必须托管在 Cloudflare 上. (you should be able to make fetch requests to a custom port within your own Cloudflare zone)

还是不行，用cf托管的域名仍然无法访问，无论dns勾不勾“使用代理”，结果一样。 另外我测过我这边ipv6的443端口，是开放的，即使我填入只有ipv6地址的域名，用https 默认443端口连接，依然无法访问，而tcping是正常的。应该是被阻断了

[lyc8503]

还是不行，用cf托管的域名仍然无法访问，无论dns勾不勾“使用代理”，结果一样。 另外我测过我这边ipv6的443端口，是开放的，即使我填入只有ipv6地址的域名，用https 默认443端口连接，依然无法访问，而tcping是正常的。应该是被阻断了

家里云的话要过 GFW 和运营商两道门槛, 确实不可控因素较多, 如果不行的话那只能用 tcping 检测了.