DIBS SSL Payment callback 出现 CURL error 35

2026-10-24支付老李

结论

CURL error 35 表示 TLS/SSL 握手失败，并不是 callback 业务代码返回了错误。

日志中最值得关注的是：

Unknown SSL protocol error in connection to rothausendev.dk:1080

DIBS 尝试通过 HTTPS 连接 rothausendev.dk:1080，而不是常用的 HTTPS 端口 443。如果 1080 端口运行的是普通 HTTP、SOCKS 代理或其他非 TLS 服务，cURL 向该端口发起 TLS 握手时就会报出这类错误。

所以，只确认 443 端口已经开放还不够。需要查清 callback 请求为什么最终连到了 1080，并确保公开的 callback URL 始终使用 443。如果必须使用 1080，则要让该端口正确提供 HTTPS。

可能原因

常见情况有：

提交给 DIBS 的 callback URL 中实际包含 :1080。
Web 服务器、反向代理或负载均衡器生成了指向 1080 的重定向。
NAT 或端口转发规则误将公网 443 转发到不支持 TLS 的内部端口。
应用在生成绝对 URL 时带上了内部监听端口，例如：

https://rothausendev.dk:1080/AppBookingManage/Confirm/...

1080 上运行的是 HTTP 服务，但客户端却被要求通过 HTTPS 访问。
DIBS 使用的 cURL 与服务器的 TLS 版本、密码套件或证书链不兼容。这一项应在确认端口配置无误后再重点排查。

日志里的 Callback(effectiveURL) 没有显示 :1080，但连接错误明确提到了这个端口。端口可能来自重定向、代理配置，也可能与 DIBS 的记录方式有关。需要结合实际的 TLS 握手和 HTTP 响应来确认，不能只看 URL 文本。

排查步骤

1. 检查发送给 DIBS 的完整 callback URL

callback 地址应类似：

https://rothausendev.dk/AppBookingManage/Confirm/<token>

其中不应包含：

:1080

还要检查 URL 是否经过编码、拼接或配置转换，特别是 Host、Port、BaseUrl、CallbackUrl 等配置项。

2. 检查是否存在重定向

从外部网络查看 callback URL 的响应头：

curl -vI 'https://rothausendev.dk/AppBookingManage/Confirm/test'

如需跟踪完整的重定向过程：

curl -vIL 'https://rothausendev.dk/AppBookingManage/Confirm/test'

逐一检查每个 Location 响应头，确认其中没有：

https://rothausendev.dk:1080/...

callback 路由最好直接处理请求，避免不必要的 HTTP→HTTPS 跳转、域名规范化跳转或登录页面重定向。

3. 分别测试 443 和 1080 的 TLS

openssl s_client -connect rothausendev.dk:443 -servername rothausendev.dk

如果确实需要检查 1080：

openssl s_client -connect rothausendev.dk:1080 -servername rothausendev.dk

如果 443 能返回证书，而 1080 出现 wrong version number、unknown protocol 等错误，或者直接断开连接，就说明 1080 不是正确的 HTTPS 入口。

4. 检查反向代理和端口映射

合理的部署结构可以是：

DIBS
  └─ HTTPS :443
       └─ Web server / reverse proxy
            └─ HTTP :1080（内部应用）

内部应用可以通过普通 HTTP 监听 1080，但这个端口不应作为外部 HTTPS 地址暴露。TLS 应在 443 上终止，再由反向代理将请求转发到内部服务。

以 Nginx 为例：

server {
    listen 443 ssl;
    server_name rothausendev.dk;

    ssl_certificate     /path/to/fullchain.pem;
    ssl_certificate_key /path/to/private.key;

    location /AppBookingManage/ {
        proxy_pass http://127.0.0.1:1080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-Port 443;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

需要特别注意这一行：

proxy_pass http://127.0.0.1:1080;

内部 1080 使用 HTTP，外部客户端则只访问 https://rothausendev.dk 的 443。生成对外 URL 时，不要带上内部端口。

5. 检查应用生成绝对 URL 的逻辑

应用部署在反向代理后面时，如果没有正确识别转发头，可能会把内部端口 1080 写入重定向地址。应用应信任指定代理发送的这些信息：

X-Forwarded-Proto: https
X-Forwarded-Port: 443
X-Forwarded-Host: rothausendev.dk

具体配置取决于所用框架。不要无条件信任公网客户端发送的转发头，只应信任实际的反向代理。

TLS 配置还需要检查什么

如果已经确认 DIBS 始终连接 443，并且请求不会重定向到 1080，再检查以下内容：

服务器证书是否与 rothausendev.dk 匹配。
服务器是否发送了完整的中间证书链。
服务器是否支持 DIBS 客户端可用的 TLS 版本和密码套件。
基于 SNI 的配置是否正确。
防火墙、WAF 或反向代理是否会在握手阶段断开连接。
服务器是否要求客户端证书，而 DIBS 没有提供。
DIBS 的出站 IP 是否被访问控制规则拦截。

可以显式测试不同的 TLS 版本，但服务器究竟需要支持哪些版本，应以 DIBS 当前的技术要求为准：

curl -v --tlsv1.2 'https://rothausendev.dk/AppBookingManage/Confirm/test'

不要为了兼容旧客户端贸然启用 SSLv3、TLS 1.0 或弱密码套件。应先向 DIBS 确认其 callback 客户端支持的 TLS 版本、SNI 能力和证书要求。

Callback 接口注意事项

TLS 问题修复后，callback 接口本身还应满足这些要求：

不依赖浏览器会话或交互式登录。
不重定向到登录页。
在较短时间内返回明确的 2xx 响应。
验证 DIBS 提供的签名或校验字段，不能只凭 URL 中的 token 确认付款。
对重复 callback 进行幂等处理，因为支付平台可能会重试。
记录请求时间、来源、订单号和处理结果，但不要记录完整密钥或敏感支付数据。

根据日志，当前最先要做的不是继续开放 443，而是找到 :1080 的来源。让 DIBS 正确连接支持 TLS 的 443，同时确保服务器证书链和 TLS 参数与其客户端兼容后，CURL error 35 通常就会消失。