Mangadex 400 Bad Request (my instance only)

[mattconnell]

Describe the bug When I try to create a feed using the Mangadex bridge, using any URL, I get a 400 Bad request error.

400 Bad Request

This is usually caused by an incorrectly constructed http request.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/400 Details Type: HttpException Code: 400 Message: https://api.mangadex.org/manga/f9c33607-9180-4ba6-b85c-e4b5faee7192/feed?limit=10&order%5BreadableAt%5D=desc&translatedLanguage[]=en&includes[]=manga&includes[]=scanlation_group&includes[]=user resulted in 400 Bad Request File: lib/http.php Line: 36

To Reproduce

I can only reproduce this on my own bridge instance, which leads me to believe that I have something misconfigured.

Expected behavior

Successful output, e.g., from the official instance

Additional context

Again, I can only reproduce this on my own instance. All other bridges (without documented bugs) work fine on my instance except this one. I can click on the api dot mangadex dot com URL and get a proper response, so the URL that is being generated is correct and valid, but the request being sent from the bridge results in a 400. I think I have something misconfigured but I can't discern what it is.

[dvikan]

im unable to reproduce this

can you give me the exact url you are using?

you can omit the leading hostname

[mattconnell]

If I right-click the (?) to use the example Mangadex URL, what gets generated is as follows:

https://bridge.domain.tld/?action=display&bridge=MangaDexBridge&context=Title+Chapters&url=https%3A%2F%2Fmangadex.org%2Ftitle%2Ff9c33607-9180-4ba6-b85c-e4b5faee7192%2Fofficial-test-manga&limit=10&lang=&images=no&format=Html

The URL that gets generated by the example instance is as follows:

https://rss-bridge.org/bridge01/?action=display&bridge=MangaDexBridge&context=Title+Chapters&url=https%3A%2F%2Fmangadex.org%2Ftitle%2Ff9c33607-9180-4ba6-b85c-e4b5faee7192%2Fofficial-test-manga&limit=10&lang=&images=no&format=Html

The URL encoding looks the same to my eyes, so I don't think that's the problem. I don't know what else to look at though.

On 10/24/25 16:56, Dag wrote:

can you give me the exact url you are using?

you can omit the leading hostname

[dvikan]

my local instance works as expected:

http://127.0.0.1:3002/?action=display&bridge=MangaDexBridge&context=Title+Chapters&url=https%3A%2F%2Fmangadex.org%2Ftitle%2Ff9c33607-9180-4ba6-b85c-e4b5faee7192%2Fofficial-test-manga&limit=10&lang=&images=no&format=Html

hard to debug. you can try this and see if theres anything interesting in the body:

diff --git a/bridges/MangaDexBridge.php b/bridges/MangaDexBridge.php
index fa82dc4b..bbefb1de 100644
--- a/bridges/MangaDexBridge.php
+++ b/bridges/MangaDexBridge.php
@@ -176,7 +176,14 @@ class MangaDexBridge extends BridgeAbstract
         $header = [
             'Content-Type: application/json'
         ];
-        $content = json_decode(getContents($api_uri, $header), true);
+
+        try {
+            $content = json_decode(getContents($api_uri, $header), true);
+        } catch (HttpException $e) {
+            var_dump($e->response);
+            exit;
+        }
+

[mattconnell]

Thanks for the tip. Looks like a User-Agent issue (details below). Now, the question is, since this is only happening on my instance... what do I have misconfigured? Maybe nothing?

