When every reading is nan

Start from what it is printing

There is nothing else to go on. The sensor cannot report a fault — it has no way to say "I am here but I am cold" or "you asked too soon". Either forty valid bits arrive or they do not, and everything else is inference from what your sketch prints.

The order to check in

First, the sensor type. It is one word in the sketch, it is not detectable, and it causes both of the two most common symptoms: total silence when a DHT11 is declared as a DHT22, and absurd numbers when the decoders are crossed. Blue cage is DHT11, white cage is DHT22.

Then the pin count. Count from the square pad: GND, VCC, NC, DATA. The third pin is connected to nothing on the board, so wiring by position and being one place out gives you a data line on a dead pad — which looks exactly like a dead sensor.

Then the supply. Is VCC on a rail that is actually powered, and is that rail the same voltage as your pins expect? A sensor with no supply is silent, and a sensor on the wrong supply usually works and quietly stresses the input pin.

Then the timing. A number that never changes is the library's two-second cache, not a stuck sensor.

Last, the placement. A reading two degrees high on wiring that is otherwise perfect is not a fault at all — the sensor is telling you accurately how warm your board is.

What "nan" actually is

readTemperature() and readHumidity() return NAN rather than throwing or returning a flag. It prints as nan, and it compares false against everything including itself, so:

if (celsius == NAN)     // never true, ever
if (isnan(celsius))     // this one

That is the only check that works, and it is why every sketch in this handbook has it. Printing a bare nan into a graph or a web page is how a wiring fault gets mistaken for a sensor that reads zero.

When it is genuinely intermittent

One failure in a hundred is the protocol, not your build. The forty bits are measured by counting loop iterations with interrupts off, and anything that stalls that count — a long wire making the edges slow, a radio, another library's interrupt — turns one bit over and the checksum discards the frame.

Retry rather than report:

float t = NAN;
for (int i = 0; i < 3 && isnan(t); i++) {
  t = dht.readTemperature(false, true);   // force past the cache
  if (isnan(t)) delay(50);
}

Three attempts covers ordinary jitter. If it takes three attempts every time, the problem is the wiring or the placement rather than luck.