transport/internet/tcp: REALITY: processed invalid connection

[Qlub53]

Cannot connect to Xray server via VLESS+Reality. Not sure what I did wrong. I tried my best following the official examples for both server and client configs.

Xray server log

...
REALITY remoteAddr: <my>.<client>.<public>.<ip>:<port>
REALITY remoteAddr: <my>.<client>.<public>.<ip>:<port>  hs.c.AuthKey[:16]: [<hidden>]   AEAD: *aes.gcmAsm
REALITY remoteAddr: <my>.<client>.<public>.<ip>:<port>  hs.c.ClientVer: [1 8 2]
REALITY remoteAddr: <my>.<client>.<public>.<ip>:<port>  hs.c.ClientTime: 2023-11-14 **:**:**
REALITY remoteAddr: <my>.<client>.<public>.<ip>:<port>  hs.c.ClientShortId: [<hidden>]
REALITY remoteAddr: <my>.<client>.<public>.<ip>:<port>  hs.c.conn == conn: true
REALITY remoteAddr: <my>.<client>.<public>.<ip>:<port>  hs.c.handshakeStatus: 0
2023/11/14 **:**:** [Info] transport/internet/tcp: REALITY: processed invalid connection
...

Server config

Xray v1.8.4 server config, based off of https://github.com/chika0801/Xray-examples/blob/main/VLESS-XTLS-uTLS-REALITY/config_server.json

