If you happen to have access to the gateway’s Traffic page in TTN Console, then you can also see the full LoRaWAN packet. When decoding that you might see some MAC commands in FOpts then, which you could try to decipher, like shown in LMIC Library Always Does Unwanted Downlink - #10 by arjanvanb (AU915-928) and ADR problems - node of the same type have different ADR behaviour - #11 by arjanvanb (EU868).
You might also run into FCtrl being hexadecimal 0xA0, or binary 0b10100000, which along with:
…actually indicates it’s indeed an ACK, but also that there are zero bytes in FOpts. So, that apparently indicates ADR does not require any changes on the device, as FOpts includes no MAC commands whatsoever.
The Trace part in the Traffic might show things like:
networkserver ttn-networkserver-eu set ack reason: adr-ack-req
…indicating the node indeed requested an ADR downlink by setting the ADRACKReq bit in the FCtrl of its last uplink:
(Also, clicking the preceding uplink in the gateway’s Traffic page sometimes shows some details in its Trace part, especially in case of errors.)