It looks fine?

~ $ curl -vI https://app.vlaine.ru

• Host app.vlaine.ru:443 was resolved.
• IPv6: (none)
• IPv4: 69.46.46.87
• Trying 69.46.46.87:443...
• ALPN: curl offers h2,http/1.1
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• SSL Trust Anchors:
• CAfile: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
• TLSv1.3 (IN), TLS handshake, Server hello (2):
• TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
• TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
• TLSv1.3 (IN), TLS handshake, Certificate (11):
• TLSv1.3 (IN), TLS handshake, CERT verify (15):
• TLSv1.3 (IN), TLS handshake, Finished (20):
• TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
• TLSv1.3 (OUT), TLS handshake, Finished (20):
• SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / id-ecPublicKey
• ALPN: server accepted h2
• Server certificate:
• subject: CN=app.vlaine.ru
• start date: Aug 7 11:44:59 2026 GMT
• expire date: Nov 5 11:44:58 2026 GMT
• issuer: C=US; O=Let's Encrypt; CN=YE1
• Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
• Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
• Certificate level 2: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
• Certificate level 3: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
• subjectAltName: "app.vlaine.ru" matches cert's "app.vlaine.ru"
• SSL certificate verified via OpenSSL.
• Established connection to app.vlaine.ru (69.46.46.87 port 443) from 10.0.0.179 port 49426
• using HTTP/2
• [HTTP/2] [1] OPENED stream for https://app.vlaine.ru/
• [HTTP/2] [1] [:method: HEAD]
• [HTTP/2] [1] [:scheme: https]
• [HTTP/2] [1] [:authority: app.vlaine.ru]
• [HTTP/2] [1] [:path: /]
• [HTTP/2] [1] [user-agent: curl/8.18.0]
• [HTTP/2] [1] [accept: /]

HEAD / HTTP/2

Host: app.vlaine.ru

User-Agent: curl/8.18.0

Accept: /

• Request completely sent off
• TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
• TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):

< HTTP/2 307

HTTP/2 307

< date: Mon, 31 Aug 2026 05:00:03 GMT

date: Mon, 31 Aug 2026 05:00:03 GMT

< location: /welcome

location: /welcome

< server: railway-hikari

server: railway-hikari

< x-railway-request-id: IoTGI6YBRByI_OeknpoFkQ

x-railway-request-id: IoTGI6YBRByI_OeknpoFkQ

< x-hikari-trace: sin1.tr00

x-hikari-trace: sin1.tr00

< x-railway-edge: sin1

x-railway-edge: sin1

<

• Connection #0 to host app.vlaine.ru:443 left intact

Could it be your local DNS cache pointing to the wrong server?

I flushed the local DNS cache and tested again.

DNS resolves correctly:

app.vlaine.ru -> 0y2riqzq.up.railway.app -> 69.46.46.87

The issue remains intermittent at the TLS layer.

openssl s_client can fail with:

unexpected eof while reading

no peer certificate available

SSL handshake has read 0 bytes

while Railway CLI reports the domain as ACTIVE, DNS propagated and certificate VALID.

For comparison, vlaine.ru on Vercel from the exact same machine/network completes TLS successfully and returns HTTP/2 200.

The native Railway domain also works.

This makes a local DNS cache issue unlikely. Could you please investigate the TLS/SNI binding or routing for app.vlaine.ru on the Railway edge?

Weird...

I can't seem to replicate using a vpn to hit different edge servers: osl1, ams1, lhr1, sin1.

Can you share the output of:

curl -vI https://app.vlaine.ru

openssl s_client -debug --connect app.vlaine.ru:443

Everything looks setup correctly on my end.