{
  "log": {
    "loglevel": "info"
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "outboundTag": "block",
        "domain": [
          "geosite:category-ads-all",
          "geosite:cn"
        ]
      },
      {
        "type": "field",
        "outboundTag": "block",
        "ip": [
          "geoip:cn"
        ]
      }
    ]
  },
  "inbounds": [
    {
      "port": 443,
      "listen": "0.0.0.0",
      "protocol": "vless",
      "settings": {
          "clients": [
              {
                  "id": "MY_UUID",
                  "flow": "xtls-rprx-vision",
              }
          ],
          "decryption": "none"
      },
      "streamSettings": {
          "network": "tcp",
          "security": "reality",
          "realitySettings": {
              "show": true,
              "xver": 1,
              "dest": "www.lovelive-anime.jp:443",
              "serverNames": [
                  "www.apple.com"
              ],
              "privateKey": "<hidden>",
              "shortIds": [
                  "", "6ba85179e30d4fc2"
              ]
          }
      },
      "sniffing": {
          "enabled": true,
          "destOverride": [
              "http",
              "tls",
              "quic"
          ],
          "routeOnly": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}

Client config

Clash.Meta kernal v1.15.0 client config, based off of Clash.Meta official example

...

proxies:
  - name: VLESS+Reality
    type: vless
    server: my.server.domain
    port: 443
    uuid: MY_UUID
    network: tcp
    tls: true
    udp: true
    flow: xtls-rprx-vision
    servername: www.apple.com
    reality-opts:
      public-key: <hidden>
      short-id: 6ba85179e30d4fc2
    client-fingerprint: chrome

...

[kingwilliam]

server config

   "show": true,
   // "xver": 1,   <-- try to delete this line
   "dest": "www.lovelive-anime.jp:443",

[Qlub53]

Hi @RPRX @chika0801, could you spot what I'm missing?🙏thank you so much

[zxbiao]

或许你应该用Xray-core的客户端试下，如果行就是Clash.Meta的原因，毕竟V1.14.X说了REALITY 是实验性支持，可能存在兼容性问题1.15版本或许还是实验性支持。 Maybe you should try it with the Xray-core client. If it works, it's because of Clash.Meta. After all, V1.14.X said REALITY is experimental support and may have compatibility issues. Version 1.15 may still be experimental support.

[chika0801]

服务端配置中

"xver": 使用0。如果你使用偷自己的形式才可能考虑写1。

"dest": "www.lovelive-anime.jp:443", "serverNames": [ "www.apple.com" ],

dest 这里填写的网址，建议是和在 serverNames 填写的要一样。你试一下。

[Qlub53]

服务端配置中

"xver": 使用0。如果你使用偷自己的形式才可能考虑写1。

"dest": "www.lovelive-anime.jp:443", "serverNames": [ "www.apple.com" ],

dest 这里填写的网址，建议是和在 serverNames 填写的要一样。你试一下。

xver: 0 is the fix. 👍 xver: 1 is only good for falling back to another inbound.

But dest and serverNames didn't seem to have to be same, though. What's the worst that could happen if they stay different? @chika0801

[chika0801]

But dest and serverNames didn't seem to have to be same, though. What's the worst that could happen if they stay different?

When using REALITY's Steal Your Own form, the serverNames parameter in the server-side configuration can be filled in with URLs that are different from those in your own SSL certificate. The URL of the serverNames parameter in the client configuration must be one of the serverNames of the server. Similarly, if you are not using Steal Your Own Form, you can also try when the destination URL of the dest parameter is not the same as the URL written in the serverNames parameter of your server-side configuration in the SSL certificate. After you fill in the client configuration, the client can successfully access the proxy site.

Client serverNames parameter, that is, SNI, network firewalls through the SNI to see what domain name you visit. For example, in mainland China, this SNI domain name should not be a government banned URL, because it can be viewed by the firewall.

This is my understanding, if you have other please ask again.

Translated with www.DeepL.com/Translator (free version)

[Qlub53]

😊 Thanks for your speedy response, @chika0801

With all you've explained, if I'm not "stealing from my own", having inconsistent dest and serverNames server-side won't have any adverse consequences, correct?

Are there documentations explaining "stealing from one's own" in detail? I haven't come across any, yet.

(Also please feel free to respond in Chinese if that makes it easier for you, I'll take care of the translation. But it was very kind of you. 😊)

[chika0801]

With all you've explained, if I'm not "stealing from my own", having inconsistent dest and serverNames server-side won't have any adverse consequences, correct?

I'll talk about my test results. The server side dest parameter is filled in the URL such as 1.com. servername parameter is filled in the URL such as 2.com. 1.com its SSL certificate may be a special kind of, when the SNI and SSL certificate contains the URL is not the same, can also be "verified", at this time you with the client test, the client can access the website to be proxied.

But not the Dest you are looking for to fill in the URL, can have this effect. So if others ask me, I usually suggest that servername keep and dest parameters filled in the same URL. And this site can not be in your country's IP address, also can not be your country's laws prohibit the site. Otherwise the consequence is that your VPS IP may be blocked by your country's firewall.

Translated with www.DeepL.com/Translator (free version)

[chika0801]

Are there documentations explaining "stealing from one's own" in detail? I haven't come across any, yet.

The effect of this approach is that the TLS fingerprint on the server side is, for example, that of NGINX, not the GO program. When stealing your own form, your own SSL certificate is provided by you, perhaps the reliable aspect of your own grasp more have the initiative. Or you have a domain name, apply for a free SSL certificate is also a basic operation. My own commonly used VPS are used to steal their own form.

These experiences come partly from Xray's TG group, and partly from author RPRX's reply in a post here. I am time to read more content, so that there is the experience.

[Qlub53]

the TLS fingerprint on the server side is, for example, that of NGINX, not the GO program. When stealing your own form, your own SSL certificate is provided by you

Then am I "stealing from my own" like this? @chika0801

⤵️ server config

```json { "inbounds": [ { "port": 443, "listen": "0.0.0.0", "protocol": "vless", "settings": { "decryption": "none", "clients": [ { "id": "*************************", "flow": "xtls-rprx-vision" } ] }, "streamSettings": { "network": "tcp", "security": "reality", "realitySettings": { "privateKey": "**********************", "serverNames": [ "www.lovelive-anime.jp" ], "xver": 1, "dest": "@trojan-tcp" } }, "sniffing": { "enabled": true, "routeOnly": true, "destOverride": [ "http", "tls", "quic" ] } }, { "listen": "@trojan-tcp", "protocol": "trojan", "settings": { "clients": [ { "password": "*******" } ], "fallbacks": [ { "dest": "www.lovelive-anime.jp:443" }, ] }, "streamSettings": { "network": "tcp", "security": "tls", "tcpSettings": { "acceptProxyProtocol": true }, "tlsSettings": { "certificates": [ { "certificateFile": "/usr/local/certs/my.domain.com.pem", "keyFile": "/usr/local/certs/my.domain.com.key.pem" } ] } } } ] } ```

[chika0801]

I looked at your configuration and you're still back to the trojan protocol configuration in Xray via the @trojan-tcp pipeline, at which point the SSL certificate is loaded by Xray (GO's TLS fingerprint). It wouldn't be me expressing steal yourself. The form I'm expressing, either through the long unix pipe or 127.0.0.1:XX, the other program passed to is using nginx (which you can of course replace with caddy (caddy's TLS fingerprint is GO's as I recall).