serverName和dest是不是要一致？

[guigeng]

如果"dest": "nextcloud.xxxx.com"服务器的nextcloud "serverNames": "vless.xxxx.com" 这里设置给reality的域名 tcp反向代理设置的sni是设置dest还是serverName？

{
    "inbounds": [ // 服务端入站配置
        {
            "listen": "0.0.0.0",
            "port": 443,
            "protocol": "vless",
            "settings": {
                "clients": [
                    {
                        "id": "", // 必填，执行 ./xray uuid 生成，或 1-30 字节的字符串
                        "flow": "xtls-rprx-vision" // 选填，若有，客户端必须启用 XTLS
                    }
                ],
                "decryption": "none"
            },
            "streamSettings": {
                "network": "tcp",
                "security": "reality",
                "realitySettings": {
                    "show": false, // 选填，若为 true，输出调试信息
                    "dest": "example.com:443", // 必填，格式同 VLESS fallbacks 的 dest
                    "xver": 0, // 选填，格式同 VLESS fallbacks 的 xver
                    "serverNames": [ // 必填，客户端可用的 serverName 列表，暂不支持 * 通配符
                        "example.com",
                        "www.example.com"
                    ],
                    "privateKey": "", // 必填，执行 ./xray x25519 生成
                    "minClientVer": "", // 选填，客户端 Xray 最低版本，格式为 x.y.z
                    "maxClientVer": "", // 选填，客户端 Xray 最高版本，格式为 x.y.z
                    "maxTimeDiff": 0, // 选填，允许的最大时间差，单位为毫秒
                    "shortIds": [ // 必填，客户端可用的 shortId 列表，可用于区分不同的客户端
                        "" // 若有此项，客户端 shortId 可为空
                        "0123456789abcdef" // 0 到 f，长度为 2 的倍数，长度上限为 16
                    ]
                }
            }
        }
    ]
}

[flowerinsnowdh]

serverNames是reality握手用的，dest是回落用的；客户端会使用serverNames中的SNI与节点服务器进行握手，若握手不通过，节点服务器则会反向代理到dest；它们按理来说应该填写一样的

serverNames如果和客户端不匹配，无法握手通过，节点也就不能正常使用

进行回落时，会由dest所设置的服务器发送证书过来，如果客户端使用的是serverNames中的SNI，那么可能会因为通用名称不匹配而收到证书验证失败的不安全提示，但是不进行回落时可以正常通过节点上网，显得不够真实

所以建议这两个设置成一样的，即让外表看上去“客户端正在访问这个网页，而我主动访问过去也确实是这个网页”

[guigeng]

那就了解了。谢谢

[RPRX]

上面的解释有误，实际上始终会把 TLS Client Hello 转发至 dest

可以不一致，这个话题讲过很多次了，你发 issue 前应当先搜索

而且 issue 区是用来提出潜在 bug 的，现在全都在问问题，置顶提示完全没用，真反馈 bug 的非常少，要不我们把 issue 区关了吧

[RPRX]

GitHub 什么时候出一个真转移 issue 到 discussion 的功能，访问原 url 会直接跳转到新 url，而不是保留原 issue

[flowerinsnowdh]

GitHub 什么时候出一个真转移 issue 到 discussion 的功能，访问原 url 会直接跳转到新 url，而不是保留原 issue

用模板告知?

[RPRX]

模板已写好，还未放出来。我是想处理历史 issue，问题类的都转移到 discussion，而且不想保留原 issue。

[RPRX]

作为项目维护者，看到 issue 区都是些提问，而且还有重复的，真的挺心烦的。它在 issue 区，就会得到某种处理，一般提问的我都会顺便回答一下，多少会占时间，而不像 discussion 区可以不理。别的项目 issue 区都是些技术性的 bug 反馈，大概只有这个破项目是一堆使用类的提问，@ 开发者答疑，就是因为没用模板强制。另外今年回来后我总是在思考一个问题，我愿意在这里花时间是为了推进信息与言论自由，反审查，写点代码，自己也用用，而不是为了在这里开免费 IT 教学班。即，我没有义务去花时间回答任何提问（当然，写代码也不是义务性的），下至 Linux / Go 的基础问题，应自己去搜索，上至 REALITY 的专业问题，应自己去看代码，都不应该让我单独花时间去回答。我并没有义务将我所拥有的任何知识，单独花时间分享出来，若有必要，应当写在文章中。写文章同样不是义务性的，我也懒得写，但是不写的话，别人就无法领会到设计的精妙之处，出现各种错误解读，这个也挺烦的。

[RPRX]

To 768 L：是的，这是个问题，找找有没有能推送 discussion 的 bot

[RPRX]

GitHubBot 不推送 discussion，这个现象早就发现了，并且看起来它没有开发计划，大家另找一个 bot 把它给换掉吧