澄潭
澄潭
> 那nginx这个proxy-next-upstream-timeout 注解有什么意义呢？跟它的名字都有点违背。 是指请求总的处理时间超过这个timeout后，就不再进行重试
@SpecialYang 我们在文档中说明下，proxy-next-upstream-timeout 这个注解和nginx的差异，并告知用户如果在配置基于超时重试时，必须做此配置，并配置的比higress.io/timeout的值要小 https://higress.io/zh-cn/docs/user/annotation-use-case#%E9%87%8D%E8%AF%95 如跟 @SpecialYang 线下沟通，这里如果完全兼容 nginx ingress，可能导致开启基于 timeout 做重试时，引入重试风暴的问题，nginx ingress 目前的默认配置也有这样的隐患。所以我们不再考虑这个功能完全兼容。 对于 proxy-next-upstream-timeout 这个注解的名字来说，当作是每次重试的 timeout，从字面理解上也是更合理的，符合用户直觉
没看到你 TCPRoute 的配置？
https://higress.cn/docs/latest/ops/how-tos/tcp-route/?spm=36971b57.24a14ac6.0.0.24dd5295RSapuD#4-%E5%88%9B%E5%BB%BA-tcproute 你创建这个了吗？创建之后看看是否监听？
- name: tcp nodePort: 32620 port: 22 protocol: TCP targetPort: 9000 这里port为什么配22，应该配9000把
> 修改 svc 的端口转发，可以监听 22 端口转发到 pod 的 9000 端口 这个我理解，但我印象中 istio 会根据 lb 的 svc 端口来关联 Gateway 资源中的端口，所以如果这里填 22，Gateway 里的端口也得是 22
https://higress.cn/docs/latest/ops/how-tos/tcp-route/?spm=36971b57.24a14ac6.0.0.24dd5295RSapuD 看上去跟这个文档配置一致，但没生效 @hanxiantao 有空帮忙看看吗
cc @luoxiner
@howardjohn I understand your suggestion, which is to make the ProtocolDetectionTimeout configuration only effective for the sidecar (as it was before), and set a fixed optimal default value for the...