``` object(Response)#45 (3) { ["body":"Response":private]=> string(45) "You must set an appropriate User-Agent header" ["code":"Response":private]=> int(400) ["headers":"Response":private]=> array(17) { ["cache-control"]=> array(1) { [0]=> string(8) "no-store" } ["content-length"]=> array(1) { [0]=> string(2) "45" } ["content-type"]=> array(1) { [0]=> string(25) "text/plain; charset=utf-8" } ["server"]=> array(1) { [0]=> string(8) "MangaDex" } ["via"]=> array(1) { [0]=> string(26) "HTTP/3.0 NA-SOUTHEAST-M1x2" } ["x-request-id"]=> array(1) { [0]=> string(36) "0208e098-2a0a-4fca-89a2-ad4d5fe8b8b4" } ["permissions-policy"]=> array(1) { [0]=> string(17) "fullscreen=(self)" } ["referrer-policy"]=> array(1) { [0]=> string(13) "strict-origin" } ["x-content-type-options"]=> array(1) { [0]=> string(7) "nosniff" } ["x-xss-protection"]=> array(1) { [0]=> string(13) "1; mode=block" } ["x-frame-options"]=> array(1) { [0]=> string(4) "DENY" } ["cross-origin-embedder-policy"]=> array(1) { [0]=> string(11) "unsafe-none" } ["cross-origin-opener-policy"]=> array(1) { [0]=> string(24) "same-origin-allow-popups" } ["cross-origin-resource-policy"]=> array(1) { [0]=> string(12) "cross-origin" } ["strict-transport-security"]=> array(1) { [0]=> string(44) "max-age=63072000; includeSubDomains; preload" } ["alt-svc"]=> array(1) { [0]=> string(19) "h3=":443"; ma=86400" } ["md-progressive-rollout-bucket"]=> array(1) { [0]=> string(10) "3969110439" } } } ```

A quick grep says that some bridges are explicitly setting a User-Agent header, but not this one. I thought perhaps because I am using the 'release' tag from August that maybe this had been something discovered and fixed in the interim but it doesn't look like that's the case. Maybe Mangadex is guarding against certain IP subnets for unauthorized scraping requests. For the sake of the argument my instance is deployed on a Linode VPS so I can definitely see that as being a problem.

Adding a User-Agent header to the immediately preceding array results in the bridge working as intended.

Shall I make a PR to add this? I suspect other people running bridges from well-known hosting providers may run in to the same issue.

[dvikan]

is you using docker

[mattconnell]

I was, previously, and had no problems with this bridge.

I recently switched to running it 'natively' (that is to say just in a directory served by nginx and php-fpm) and this issue arose.

Would docker affect the outgoing User-Agent on requests?

On 10/25/25 15:00, Dag wrote:

is you using docker

[dvikan]

I did indeed found a bug. Fixed in master. Please check if it solves your problem.

[mattconnell]

I'll try applying this tonight and check if it still functions without the manual UA being added.

On 10/25/25 17:32, Dag wrote:

I did indeed found a bug. Fixed in master. Please check if it solves your problem.

[mattconnell]

Just today got around to testing this and I still get a 400 error without a specified UA in my headers.

To be clear I'm applying a patch from your merged branch, but the rest of my copy of the code base is still at the 2025.08.05 release.

On 10/25/25 17:32, Dag wrote:

dvikan left a comment (RSS-Bridge/rss-bridge#4757)

I did indeed found a bug. Fixed in master. Please check if it solves your problem.

[dvikan]

curl -A '' 'https://api.mangadex.org/'
You must set an appropriate User-Agent header

Your copy of rss-bridge does not send useragent with http request. I have no idea why. Maybe try git master. Or maybe try stock config.

[Nikoos]

Hello,

I hit this issue too, in my case, I 'm using rss-bridge via FreeBSD.

Nikoos

[Nikoos]

I added the following quick and dirty hack (based ComcikBridges) :

at line 179, the current line is :

        $content = json_decode(getContents($api_uri, $header), true);

I replaced with the following content :

        $opts = [
            CURLOPT_USERAGENT => 'Mozilla/5.0 (X11; Linux x86_64; rv:145.0) Gecko/20100101 Firefox/145.0'
        ];

        $content = json_decode(getContents($api_uri, $header, $opts), true);

Now, no 400 error

regards,

Nikoos