我们正在尝试将用户链接到他们的Twitter帐户，以便该用户从我们的网站发送推文。我们得到“cURL错误35”错误，但有时只是。该错误将我们引导到一个页面，该页面指出我们应该看到错误缓冲区中的内容，但因为我们使用的是社交网站，我不确定如何访问它？
我已经发现了各种cURL选项来启用更多输出，但是不能为我的生活决定如何让社交名媛使用那些？似乎供应商软件包（socialite）正在调用一个调用curlFactory的供应商软件包（guzzle），我需要告诉最后一个供应商软件包输出更详细的错误，到某个日志文件？
目前正在使用：Laravel 5.4，laravel-socialite 3，socialiteproviders / twitter 3.
完整错误：
cURL错误35：与api.twitter.com:443相关的未知SSL协议错误（请参阅http://curl.haxx.se/libcurl/c/libcurl-errors.html）
非常感谢任何协助。
[编辑] 我们已将此问题缩小到服务器端配置。运行此命令：
curl 'https://api.twitter.com/oauth2/token'
最终导致cURL 35错误。但！我们从流浪汉机器内部运行相同的命令，它可以100％的时间工作。
生产服务器上的cURL版本是7.38，但在我的流浪机内是7.35。
[UPDATE]
过去几天，我们的服务器管理员一直在处理这个问题。他报告说他仍然无法让这个工作。他甚至降级到7.35，这对我们以前的服务器起作用无济于事。似乎cURL包一般不能与Debian 8和php7一起使用。
有没有人，在整个世界范围内，以及任何监视我们的ET都知道发生了什么事？我们正在努力与社交网络合作，当每个人都说使用cURL时，这是一个巨大的痛苦。
[更新2]
我在Twitter开发者论坛上发现了类似的帖子。来自Twitter工作人员：
Twitter supports TLS 1.2 - SSLv3 was withdrawn some time ago3. I doubt
this is the specific reason for the error you are seeing - that's more
likely to be possibly related to routing between datacenters, I
imagine. Hard to say what the specific issue here is. 7 out of 10
failing calls does sound unusually high, but then the timeouts are a
bit surprising too.
如果这些论坛帖子在搜索此错误时在谷歌中显示，那么老实说会很棒。
当我们等待我们的服务器人员查看TLS时，我们正在尝试联系Twitter。如果其中任何一条路线出现任何问题，将更新此帖子。
[更新3]
这篇文章正式发布一个月，没有运气！以下是我们的服务器管理员尝试过的最新步骤：
Updated all root certs in our server
Added twitter specific digi-cert (downloaded and added as files, made the SSL system look for it)
confirmed our cipher match twitters requested ciphers
Scanned our server with ssllabs.com (scans entire system and outputs details about cypers and ssl cert.) - We passed no issues found
CLI output says SHA2, the error in the Laravel stack trace says SHA1
DNS Caching issue, added DNS caching to server (there wasn't any before)
way to tell curl what cert to use, manually told it to use twitters cert, no clear problem reported, wasn't getting expected responses though.
insured certs are not expired.
3 common SSL issues with cURL: destination does not like cypher, does not like protocol, private key has expired.
Sever admin went through all twitter dev info. (https://developer.twitter.com/en/docs/basics/authentication/guides/tls)
我们已经在CLI中运行了cURL，并且启用了详细模式，当PASSES输出如下：
curl -v'https://api.twitter.com/oauth2/token'
* Hostname was NOT found in DNS cache
* Trying 104.244.42.130...
* Connected to api.twitter.com (104.244.42.130) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to api.twitter.com:443
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to api.twitter.com:443
当它通过时，它看起来像：
* Hostname was NOT found in DNS cache
* Trying 104.244.42.2...
* Connected to api.twitter.com (104.244.42.2) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* Server certificate:
* subject: C=US; ST=California; L=San Francisco; O=Twitter, Inc.; OU=Twitter Security; CN=api.twitter.com
* start date: 2016-06-29 00:00:00 GMT
* expire date: 2019-09-19 12:00:00 GMT
* subjectAltName: api.twitter.com matched
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
* SSL certificate verify ok.
> GET /oauth2/token HTTP/1.1
> User-Agent: curl/7.38.0
> Host: api.twitter.com
> Accept: */*
>
< HTTP/1.1 400 Bad Request
< allow: POST
< cache-control: no-cache
< content-length: 0
< content-security-policy: default-src 'none'; connect-src 'self'; font-src https://abs.twimg.com https://abs-0.twimg.com data:; frame-src 'self' twitter:; img-src https://abs.twimg.com https://*.twimg.com https://pbs.twimg.com data:; media-src 'none'; object-src 'none'; script-src https://abs.twimg.com https://abs-0.twimg.com https://twitter.com https://mobile.twitter.com; style-src https://abs.twimg.com https://abs-0.twimg.com; report-uri https://twitter.com/i/csp_report?a=NVQWGYLXFVWG6Z3JNY%3D%3D%3D%3D%3D%3D&ro=false;
< date: Thu, 21 Dec 2017 17:40:24 GMT
* Server tsa_b is not blacklisted
< server: tsa_b
< set-cookie: personalization_id="v1_Txp6AuuonT7REMqCB7vkzg=="; Expires=Sat, 21 Dec 2019 17:40:24 UTC; Path=/; Domain=.twitter.com
< set-cookie: guest_id=v1%3A151387802465523279; Expires=Sat, 21 Dec 2019 17:40:24 UTC; Path=/; Domain=.twitter.com
< status: 400 Bad Request
< strict-transport-security: max-age=631138519
< x-connection-hash: a5a497e59a35ec28ab7fae706c69598b
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-response-time: 5
< x-transaction: 006fdc83002993a0
< x-xss-protection: 1; mode=block
<
* Connection #0 to host api.twitter.com left intact
当失败时，Laravel的顶级堆栈跟踪项看起来像：
TwitterOAuthException
Unknown SSL protocol error in connection to api.twitter.com:443
in TwitterOAuth.php (line 440)
at TwitterOAuth->request('https://api.twitter.com/oauth/access_token',
'POST', 'Authorization: OAuth oauth_version="1.0",
oauth_nonce="a93b697784a0b2d3ceaaf203d4d9aff8",
oauth_timestamp="1513875885",
oauth_consumer_key="T79KMPJi0Wx64fbmwoa606gut",
oauth_verifier="5ZKcm8A2VN6muXFwOBOdTaFRGyPnA9bi",
oauth_signature_method="HMAC-SHA1",
oauth_signature="Q4DkMhNz3eImT9T%2BbbDxgVZyRno%3D"', array())
in TwitterOAuth.php (line 357)
在堆栈跟踪中，您会看到： oauth_signature_method =“HMAC-SHA1”，
在CLI成功输出中，您会看到
CN=DigiCert SHA2
一个线索？我们的服务器管理员有一个几乎完全克隆我们的服务器，他没有问题，我的本地Ubuntu 17系统没有问题，当我ssh到我的本地系统上的vagrant，运行一些苏格兰威士忌盒我不穿没问题。
我很确定我之前在这篇文章中提到过，但是，在twitter开发者论坛上有关于curl 35错误的确切问题，每个错误都没有解决方案。当您在谷歌上搜索此问题时，其中任何一个都不应该出现。
[2018年1月26日更新]
好吧，我们终于有了一些具体的信息。
我们目前有2台服务器。一个在东海岸的集群中，另一个在西部的集群中。我们的服务器管理员有一个我们服务器的克隆，在我们所在的同一个集群之一，并声称他无法重现它。好吧，他转向最终成为有问题的集群，果然，卷曲35问题开始出现。
我们目前正在与我们的主机开放对话框，我们正在将服务器迁移到正在运行的群集。
在这一点上，似乎很清楚的是，Twitter API正在反弹，偶尔会包含一个不喜欢呼叫来源的点。我们可以在代码或服务器配置中修改这个问题。
Twitter论坛上有很多类似的帖子，它们都走到了死胡同。尝试联系twitter会让您在聊天中与某些机器人交谈。所以不幸的是，如果他们还没有推特，我认为twitter不会采取任何措施来解决这个问题。
如果这最终成为解决方案，并且将此帖标记为已解决，我当然会更新此帖子。
答案 0 :(得分：0)
对于相同的症状（在失败与传递时卷曲详细输出）但是完全不同的终点我们出现以发现这个额外的卷曲选项有效地解决了这个问题：
--connect-timeout 30
答案 1 :(得分：0)
它已经过时，但是可能是MTU大小不匹配。
尝试检查主机和容器中的MTU大小。或在主机和路由器中。据我了解，握手期间的数据包标记为DoNotFragment，并且如果容器使用的MTU大小大于主机，则有时最大的packest无法到达目标并丢弃。
您可以使用此命令发现有效的MTU。
traceroute --mtu <target>
[1] https://www.computerhope.com/unix/utracero.htm
[2] https://unix.stackexchange.com/questions/59854/discover-mtu-between-me-and-destination-ip