例行检查
功能描述
当服务完全没法访问时，比如服务器挂掉，被攻击，失联时，日志内不要暴露渠道地址，建议用渠道 id 替代。
应用场景
mec1mxoz1#
好的
bqjvbblv2#
@songquanpeng 使用随机字符串(如UUID)作为渠道ID更好，而不是递增整数。在分发令牌时，可能不希望用户自行修改渠道。目前这种渠道ID格式(如sk-token-{渠道id}),用户很容易猜测并尝试其他渠道。
sk-token-{渠道id}
ars1skjm3#
非管理员这样设置无效
332nm8kg4#
非管理员这样设置无效也就是说，非管理员不允许设置渠道，管理员可以随意设置渠道？这样似乎就很难满足给指定用户使用指定渠道的需求了。
kokeuurv5#
非管理员这样设置无效也就是说，非管理员不允许设置渠道，管理员可以随意设置渠道？这样似乎就很难满足给指定用户使用指定渠道的需求了。有个折中的办法，加一个分组，现在分组可以自定义的，把指定用于设置到指定的分组，然后渠道对应这个分组即可。就可以解决了
mefy6pfw6#
当无法与上游服务器正常连接时，仍然暴露了上游地址。
Post "https://xxx.com/v1/chat/completions?retry=0": dial tcp56.161.281.15:443: i/o timeout (reguest id: 20231121082111251409639ixPDsVQE)
6条答案
按热度按时间mec1mxoz1#
好的
bqjvbblv2#
@songquanpeng 使用随机字符串(如UUID)作为渠道ID更好，而不是递增整数。
在分发令牌时，可能不希望用户自行修改渠道。
目前这种渠道ID格式(如
sk-token-{渠道id}),用户很容易猜测并尝试其他渠道。ars1skjm3#
非管理员这样设置无效
332nm8kg4#
非管理员这样设置无效
也就是说，非管理员不允许设置渠道，管理员可以随意设置渠道？
这样似乎就很难满足给指定用户使用指定渠道的需求了。
kokeuurv5#
非管理员这样设置无效
也就是说，非管理员不允许设置渠道，管理员可以随意设置渠道？
这样似乎就很难满足给指定用户使用指定渠道的需求了。
有个折中的办法，加一个分组，现在分组可以自定义的，把指定用于设置到指定的分组，然后渠道对应这个分组即可。就可以解决了
mefy6pfw6#
当无法与上游服务器正常连接时，仍然暴露了上游地址。