We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Xray webscan listen模式启动时,若webhook端口还未开放或者 reverse的端口还未开放,则整个扫描过程中webhook和reverse功能都是失效的。 这样就严格要求了启动顺序,对于使用而言体验并不太好,建议可以改成定期检查,或者就算检查不通过,依然向webhook吐输出。
当在Retry Reverse的Warning状态时,Xray mimt返回的状态为502或500,且此时投料的URL不会进入任务队列。 一旦Listen和Reverse之间由网络波动,导致Listen进入Retry逻辑,期间经过Listen的Url任务全部丢失不说,而且严重影响了上层业务逻辑(502的原因) 检查Reverse可以异步进行,不需要高实时性,尤其对于我而言是将xray listen作为了Linux service , 导致listen和reverse有长时间的连接,这部分开销是没有必要的,可以将获取数据结果的时间间隔拉长,在退出之前再统一拉一次结果即可。
且Retry期间URL不进入任务队列的BUG建议发版修改掉!!
类似问题: #1637
The text was updated successfully, but these errors were encountered:
大部分开销都用来retry了:
大部分人的反连平台都是部署再云虚拟机,而xray是本地化,存在网络波动非常正常,但是获取reverse数据没必要这个高的实时性啊!
Sorry, something went wrong.
被去掉的数据当作连通性错误的牺牲品,避免影响整个流程执行。 反连数据的获取和webhook可以用一套逻辑,通过维护Array通过线程来完成,而不占用主流程,最好连通成功之后的请求一次多拉取点数据。
webhook确实可能存在阻塞问题,但是反连的检测是独立出来的,并不会造成阻塞,同时我也测试了一下,并没有不接受新的目标。 后面会优化一下webhook可能造成阻塞的问题
我们在xray 2.0 里面,可以自定义golang插件,理论上插件定义漏洞事件,即可实现自定义的webhook,等后续golang插件的教程出来之后,会有一个示例
No branches or pull requests
问题1:连接逻辑
Xray webscan listen模式启动时,若webhook端口还未开放或者 reverse的端口还未开放,则整个扫描过程中webhook和reverse功能都是失效的。
这样就严格要求了启动顺序,对于使用而言体验并不太好,建议可以改成定期检查,或者就算检查不通过,依然向webhook吐输出。
问题2:阻塞
当在Retry Reverse的Warning状态时,Xray mimt返回的状态为502或500,且此时投料的URL不会进入任务队列。
一旦Listen和Reverse之间由网络波动,导致Listen进入Retry逻辑,期间经过Listen的Url任务全部丢失不说,而且严重影响了上层业务逻辑(502的原因)
检查Reverse可以异步进行,不需要高实时性,尤其对于我而言是将xray listen作为了Linux service , 导致listen和reverse有长时间的连接,这部分开销是没有必要的,可以将获取数据结果的时间间隔拉长,在退出之前再统一拉一次结果即可。
且Retry期间URL不进入任务队列的BUG建议发版修改掉!!
类似问题:
#1637
The text was updated successfully, but these errors were encountered: