vmess-ws "security": "auto"

[AKotov-dev]

Hello. I have a simple, working server vmess-ws (XRay-v.1.7.5):

  {
  "log": {
    "access": "",
    "error": "",
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "port": 8080,
      "protocol": "vmess",
      "settings": {
      "udp": false,
      "clients": [
      {
        "id": "174a501d-ad41-4c3b-8b2b-cdf05dc83f93",
        "alterId": 0,
        "email": "t@t.tt"
      }
    ],
    "allowTransparent": false
      },
      "streamSettings": {
      "network": "ws",
      "security": "auto",
      "wsSettings": {
      "path": "/vmess",
      "headers": {
        "Host": "example.com"
      }
    }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": []
  }
}

After upgrading to Xray-linux-64 v1.8.0, the parameter "security": "auto" is not perceived and starts working only after its removal. Accordingly, in the client configuration "sсy":"auto" also gives an error.

Is this parameter "security": "auto" no longer needed? Thanks.

p.s. I am a beginner and do not understand the entire technological chain well. I just saw a problem at home and decided to report it. :). After all, if you use any free mass configuration, for example from sshocean.com , then this parameter is still present there and it's strange. For example, here is one of them for the client (see "scy": "auto"):

{
  "v": "2",
  "ps": "sshocean-marsik",
  "add": "am1.v2rayserv.com",
  "port": "80",
  "id": "863041cd-d4db-49f7-ab14-00a178cc2016",
  "aid": "0",
  "scy": "auto",
  "net": "ws",
  "type": "none",
  "host": "am1.v2rayserv.com",
  "path": "/vmess",
  "tls": "none",
  "sni": "am1.v2rayserv.com",
  "alpn": ""
}

Sincerely, Alex

[Nyar233]

server example:

{
    "log": {
        "loglevel": "warning"
    },
    "routing": {
        "domainStrategy": "AsIs",
        "rules": [
            {
                "type": "field",
                "ip": [
                    "geoip:private"
                ],
                "outboundTag": "block"
            }
        ]
    },
    "inbounds": [
        {
            "listen": "0.0.0.0",
            "port": 1234,
            "protocol": "vmess",
            "settings": {
                "clients": [
                    {
                        "id": ""
                    }
                ]
            },
            "streamSettings": {
                "network": "ws",
                "security": "tls",
                "tlsSettings": {
                    "certificates": [
                        {
                            "certificateFile": "/path/to/certificate.crt",
                            "keyFile": "/path/to/key.key"
                        }
                    ]
                }
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "freedom",
            "tag": "direct"
        },
        {
            "protocol": "blackhole",
            "tag": "block"
        }
    ]
}

client example:

{
    "log": {
        "loglevel": "warning"
    },
    "routing": {
        "domainStrategy": "AsIs",
        "rules": [
            {
                "type": "field",
                "ip": [
                    "geoip:private"
                ],
                "outboundTag": "direct"
            }
        ]
    },
    "inbounds": [
        {
            "listen": "127.0.0.1",
            "port": "1080",
            "protocol": "socks",
            "settings": {
                "auth": "noauth",
                "udp": true,
                "ip": "127.0.0.1"
            }
        },
        {
            "listen": "127.0.0.1",
            "port": "1081",
            "protocol": "http"
        }
    ],
    "outbounds": [
        {
            "protocol": "vmess",
            "settings": {
                "vnext": [
                    {
                        "address": "",
                        "port": 1234,
                        "users": [
                            {
                                "id": "",
                                "security": "none"
                            }
                        ]
                    }
                ]
            },
            "streamSettings": {
                "network": "ws",
                "security": "tls",
                "tlsSettings": {
                    "fingerprint": "chrome" // uTLS fingerprint as traffic camouflage, can be either "chrome" or "firefox" or deleted entirely to disable uTLS
                }
            },
            "tag": "proxy"
        },
        {
            "protocol": "freedom",
            "tag": "direct"
        }
    ]
}

[chika0801]

https://xtls.github.io/Xray-docs-next/config/transport.html#streamsettingsobject

security: "none" | "tls" | "reality"

security 只有这3个选项了。

[Nyar233]

https://xtls.github.io/Xray-docs-next/config/transport.html#streamsettingsobject

security: "none" | "tls" | "reality"

security 只有这3个选项了。

他在streamSettings块里写的"security": "auto"，其实是把vmess的入栈跟streamSettings搞混了

[AKotov-dev]

@chika0801, @Nyar233 Thank you very much. I replaced the server with "security": "none" and now everything is working. And as for the client, the error was in the parser, to which xray-v1.7.5 did not react, but xray-v1.8.0 began to react. Probably v1.8.0 is smarter than v1.7.5.

And one more question, taking the opportunity of our communication, if you don't mind. Please do not laugh out loud if the question seems silly... :)

I usually download configurations (vmess, vless, ss, trojan and their varieties) from free sources to experiment. I check my configurations that my GUI builds with those that are created in v2rayN (Windows on QEMU) or Qv2ray in Linux (but this one does not understand trojan configurations). That's why I'm building configurations piece by piece until it all works. At the same time, it is necessary to take into account the various types/encapsulations of these basic protocols. This process is painfully long and painstaking. To put it jokingly: "I need to drink at least two bottles of vodka to get a working configuration file for XRay client." :)

Last question: Is there any established/stable method to create configurations for the client based on the received server configurations?

In other words:

1. I view the server connection string, define the protocol, decode configuration, pull out the parameters and building my own configuration.json for client...

2. { Insert block_1 + parameters }, { Insert block_2 + parameters }, { Insert block_3 + parameters }, ...etc.

Is it possible to bring all this to some logical sequence in order to create configurations in a more convenient way, breaking any server configurations into standard client blocks? Thanks. :)

Sincerely, Alex

[chika0801]

I view the server connection string, define the protocol, decode configuration, pull out the parameters and building my own configuration.json for client...

To the best of my knowledge, there is no such tool.

[AKotov-dev]

Thank you very much, @chika0801. Ok. I will close this issue so as not to distract you. All the best to you.

Sincerely, Alex

[RPRX]

建议新手从套模板开始：https://github.com/XTLS/Xray-examples

（该 issue 非 Xray 的问题，所以我将以另一种方式关闭它）