Could you provide a PCAP or Chrome Network log (https://dev.chromium.org/for-testers/providing-network-details) showing this?

There are two places that curves are used. There's the acceptable curves for the server certificate and the set of curves that will be used on each connection when talking with the client.

OpenSSL 1.1.0 had part of this behavior broken and might error out there.

Since Chrome will prefer X25519, this really isn't a Chrome side issue, since a correctly working server that is actually refusing X25519 should fail to connect with Chrome, so it sounds like your nginx configuration isn't explicitly preventing X25519 (If its unspecified nginx/OpenSSL default to a wide array of curves).

You should be able to explicitly specify particular curves in nginx (using the 'ssl_ecdh_curve' command, though only on newer versions of nginx) if you'd like to restrict X25519, though its not recommended since most implementations prefer X25519 over any of the P-* curves.

^ That is, if Chrome were doing X25519 when the server didn't support it, the server should fail to connect, so if you're getting a successful connection over X25519, this is a server configuration issue.

thanks to you two.
I finally figured it out.
svaldez@chromium.org is right.

My understanding:
ECC cert use a curve and the key exchange procedure also use a curve.
These two can often and indeed be different.
However, if you 
    set ssh_ecdh_curve X25519;
into the Nginx under openssl 1.1.0c 
the Nginx/openssl will use X25519 to both the two places above .which is not correct because X25519 can only be used in key exchange.

My solution is:
1. Do not set ssh_ecdh_curve , then the nginx will use its default settings, which can reach my goals becasue chrome will prefer X25519, but this is not recommended because you can not control the nginx's default setings(seems to be P-256).
2. explicitly set ssh_ecdh_curve X25519:spec284r1; this is perfect for me

sorry , the last line of Comment4 is  ssh_ecdh_curve X25519:spec384r1  
not 284