我们有一个 haproxy 实例，我们的应用程序之一仅支持 TLSv1.0。当它尝试通过此 haproxy 连接时，它会因握手失败而失败。
我如何在此 haproxy 实例上启用 TLSv1.0 支持。下面是我的 haproxy.cfg
global
daemon
log /var/log local0 debug
maxconn 4000
ssl-default-bind-options no-sslv3
tune.ssl.default-dh-param 2048
stats socket /var/lib/haproxy/stats
#---------------------------------------------------------------------
defaults
mode http
log global
option httplog
option dontlognull
option http-server-close
option forwardfor except 127.0.0.0/8
option redispatch
retries 3
timeout http-request 10m
timeout connect 10s
timeout client 10s
timeout server 10s
#---------------------------------------------------------------------
frontend api_passthrough
bind *:443 ssl crt /usr/local/etc/certs/ ciphers CECPQ1-RSA-AES256-GCM-SHA384:CECPQ1-RSA-CHACHA20-POLY1305-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-CCM:DHE-RSA-AES256-CCM:DHE-RSA-AES128-CCM8:DHE-RSA-AES256-CCM8:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA256-SHA256:DHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CAMELLIA128-SHA256:ECDHE-RSA-CAMELLIA256-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:CECPQ1-ECDSA-AES256-GCM-SHA384:CECPQ1-ECDSA-CHACHA20-POLY1305-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-CCM:ECDHE-ECDSA-AES256-CCM:ECDHE-ECDSA-AES128-CCM8:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-SHA:DHE-DSS-AES128-GCM-SHA256:DHE-DSS-AES256-GCM-SHA384:DHE-DSS-CAMELLIA128-SHA256:DHE-DSS-CAMELLIA256-SHA256
log /dev/log local0 debug
use_backend hapstats if { path_beg /stats } …我在这样的函数中运行 FastApi 和 guvicorn：
if __name__ == "__main__":
uvicorn.run(
app="app.main:app",
host="HOSTIP",
port=8000,
reload=True,
# log_config=None,
log_config=log_config,
log_level="info"
)
这就是我的 log_config 的样子：
log_config = {
"version": 1,
"disable_existing_loggers": True,
"formatters": {
"default": {
"()": "uvicorn.logging.DefaultFormatter",
"fmt": "%(asctime)s::%(levelname)s::%(name)s::%(filename)s::%(funcName)s - %(message)s",
"use_colors": None,
},
"access": {
"()": "uvicorn.logging.AccessFormatter",
"fmt": '%(asctime)s::%(levelprefix)s %(client_addr)s - "%(request_line)s" %(status_code)s',
},
},
"handlers":
{
"default":
{
"formatter": "default",
# "class": 'logging.NullHandler',
"class": 'logging.FileHandler',
"filename": CONFIG[SECTION]["default"]
},
"error":
{
"formatter": "default",
# "class": 'logging.NullHandler',
"class": 'logging.FileHandler',
"filename": CONFIG[SECTION]["error"]
},
"access": …当我使用 HAproxy 作为负载均衡器时，在 HTTP 终止模式下，我跟踪它的日志
（尾-f /var/log/haproxy.log）。出现的日志有2种类型
[time] frontend_name/1: SSL handshake failure
和
[time] frontend_name~ message
frontend_name是 /etc/haproxy/haproxy.cfg 中前端关键字配置的名称
我不知道日志消息中的/1和~是什么，以及为什么日志中出现 SSL 握手失败~ 有人可以帮我解释并修复此错误吗？谢谢！
我正在使用appsession配置元素进行粘性会话.我有5个weblogic实例,其中3个处于活动状态,并且当负载增加时立即服务加载我开始另外2个实例.现在HAProxy将它们标记为"Helthy",但不会传输任何流量,因为它很粘.
如何将现有会话转移到新的weblogic服务器.我使用Terracotta进行会话群集,因此服务请求的服务器无关紧要.下面是我对HAProxy的配置.
# this config needs haproxy-1.1.28 or haproxy-1.2.1
global
log 127.0.0.1 local0
maxconn 1024
daemon
# debug
#quiet
defaults
log global
mode http
option httplog
option httpchk
option httpclose
retries 3
option redispatch
contimeout 5000
clitimeout 50000
srvtimeout 50000
stats uri /admin?stats
stats refresh 5s
listen terracotta 0.0.0.0:10001
# balance url_param JSESSIONID
balance roundrobin
option httpchk OPTIONS /Townsend
server L1_1 10.211.55.1:7003 check
server L1_2 10.211.55.2:7004 check
server L1_3 10.211.55.3:7004 check
appsession JSESSIONID len 52 timeout 3h
我正在尝试在haproxy上安装haproxy comodo positivessl但浏览器显示证书错误.HaProxy配置:
global
daemon
#debug
maxconn 15000
pidfile /var/run/haproxy.pid
stats socket /var/run/haproxy.stat mode 600
defaults
mode http
balance roundrobin
timeout client 60s # Client and server timeout must match the longest
timeout server 60s # time we may wait for a response from the server.
timeout queue 60s # Don't queue requests too long if saturated.
timeout connect 4s # There's no reason to change this one.
timeout http-request 5s
option http-server-close
option httpclose
option abortonclose
option redispatch
option …我有REST API.
为简单起见,我想说有两项服务:
我怎样才能将所有读取请求(GET方法)重写为read.request.com,并将所有写入请求(POST,PUT,DELETE方法)重写为带有HAProxy的write.request.com？
我们正在使用微服务架构,其中顶级服务用于向最终用户公开REST API,后端服务用于查询数据库.
当我们收到1个用户请求时,我们会向后端服务提出~30k的请求.我们使用RxJava进行顶级服务,因此所有30K请求都是并行执行的.我们使用haproxy在后端服务之间分配负载.但是,当我们得到3-5个用户请求时,我们将获得网络连接异常,无路由到主机异常,套接字连接异常.
这种用例的最佳实践是什么？
我们最近从citrix切换到HAProxy，以实现负载平衡。
问题在于，对于某些请求，HAProxy开始给出400错误（以前在citrix上正常工作）。因此，我们暂时从基于HTTP的负载平衡转向了基于TCP的负载平衡。
在进一步调查中，我们发现某些请求的HTTP标头中有多余的空间，这会导致400错误。
profileID<space>:value
vs
profileID:value
这些请求来自android应用，因此我们无法更改源代码。
我们正在尝试回到基于http的负载平衡。
是否有任何配置设置可能会让我们忽略空间。
我正在尝试为Azure SQL实例配置HAProxy负载均衡器,我的配置文件如下;
defaults
mode tcp
balance leastconn
timeout client 30000ms
timeout server 30000ms
timeout connect 3000ms
retries 3
listen sql-db
bind *:81
mode tcp
balance leastconn
option log-health-checks
server DB-1 ********.database.windows.net:1433 check port 1433 inter 1000
在Azure VM上定位SQL Server实例时,此配置文件可正常工作.但是,在针对Azure SQL时,由于登录失败,连接被拒绝:"无法打开服务器" ..."登录请求.登录失败.(.Net SqlClient Data Provider)"我100%确定用户名/密码是否正确.他们一定是迷路了.
任何想法为什么会这样？
谢谢你,杰森
我们使用以下方法将URL映射文件加载到HAProxy中：
http-request redirect location %[capture.req.uri,map(/etc/haproxy/redirects.map)] code 301 if { capture.req.uri,map(/etc/haproxy/redirects.map) -m found }
地图文件中一行的示例为：
/shop-by-category /products
此重定向按预期工作。我遇到的唯一问题是使用/ shop-by-category路径传递查询字符串时。例如：
/shop-by-category?testingquerystring=test
这不会重定向。
我尝试将我认为是HAProxy查询变量的内容添加到重定向映射中，例如：
/shop-by-category&%[query] /parts&%[query]
但是，HAProxy在地图文件中似乎无法识别出这一点。有什么方法可以让HAProxy动态识别查询字符串并在重定向时将其传递通过？
haproxy ×10
ssl ×2
architecture ×1
citrix ×1
config ×1
fastapi ×1
frontend ×1
handshake ×1
http ×1
http-headers ×1
networking ×1
python-3.x ×1
rx-java ×1
tls1.0 ×1
uvicorn ×1