Issue with CoAP POST – "No matching proxy rule" on custom server using nRF9151 (Lesson 5, Exercise 1)

[Priyesh Shahi]

I'm currently working through DevAcademy Lesson 5, Exercise 1 using the nRF9151 DK, following the CoAP client example. I’ve encountered an issue when attempting to POST data to my own CoAP server.

What works:

• The code works correctly when posting to the Eclipse CoAP server (using its hostname and resource URI).

• It also works with the coap.me test server (coap://coap.me/test).

What fails:

• When I replace the server with my own CoAP server hostname and try a POST request, the device returns the following error in the log:

[00:00:03.350,067] <inf> coap_client_sample: CoAP post response: code: 0x80, payload: No matching proxy rule

Additional Notes:

• I’ve tried both IP and hostname for my server.

• The error code 0x80 indicates a response with no specific CoAP status class, and the payload suggests some form of proxy or routing issue.

Question:

• What does the "No matching proxy rule" error mean in this context?

• Is there a configuration in the example or the modem firmware I might be missing?

• Does this error imply something on the server side (like unsupported proxying or a malformed URI)?

Any guidance on resolving this or additional debugging tips would be greatly appreciated.

Thanks in advance!

[Priyesh Shahi]

[Achim Kraus]

I guess, you better ask that the developers of that server. 

A response code uses 0bccc.ddddd (first 3 bits response class, last 5 bits details)

So a 0x80 is 4.00 => BAD REQUEST

If other servers are processing that request, then the request itself may not be the cause.

Why your own server doesn't want to process it, is something only you or the developers will be able to know.

Priyesh Shahi said:

"No matching proxy rule"

That may be a hint, that your coap-server acts mainly as proxy and has no "matching rule" for your request.

[Priyesh Shahi]

Thank you for the clarification regarding the 0x80 (4.00 Bad Request) response and the proxy behavior of the CoAP server.

I've resolved the issue with the help of our developer team. It turns out the server was expecting the hostname to be explicitly included in the CoAP request payload, which we had initially missed. Once we added that, the server started processing the requests correctly.

Appreciate your insights—it helped us narrow down the problem.

[Achim Kraus]

You're welcome.