simplerick-simplefun

谢谢回复。这种改动肯定不适合在这个项目上直接PR，那就变成瞎搞了。 > 1. 解决你提议的 xx-Ln 属性没有量化标准的问题，确保任何人遵照这个规则都能给出一致的属性标注 唉我觉得用户的问题用户自己解决，群组内部自己定标准也好投票决定也好。想办法把这个问题推给用户。一个群组/层级内部需求不统一，就让群组管理主持再细分。 > 2. 落实你的想法。如果你现在就在这个项目上做类似的事情，我会直接关闭相关的 issue 或者 pr。你可以先自己 fork 一个项目实践你的想法，如果我觉得新的项目完善得足够好了，我会来求你把你的成果 backport 回来。 嗯，还再考虑考虑。思路是否靠谱，能否行得通，需要付出多少时间精力，能出多少成果等等。反正太阳每天升起，现在这样大家也都挺好，不急。

I've run into the same problem, unable to issue cert. workaround: use command with option `--use-wget` here's the log(for installation): ``` [Thu 28 Mar 2024 06:44:45 AM EDT] Installing from...

Edit:今天看了一下代码，发现我之前的理解有误，修改一下： sniffing（不打开destOverride不打开routeOnly）：**不改变该连接的原始目的地ip**。只进行嗅探，**将得到的fqdn网址和该连接原始目标ip地址交给本地客户端路由模块来分流。** 此时，打开destOverride不打开routeOnly：**会把本地客户端dns模块解析出的ip地址替换为该连接的目的地ip**，并发往远端代理服务器。此时如果远端代理服务器没有开destOverride，或开启了destOverride的同时开启了routeOnly，那么最终目的地ip为本地客户端dns模块解析出的ip地址。 此时，打开destOverride打开routeOnly：**不改变该连接的原始目的地ip**。只进行嗅探，**将得到的fqdn网址交给本地客户端dns模块解析，并将fqdn网址和本地dns模块解析出的新目标ip地址的交给本地客户端路由模块来分流。**

> 在路由器上用passwall2的时候，发现路由器下游的电脑用户用reality连接方式会连接不上，看了下日志也跟这个选项有关。 默认”流量嗅探只供路由使用“是关闭的。对于下游电脑端reality配置里面的sni，xray会嗅探出来，然后去找真实的这个域名的ip，导致客户端发起请求的时候，实际上会连接到这个xray自己另外解析出来的sni域名的真实ip上面。 1.dns模块里配置IPIfNonMatch会导致未被域名规则识别的域名由xray解析。 2.如果开了destOverride，解析出来的ip就会覆盖掉原ip。 3.如果再开routeOnly，xray解析出的ip会被用于路由，但实际连接目的地ip还是原ip。（就是说，如果在路由模块里，原始ip应该直连，而xray解析域名出来的ip应该走节点，那么结果就是走节点连原始ip）

> 我的理解是 routeOnly 选项的作用是将嗅探得到的域名仅用于路由，代理目标地址仍为 IP。默认值为 false，也就是说，如果不设置这个选项，Xray-core 会将嗅探得到的域名用于路由和代理。 > > 比如一下这份Xray日志 > > ``` > 2023/12/20 10:40:42 [Info] [4114861100] proxy/http: request to Method [CONNECT] Host [47.246.137.198:443] with URL [//47.246.137.198:443] > 2023/12/20...

> > 请帮忙看下log： > > log 在哪 > > > 在相同的配置下，如果是要被代理的域名，xray发给服务端的是ip还是域名？ > > 我认为是域名，如果是ip，那么这ip也只是你客户端那边dns解析出的适合你地理位置的域名的ip，但是有些网站可能有多个IP地址，而不同的IP地址可能有不同的内容或速度，如果把你客户端dns解析的ip拿给服务端用，可能就不是服务端地理位置那儿 最佳的ip了，而如果客户端发送的是域名，那么服务端就可以根据自己的DNS设置来解析最适合的IP地址，从而提高访问的效果，我自己也试了一下，最后一行(用XXXX替换了服务器地址)： > > ``` > 2023/12/21 11:36:19 [Warning] core: Xray 1.8.6 started > 2023/12/21 11:36:23 [Info]...

I assume the change is done right? please tell me if my understanding is correct: one server can now handle multiple clients, and all we need to do is to...

经过一些测试，总结一下： 微信走fcm，需要微信必须处于关掉后台的状态。微信在后台保活的情况下，是不会接到fcm通知的。 然后，微信每次被拉起，无论是被fcm还是其他的拉起，都需要自己处理一会数据，才能读取出来新消息，这个时间我手机大概40秒。 文字信息，由于内容本身会包括在fcm里面，所以通知里面就能看到，延迟只有fcm的处理时间，大概10秒。但是你要回复这个消息，还是要等小一分钟的时间。 语音和视频的响铃，就需要彻底等微信拉起后处理好启动，等个半分钟到一分多钟，才会开始闹铃。 微信走fcm还有一个坏处，容易造成梯子ip泄露。 这里建议，工作场景下，就让微信一直保活，手机多充电就是了。或是直接用电脑微信。 个人场景下，可以考虑手机亮屏时保留微信后台，手机息屏后杀掉微信后台。亮屏时关闭微信并不能明显节约电量，除非消息很多（注意关闭/切断其他应用的微信推送功能，或直接杀后台）；息屏时杀掉微信能节约的电量相比总息屏耗电而言还是可观的。原理是cpu频率相关。 这样，亮屏时能及时接收消息，息屏时人在休息状态，不能及时接收消息，如果有紧急情况，仍可以通过传统打电话的方式接听。 如果设置成息屏杀掉微信后台，走fcm接收消息，又会有一个问题：息屏后微信被fcm拉起，不会被自动杀掉，就会一直保留息屏后台。手动设置规则杀掉后台（如fcm通知后2.5分钟，息屏状态，杀掉微信），则会把新消息的通知一并杀掉。 所以我选择，非工作场合，不去及时接收微信消息；工作场合，尽量用电脑接收。亮屏拉起微信，接收消息，息屏杀微信后台。 最后，能不用微信，少用吧。

I'm in the same shoe as OP, just want to share my situation&experience: I'm using HAProxy as a front load balancing proxy based on sni for my services. For my...

> 欢迎试用[shadow-tls-android](https://github.com/maskedeken/shadow-tls-android/releases/tag/v0.0.1) 测试了不好用，可能是跟我这个issue相同的问题 https://github.com/ihciah/shadow-tls/issues/45#issue-1457012655