# IPFS Gateway returns 404 when using api/v0/add

**URL:** <https://discuss.ipfs.tech/t/ipfs-gateway-returns-404-when-using-api-v0-add/6795>\
**Category:** Help\
**Tags:** go-ipfs\
**Created:** [December 3, 2019, 2:42pm UTC](https://discuss.ipfs.tech/t/ipfs-gateway-returns-404-when-using-api-v0-add/6795 "2019-12-03T14:42:19Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![cmagoun](https://avatars.discourse-cdn.com/v4/letter/c/3ab097/32.png) [@cmagoun](https://discuss.ipfs.tech/u/cmagoun)\
**Post date:** [December 3, 2019, 2:42pm UTC](https://discuss.ipfs.tech/t/ipfs-gateway-returns-404-when-using-api-v0-add/6795/1 "2019-12-03T14:42:19Z")

</div>

Greetings,

I have recently set up a go-ipfs node for testing as a gateway. I have been able to add files locally on the server, and read them remotely in the browser, as well as in code (C#, .Net and the Ipfs.Http.Client library). However, trying to add a file from a remote machine, using [http://mynode/api/v0/add](http://mynode/api/v0/add) fails with a 404 error.

I have set “Writeable”: true in the config file, and the daemon indicates that it is writeable on startup.

The request looks like this

POST /api/v0/add?chunker=size-262144 HTTP/1.1  
User-Agent: net-ipfs/0.33  
Accept-Encoding: gzip, deflate  
Content-Type: multipart/form-data; boundary=“3ac6737d-2600-454f-ae91-9a5713b2c22b”  
Content-Length: 227  
Host: myrealhostaddress:8080

–3ac6737d-2600-454f-ae91-9a5713b2c22b  
Content-Type: application/octet-stream  
Content-Disposition: form-data; name=file; filename=unknown; filename\*=utf-8’'unknown

This is a test  
–3ac6737d-2600-454f-ae91-9a5713b2c22b–

Has anyone experienced this behavior, or does anyone have any ideas on how to begin diagnosing this problem?

Thanks,  
Chris

---

<div class="post-metadata">

**Author:** ![valeriano-cossu](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/valeriano-cossu/32/3266_2.png) [@valeriano-cossu](https://discuss.ipfs.tech/u/valeriano-cossu)\
**Post date:** [December 3, 2019, 3:57pm UTC](https://discuss.ipfs.tech/t/ipfs-gateway-returns-404-when-using-api-v0-add/6795/2 "2019-12-03T15:57:39Z")

</div>

not work… you need a proxy

---

<div class="post-metadata">

**Author:** ![cmagoun](https://avatars.discourse-cdn.com/v4/letter/c/3ab097/32.png) [@cmagoun](https://discuss.ipfs.tech/u/cmagoun)\
**Post date:** [December 3, 2019, 4:28pm UTC](https://discuss.ipfs.tech/t/ipfs-gateway-returns-404-when-using-api-v0-add/6795/3 "2019-12-03T16:28:33Z")

</div>

Ok, I can see that now. Thank you very much.

---

<div class="post-metadata">

**Author:** ![hector](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/hector/32/178_2.png) [@hector](https://discuss.ipfs.tech/u/hector)\
**Post date:** [December 21, 2019, 9:19am UTC](https://discuss.ipfs.tech/t/ipfs-gateway-returns-404-when-using-api-v0-add/6795/4 "2019-12-21T09:19:44Z")

</div>

hey, have a look to [Writeable HTTP Gateways](https://discuss.ipfs.tech/t/writeable-http-gateways/210) which describes the usage of the writable gateway endpoints.

The writable gateway endpoint is not the same as the HTTP API (API runs on 5001 and gateway on 8080). You are getting a 404 because the path you are posting to is not handled by the gateway (but it should be by the API).

Depending on your access-control requirements, you may need to setup a reverse proxy in-between to control authentication etc. or to limit the API surface area that is exposed.